Introduction
In team collaborative development, version management tools are particularly important. They can help teams share code, rollback and other operations. The more popular version management tools include: CVS, SVN, and Git. As a distributed version management tool, Git has obvious advantages. It can provide each team member with a complete set of code libraries locally, which allows developers to submit code to the local warehouse without an Internet connection, reducing the need for central processing. Server dependencies.
With the popularity of Git, in order to carry out team collaboration and development more efficiently, people have developed several sets of branch management strategies suitable for various teams and projects through experience summarization. Git Flow is one of them, which has stricter version control. , mainly suitable for projects with larger development teams and longer development cycles, which can last from several weeks to several months. Next, the final actual solution is directly displayed. If the development team and project type are suitable, it can be used directly.
Git Flow workflow diagram
Git Flow workflow description
Overall specification recommendations:
All branches are named after version numbers, and each branch corresponds to a version number, for example, feature/v1.0, release/v1.0, tag/v1.0
1. Master branch
The stable version code branch cannot directly modify the code in this branch. It only accepts code merges from the hotfix and release branches. Each merge from the release/hotfix branch must be tagged with a version number to facilitate subsequent code tracing.
2. Main development branch Develop
Each feature iteration pulls the branch from develop. This branch only accepts code merging from the hotfix and release branches. This branch is prohibited from being merged directly into master.
3. New feature branch Feature
Iterative development branches for new features. After developers complete development, they are merged to generate the pre-release branch release/xxx (one-to-one correspondence with the feature branch). This branch is prohibited from testing, release and online, direct merging into develop, and direct merging into master.
4. Pre-release branch Release
The feature branch is merged into the develop branch after the development and self-testing is completed, and the tester creates a corresponding release branch from the develop branch. The testing department conducts integration testing, the development department fixes bugs, and conducts product acceptance. After passing the test (before the release goes online), merge this branch into the develop and master branches, and then delete the release iteration and the corresponding feature iteration branch.
5. Hotfix branch HotFix
This branch is created based on the master branch and is used to modify emergency bugs discovered online. After the bug fixes are completed and tested, they need to be merged back into the master and develop branches.
Summarize
The above is the Git version management strategy in real projects. It has been tested in actual combat and can be used out of the box. We can see that the above strategy is relatively cumbersome and requires the maintenance of two main branches, master and develop. Therefore, the Git Flow strategy only It is suitable for projects with larger teams and longer project development cycles. This cycle can be from a few weeks to a few months. In modern development models, in order to meet customer needs faster and better, agile iterative development methods are often adopted. .
Next, I will update a version management strategy suitable for agile management teams for your reference.