Q: When faced with multi-person collaboration, code management often presents troublesome problems. Conflicts, code loss caused by team members’ operational errors, branch management, version management, etc. can easily lead to rollback and troubleshooting. Submit logs, etc.
A: git flow
This article only introduces personal experience and an opinion on code management. If it does not apply or you are not interested, skip it!
Although each team has its own set of code management methods, mature teams generally have more rigorous and mature processes. But git flow (git workflow) is more suitable for most teams and most scenarios. Git Flow has become popular for trunk-based workflows, and it is now considered a best practice for modern continuous software development and DevOps (the intersection of development, technical operations, and quality assurance) practices.
The following is the flow chart of git flow
Branch situation: Under normal circumstances, code branches are divided into master, develop, feature, release, hotfix, etc. The larger the project, the more branches there will be, but they are basically based on these five types of branches. The following statements are purely personal understanding and are not official statements.
Manual dog head
- Master branch (production branch): Generally refers to the code of the production environment (formal environment), that is, the latest stable version. Direct modification of the branch code is not allowed, and only merging from other branches is allowed.
- develop branch: Generally refers to the main development branch, which allows direct modification (but is not recommended). If you need to add functions, it is recommended to pull out the feature/xx branch here, and merge it into develop after completion.
- Feature branch: Generally refers to the branch to complete a new module or function. Once the development is completed, it needs to be merged into the develop branch.
- Release branch: Based on the develop branch, it means that the current version has been developed, and the newly created release branch is used as the basic branch for testing environment and bugfix.
- Hotfix branch: Maintenance branch (can be understood as bugfix-specific). Generally, when there is a bug in the production environment, a hotfix branch needs to be pulled from the master branch or develop branch to specifically modify the bug (some teams are based on master, Some are based on the develop branch).
After understanding the regular branches of git, let’s explain how to operate the corresponding git flow and its advantages based on regular code management.
I believe that many developers use the regular status->add->commit->push process as the main code process (pull depends on your habits and mood, as long as you make sure to pull before push). Or use visual git applications such as sourcetree to implement code management. (I am used to the command line). The following describes the corresponding operations of git flow based on scenarios.
Scenario 1: Developing new features
(Only discussing new features developed on the current version of the project)
Non-git flow operation process:
Method 1: Generally occurs in teams with slightly smaller projects or projects that are independently responsible.
// Write bugs on the dev branch -> Finish add -> commit -> push
Method 2: Generally occurs in teams with slightly more rigorous processes:
// Pull the feature branch from the dev branch -> Code code to write bugs -> Finished add -> commit -> // Switch to dev -> merge feature branch feature -> delete feature branch
git flow operation process:
Compared with the complete process,
// git flow feature start xxx -> (git flow feature pull origin xxx) -> // (git flow feature pulish xxx) -> git flow feature finish xxx
Where xxx is the branch name, The first step of the git flow operation processCompare the Pull feature branch step from the dev branch in the non-git flow operation process method 2, in method 2 The naming is generally feature/module_function or feature/function. Under git flow, xxx is directly module_function or direct function. The pulish and pull steps are used as an operation method to avoid conflicts in multi-person development. They can be used as needed. If you are only responsible for independent work, you can finish after the local git flow start is completed. After finish, the feature will be merged into develop and the local feature branch will be deleted. .
Advantages: If a team develops in method 2, using git flow can simplify many processes, such as deleting redundant feature branches after development is completed, automatically merging into the develop branch, etc. For a team developing in Mode 1, although using git flow feels a bit unnecessary, you can standardize yourself and develop a good code management habit. In multi-person collaboration, you can better manage the code and avoid various problems.
Scenario 2: Testing Phase
Non-git flow operation process:
Method 1: Generally occurs in teams with slightly smaller projects or projects that are independently responsible.
Directly use the develop branch as the test branch of the current version. After fixing the bug, submit it for retest through the normal process. If there is no problem, use the current develop branch as the latest stable version and merge it into master as the production environment code. Disadvantages: If there is a new version during the repair process Requirements will be a little more troublesome to deal with. You have to consider how to avoid problems such as new code. Especially the requirements for new versions also need to be tested at this stage.
Method 2: Pull the release branch based on the develop branch. At this time, the develop branch no longer has features that need to be developed for the current version. Use the release branch as the final version of the current version as a test, which will not affect the development of new features (method 1 will not appear. This is a strange time node). If you step back ten thousand steps, new functions will intervene at this time. When the release is released, the stable release will be merged back to the develop and master branches. If there are conflicts, they still need to be resolved manually. A detailed analysis of the specific situation, the above is my personal opinion.
// git checkout -b release-0.1.0 develop -> git checkout master / develop -> // git merge -no-ff release-0.1.0 -> git push -> git branch -d release-0.1.0 -> // git push origin --delete release-0.1.0 -> tag
git flow operation process:
// git flow release start xxx -> (git flow release pull origin xxx) -> // (git flow release publish xxx) -> git flow release finish xxx
The operation process and instructions are similar to those of feature, so it is particularly easy to remember. Just choose feature or release according to the scenario, but remember to tag it when pushing. After all, if there is no problem with release, it means that this is a new stable version. Those that need to be merged into master and develop can be tagged to quickly locate various problems based on the identification.
Scenario 3: Sudden! There is a bug in the production environment!
Non-git flow operation process:
Master pulls the hotfix branch -> handles bugs -> tests -> merges into master
// git checkout -b hotfix-0.1.1 master -> git checkout master -> git merge --no-ff hotfix-0.1.1 ->git push
git flow operation process:
// git flow start hotfix 0.1.1-> git flow finish hotfix 0.1.1
The two processes are the same, but the operation is obviously much more convenient with git flow. In addition, if you use a non-git flow operation process, you must also consider the code merge issue, merging from master to develop. Using git flow, the hotfix branch will be merged into the master and develop branches during finish, and the hotfix branch will be deleted. But there is a special scenario that you need to pay attention to when using hotfix: If a release branch currently exists, it will be merged into the release branch when you finish, but not into the develop branch.
Commonly used git flow operations are the above scenarios. Although the process is similar to non-git flow, the operation is convenient and saves a lot of trouble, especially where to pull the branch and delete the branch after completion. Interested friends can give it a try. Personally, I think it is more standardized and convenient. For teams in the embryonic development stage, a standardized code management method can save a lot of unexpected things in the future (dddd, at least conflicts, etc.) More importantly, the code was killed by someone else T_T). It is cumbersome and inefficient to check the log locally, reset, and then handle the merge conflicts yourself.
All in all, if the team is very mature in this aspect, especially those who have used or are currently using git flow, are satisfied with regular git operations, or are accustomed to regular git processes, you can ignore this article.
If you are not familiar with the git process, you can first learn about the regular git development process. This article is shallow and can be regarded as an insight and review of my personal study and practice of git flow. Interested friends can try it for themselves. Thanks for watching and best wishes.
The knowledge points of the article match the official knowledge archives, and you can further learn related knowledge. Git Skill TreeHomepage Overview 6796 people are learning the system