After using Git for many years, I have a deep understanding of the advantages and challenges.
Without further ado, let's just go to the question: How to efficiently use Git to manage code in a large enough team?
Keep talking, just go to the answer: branch management.
There are many practices in Git branch management. Some are inherited from centralized version management tools like SVN, and some are summarized based on Git's own characteristics. At present, the three well-known Git branch management models on the market are:
- TrunkBased: The backbone is in hand, I have the world. All codes are greeted on the trunk, and only the trunk is used for release.
- GitFlow: rigorous, standardized, and difficult to use. The main reason is that I can't remember which branch to merge.
- AoneFlow: The first two are not good, then learn from their respective advantages to achieve a balance between yin and yang, and the mean.
TrunkBased
TrunkBased, also called trunk development, has a website dedicated to this development method: Trunk Based Development .
TrunkBased is a working method advocated by continuous integration thinking. 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 specific version for online deployment and Hotfix. In the TrunkBased model, there is no explicit feature branch. Of course, the distributed feature of Git inherently allows everyone to have a local branch, and TrunkBased does not exclude the existence of short-term feature branches, but when talking about this mode, people usually don't explicitly emphasize it.
After using the trunk development, in principle, our code base can only have one trunk branch, the master branch, and all new feature submissions are also submitted to the master branch, ensuring that the master branch is ready to be released after each submission . Without branch code isolation, testing and conflict resolution have become simpler, and continuous integration has become much more stable.
However, the shortcomings of this scheme are also obvious. If everyone is developing in the main trunk, it will be extremely painful when the code is submitted and merged, and conflicts will occur if you are not careful. Moreover, because there is no obvious feature branch in this way, it becomes very difficult to remove features that have already been online. (If you say to comment on the unnecessary functions and republish it, then I don’t say anything.) Another solution is to introduce feature switches, which control whether features are enabled or disabled, but adding switches introduces complexity , The introduction of complexity introduces the risk of bugs, after all, each additional line of code may be a new bug.
GitFlow
GitFlow is derived from the A successful Git branching model proposed by Vincent Driessen . On the whole, it is a complete version management process. The disadvantage is that it is too strict and not suitable for free and lazy programmers. Of course, there is no perfect solution in this species of programmers, and a small group of people will always feel bad. Refer to Ant, Maven and Gradle.
First picture:
GitFlow commonly used branches:
- Main branch (
master): The branch recently released to the production environment code. This branch can only be merged from other branches and cannot be directly modified from the Master branch. - Main development branch (
develop): contains all the code to be released to the next Release version. It can be developed directly in Develop, or the feature code of Feature can be merged into Develop.
- Feature branch (
feature/*): Feature item development branch.feature/Name the branch at the beginning. When the feature item is developed, it will be merged into the main development branch and enter the next Release. After the branch is merged, this feature branch will usually be deleted.
- Release branch (
release/*): A release branch created based on the main development branch,release/named the branch at the beginning, used for testing, bug fixing, and going online. After completion, merge into the main branch and main development branch. At the same time, put a Tag on the main branch and remember the Release version number, and then you can delete the release branch.
- Hot fix branch (
hotfix/*): Used to solve the bugs in the online Release version,hotfix/name the branch with the beginning, fix the online problem, after completion, merge into the main branch and main development branch, and tag the main branch at the same time.
According to the above description, GitFlow is a complete set of management methods from development to production, but switching and merging various branches back and forth can easily confuse people, so fewer people are used.
AoneFlow
AoneFlow is a set of internal version management model of Alibaba. It takes into account the easy continuous integration of TrunkBased and the easy management requirements of GitFlow, and it avoids the cumbersome shortcomings of GitFlow branches, that is, moderation.
AoneFlow uses three branches: main branch ( master), feature branch ( feature/*), release branch ( release/*), and three principles:
Rule one, before starting work, create a feature branch from the main branch.
This rule borrows from GitFlow. Whenever a new work item (such as a new feature or a problem to be solved, which can be completed by one person or completed by multiple people), from the representative of the latest released version Create a feature/feature branch usually named with a prefix on the main branch , and then submit code changes on this branch. In other words, each work item corresponds to a feature branch, and all modifications are not allowed to be directly submitted to the trunk.
Feature branches not only undertake new functions, but are also branches that need to be solved. For our team, in order to avoid ambiguity, with new features will feature/be prefixed with the problem to be resolved hotfix/as a prefix, in addition to the name, the other in accordance with a rule execution.
Rule two is to form a release branch by merging feature branches.
GitFlow first merges the completed feature branches back into the main branch and main development branch, and then tags the main branch to record the release information. TrunkBased is to wait for all required features to be developed on the main branch, and then pull the release branch from a specific location of the main branch. The idea of AoneFlow is to pull a new branch from the main trunk, merge all the feature branches that are to be integrated or released this time, and get the release branch. The release branch is usually release/named with a prefix.
We can release/testcorrespond each release branch to a specific environment, corresponding to the deployment test environment, release/prodcorresponding to the online formal environment, etc., and combine it with pipeline tools to connect the code quality scanning and automated test levels in each environment to produce The deployment package is directly published to the corresponding environment.
In addition, the feature composition of the release branch is dynamic, making it particularly easy to adjust. In some rapidly changing Internet companies, as well as Party B’s companies that adopt "agile operations", this situation is often encountered. The need to go online after completion may be adjusted at any time due to market strategy adjustments or a temporary decision of Party A. One of them Suddenly, the feature requires delayed release or not at all. Or a certain feature is found to have serious development problems before it goes live, which needs to be eliminated. According to the usual practice, it is time to manually "tick the code", and remove the relevant submissions that have been merged into the development branch or the main branch one by one. Those who have done it know it is very troublesome. In AoneFlow mode, to rebuild the release branch, you only need to delete the original release branch, pull a new release branch with the same name from the main trunk, and merge the feature branches that need to be retained, and the code is clean and not included. Unnecessary features.
In addition, the release branches are loosely coupled, so that there can be multiple integration environments to perform integration tests with different feature combinations, and it is also convenient to manage the timing of deployment of various features into different environments. Loose coupling does not mean that there is no correlation. Since the release process of test environment, integrated environment, pre-release environment, gray environment and online formal environment is usually carried out in sequence, the process can require only the features verified by the previous environment , Can be passed to the next environment for deployment, forming a funnel-shaped feature release flow. Of course, this kind of gameplay is more suitable for companies that have a complete development and integration platform. Small teams can't play it. For example, our team can't play this advanced gameplay.
Rule 3: After publishing to the online formal environment, merge the corresponding release branch to the main trunk, add a tag to the main trunk, and delete the feature branch associated with the release branch at the same time.
When a pipeline on a release branch completes the deployment of an online formal environment, it means that the corresponding function is actually released. At this time, this release branch should be merged into the main trunk. In order to avoid accumulating a large number of historical feature branches in the code repository, some feature branches that have been online should also be cleaned up. Similar to GitFlow, the latest version on the main branch is always consistent with the online version. If you want to go back to the historical version, you only need to find the corresponding version label on the main branch.
In addition to the basic rules, there are some unwritten skills in actual operation. For example, the hot fix after going online, the normal way to deal with it should 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 to ensure necessary pre-release checks and smoke The test can be executed automatically.
A few more words of nonsense
Either way, since it exists, there will be a certain degree of rationality. So, no matter which brand you turn over, it's not because it looks good, but because it suits you better.
Personal homepage: https://www.howardliu.cn
Personal blog post: How to efficiently use Git to manage code in a team of sufficient size?
CSDN homepage: http://blog.csdn.net/liuxinghao
CSDN blog post: How to efficiently use Git to manage code in a large enough team?