“This is the 19th day of my participation in the Gwen Challenge in November. Check out the details: The Last Gwen Challenge in 2021”

Hello, I’m looking at the mountains.

Having worked with Git for many years, I know both the advantages and challenges.

Without further ado, how do you manage your code effectively with Git on a large enough team?

Continue without more words, the direct answer: branch management.

Git branch management has many practices, some are inherited from the centralized version management tool of SVN class, and some are summarized according to the characteristics of Git itself. At present, there are three well-known Git branch management models on the market:

  • TrunkBased: Trunk in hand, world I have. All code is addressed to the trunk and only the trunk is used for distribution.
  • GitFlow: rigorous, normative, difficult to use, mainly because I can’t remember which branch to merge.
  • AoneFlow: The first two are not good, then use their strengths to achieve a balance of Yin and Yang, the middle is also.

TrunkBased

TrunkBased, also known as Trunk Development, has a website dedicated to this type of Development: TrunkBased Development.

TrunkBased is a working mode advocated by continuous integration. It consists of a single trunk branch and many release branches. Each release branch is created from the trunk at the commit point of a particular version for online deployment and Hotfix. In trunk-based mode, there are no dominant feature branches. Of course, the distributed nature of Git naturally allows everyone to have local branches, and TrunkBased does not exclude short-term feature branches, but it is often not explicitly emphasized when talking about this pattern.

With Trunk development, our code base can only have one Trunk branch, the Master branch, and all new functionality is committed to the Master branch, ensuring that the master branch is ready to publish after each commit. Without branching code isolation, testing and conflict resolution are easier, and continuous integration is much more stable.

However, the downside of this approach is that if everyone is working in the trunk, it can be very painful when the code is submitted and merged, and you can accidentally cause conflicts. Also, because there is no obvious feature branching this way, it becomes very difficult to remove features that are already online. (If you say that you want to comment out the features that you don’t want, then I didn’t say anything.) Another option is to introduce feature switches, which control whether features are turned on and off. However, adding switches introduces complexity, and introducing complexity introduces the risk of bugs. After all, each additional line of code may be a new bug.

GitFlow

GitFlow is derived from Vincent Driessen’s A successful Git Shoot model, as A whole, A well-rounded version management process. The disadvantage is that it is too strict, not suitable for free and lazy programmers. Of course, there is no perfect solution in the programmed ape species, and there is always a small group of people who feel bad about it. See Ant, Maven, and Gradle.

First above:

