Git branches are a feature that we rely heavily on to implement our collaborative and CI/CD processes. This time, we will briefly talk about two common types of branches.

The trunk

The master branch can be understood as a stable, releasable, production-oriented branch.

Our projects tend to be production-oriented, which means that the features we develop will eventually be deployed to production. If our backbone is not stable and not production-oriented, then the “tree” will grow further and further away from where we want to go, and further away from the production environment.

Shared branch

Depending on the needs of the team collaboration process and CI/CD process, there may be a dedicated shared branch to accept developer submissions in addition to the trunk.

When to use shared branches?

For example: at the beginning of the project, we set up a Git repository for the project. By default, we get a Master branch and write the first commit after we have prepared the project infrastructure (directories, documents, etc.). Develop Checkout is a branch that you can use to merge all of your functions into the Develop branch. Develop can then be called a shared branch.

After a certain phase of development is completed, develop’s changes are merged into the Master once they are verified to be ok.

You might think it’s weird, but that’s nothing special. Yes, after all, no matter what the name of the branch is, it’s still a normal branch, and you should understand it not in terms of the name, but in terms of the mission of the branch, in terms of the process.

Make things? No way! Don’t be careful? Don’t be afraid!

I’m just trying to mess things up! I prefer to develop in Master!

If you accidentally change the code on the master, you might as well push it.

Github and Gitlab provide branch protection function, you can set the specified branch as protected branch, in this case, set the master branch as protected branch, that is, even if you have changed the content of the local master branch, as long as you do not have permission, The master branch of the managed repository cannot be used.

This is xx flow.

Some mature Git collaboration flows already exist in the industry. If you want to learn more about mature Git collaboration flows, check out the following:

  • Git flow
  • Github flow
  • Gitlab flow

Each process has its own characteristics and scenarios, so if you’re on a team or project where a process works, use it! If these processes are not satisfied, you can completely customize a process based on the above process to meet the team or project, there is not too much dogma, everything should be based on reality!

What’s all this for?

Both the trunk and shared branches are common Git branches. We have named branches for team collaboration and CI/CD flow, so don’t think too complicated about them.

When it comes to figuring out the team collaboration process, I personally feel that if you can properly understand the three mature flows mentioned above, there is generally no problem, and the rest is a matter of improvisation.

trailer

The sharing this time is to pave the way for the process I want to implement later, which can be interpreted as the pre-skill. I will share Github flow and its CI/CD process through the project.