Git branch management models are quite numerous, with various concepts and illustrations. For beginners, they will look tired and may not understand.

I would like to describe how I personally do branch management and have better ways or suggestions to communicate in the comments section.

Resident branch

Keep three resident branches for three environments

  • The master production –
  • Develop, develop
  • Beta – test

Typically, each company has several different environments for each r&d effort

The names are pretty much the same. Here I have selected a few common environment names for production, test and development

You have several environments, usually corresponding to several resident branches

Protect the branch

master

In order to protect branches, master forbids direct local submission and requires an authorized developer to merge through the git platform used by the company

There are a lot of Git platforms, your company must have related platform choice, github Gitee Gitlab gitea and so on

It is recommended that the beta and Develop branches also initiate merges from the platform and do not commit merges locally.

The process of such a merger must have been known by authorized personnel

If you had a codeReview procedure, you could do this during the merge

Branch agreed

named

Functional iteration requirements

Start with feature/. Follow the corresponding version number of this project without V

Scenario use cases:

For example, for a platform, we call it AAA, the current online release is V6.0.0

  1. Product A needs to change AAA platform due to the requirements of A product, so the new iteration branch is pulled out by master as feature/6.0.1

  2. During the same period, product B needs to modify the AAA platform due to the requirements of A product. Product A and PRODUCT B negotiate the modification

    Whether to develop together in one iteration or separately

    Together, use feature/6.0.1 for development

    Otherwise, the master will pull out the branch feature/6.0.2 for development

    Both branches are pulled out by the master and do not interfere with each other

Bugfix type requirements

Start with bugfix/. The value is followed by the version number that is being iterated. If no version is being iterated, the value is added

Scenario use cases:

AAA platforms, for example, are scanned by code scanning platforms for bugs that need to be urgently fixed (theoretically this problem is relatively infrequent).

  1. The current iteration branch of AAA platform is Feature /6.0.1

    Then pull bugfix/6.0.1 from master

    Once the fix is complete, merge it to Develop,beta, and release it to Master

  2. After merging into master, master is merged into all iteration branches, that is, the feature/6.0.1 online version is revised to V6.0.2

Branch merge process

The feature and Bugfix branches are merged into the Master, Develop, and Beta branches

When the master has a new merge, it needs to merge the master’s code into the iteration branch currently under development

Develop will not merge with beta and Master! Beta in the same way!

Develop will not merge with beta and Master! Beta in the same way!

Develop will not merge with beta and Master! Beta in the same way!

It depends if you need to rebuild the Develop and beta branches

instructions

There’s a caveat here

Why merge branches under feature to master branch separately

Instead of feature->develop->beta->master

Assume that there are multiple iterations going on at the same time, but not simultaneous releases.

I’m going to use three letters here for multiple iterations A, B, and C

Their release time, respectively on the 1st, 2nd and 3rd of the same month.

Let’s say that on the 30th of last month, ABC has all finished iterating and released to a beta environment.

So when the beta was released on the 1st, there were b and C codes on the beta branch, which could not be separated from the separate release.

Therefore, we should never use feature/ merge to Develop, Develop to beta, and beta to master

Release process

Introduce automation platforms, there are a lot of platforms available, Jenkins Spug, etc

  1. Pulled by the automated platformmasterBranch to publish
  2. After verification online
  3. Git Platform releasereleaseTo generate thetagFill in the version well, with v
  4. Be sure to fill in the content of this edition!!
  5. Delete the corresponding iteration branch

For some business products that are individually customized by the backbone product

There may be some business, another backbone product

At the same time, some customers require customization

These customized requirements actually deviate from the backbone product

For this type of product, separate warehouses are forked out and branch management is done as described above

The custom project is associated with the trunk project through fork

Some parts of the trunk can be merged into a custom project by means of a merge

These projects are published by the automation platform’s separate business Job