Common branches of GitFlow:

  • Trunk branch (master) : A branch of code recently released to production. This branch can only be merged from other branches and cannot be modified directly from the Master branch.
  • Main Development Branch (develop) : contains all the code to be released to the next Release. You can Develop features directly in Develop, or incorporate them into Develop.
  • Feature branch (feature/*) : Function item development branch tofeature/Name the branch at the beginning, and when the feature item is developed, it will be merged into the main development branch and entered into the next Release. After the branch is merged, the feature branch will be deleted.
  • Publish branch (release/*) : A release branch created based on the main development branch torelease/Start with named branches for testing, bug fixing, and rollout. Once you’re done, merge into the trunk and the main development branch, Tag the trunk with the Release number, and then delete the Release branch.
  • Hot repair branch (hotfix/*) : used to solve the online Release version of the bug, tohotfix/Name the branch at the beginning, fix the problems on the line, and when you’re done, merge into the trunk branch and the main development branch, with a tag on the trunk branch.

According to the above description, GitFlow is a complete set of management methods from development to production, but various branches switch back and forth and merge, which is easy to confuse people, so fewer and fewer people use it.

AoneFlow

AoneFlow is an internal version management model of Alibaba, which takes into account the characteristics of Trunk-based easy continuous integration and GitFlow easy to manage demands, and avoids the shortcomings of GitFlow’s cumbersome branches, namely the middle.

AoneFlow uses three branches: the main branch (master), the feature branch (feature/*), and the release branch (release/*), and three principles:

Rule one, before you start work, create a feature branch from the trunk branch.

This rule is borrowed from GitFlow, which creates a feature branch, usually named feature/ prefix, from the trunk branch representing the latest release whenever a new work item (such as a new feature or problem to be solved, either by one person or by multiple people) is started. The code changes are then committed on this branch. That is, each work item corresponds to a feature branch, and all changes are not allowed to be committed directly to the trunk.

The feature branch not only takes on new functionality, but also the branch of the problem to be solved. For our team, in order to avoid ambiguity, new functions will be prefixed with feature/, and problems to be solved will be prefixed with hotfix/. All rules except the name will be implemented according to rule 1.

Rule two, form the release branch by merging the feature branches.

GitFlow merges completed feature branches back into the trunk and main development branches, and then tags the release information on the trunk. TrunkBased waits for all required features to be developed on the trunk branch, and then pulls the release branch from a specific location in the trunk branch. The idea behind AoneFlow is to pull a new branch from the trunk and merge all the feature branches that are being integrated or published in turn to get the release branch, which is usually named with the prefix release/.

We can correspond each release branch to the specific environment, release/test to the deployment test environment, release/ PROd to the formal online environment, etc., and combine with pipeline tools to connect the code quality scanning and automatic test levels in each environment, and directly release the generated deployment package to the corresponding environment.

In addition, the feature composition of the release branch is dynamic, making it particularly easy to adjust. In some Internet enterprises with rapidly changing markets, as well as enterprises of Party B that adopt “agile operation”, such situation is often encountered. The demand of waiting to go online after completion may be delayed or eliminated at any time due to adjustment of market strategy or a temporary decision of Party A. Or a feature may have a serious development issue that needs to be resolved before it goes live. As usual, this is the time to manually “code”, weeding out related commits that have been merged into the development branch or trunk branch. In AoneFlow mode, to rebuild the release branch, just delete the original release branch, pull out the new release branch with the same name from the trunk, and merge the feature branches that need to be preserved. The code is clean and does not contain unnecessary features.

In addition, the release branches are loosely coupled so that multiple integration environments can be used for integration testing of different feature combinations, and it is easy to manage when features are deployed to different environments. Loosely coupled does not mean no correlation, as a result of the test environment, integrated environment, pre-release, gray environment and online environment, such as formal release process is usually carried out the order, in the process may require only through an environment before validation features, can be passed on to the next do deployment environment, to form the characteristics of the funnel flow. Of course, this kind of play is more suitable for companies with complete development integrated platform, small team can not play, for example, our team can not play this advanced play.

Rule 3: After publishing to the official online environment, merge the corresponding publishing branch to the trunk, add tags to the trunk, and remove the feature branch associated with the publishing branch.

When the pipeline on a release branch completes an online deployment of a formal environment, it means that the corresponding functionality is actually released, and the release branch should be merged into the trunk. To avoid piling up a large number of historical feature branches in the code repository, you should also clean up the feature branches that are already online. Like GitFlow, the latest version on the trunk branch is always the same as the online version, and if you want to go back to the historical version, you just need to find the corresponding version label on the trunk branch.

In addition to the basic rules, there are some unwritten tricks of the trade. For example, for a Hotfix after launch, the normal approach would be to create a new release branch corresponding to the online environment (equivalent to the Hotfix branch) and create a temporary pipeline for this branch so that necessary pre-release checks and smoke tests can be performed automatically.

A few more words of nonsense

No matter which way, since it exists, there will be a certain rationality. So, no matter which brand you finally turn over, it’s not because it looks good, but because it suits you better.

Recommended reading

  • What are microservices?
  • Microservices programming paradigm
  • Infrastructure for microservices
  • Feasible solutions for service registration and discovery in microservices
  • From singleton architecture to microservice architecture
  • How to effectively use Git to manage code in microservices teams?
  • Summary of data consistency in microservice systems
  • Implementing DevOps in three steps
  • System Design Series how to Design a Short Chain Service
  • System design series of task queues
  • Software Architecture – Caching technology
  • Software Architecture – Event-driven architecture

Hello, I’m looking at the mountains. Swim in the code, play to enjoy life. If this article is helpful to you, please like, bookmark, follow. Welcome to follow the public account “Mountain Hut”, discover a different world.