Code branch management policy

Currently, I know two main methods for the branch and release policies of code management.
One is that the trunk is used as the main line for new function development and the branch is used for release.
The other is that the branch is used for new function development, and the backbone is used for stable version release.
The previous branch management policy is widely used in open-source projects. For example, the release of FreeBSD is a typical example. FreeBSD's trunk is always current, that is, including
An unstable version with the latest features. Then, with the gradual stabilization of new features, a stable branch will be split from the trunk after reaching a milestone of release. FreeBSD is a score for each major version.
. That is to say, 4.X, 5.x, 6, and X each has one branch. Only bug modification and improvement of existing functions are available on each release branch, without adding new features. New features will continue to be developed on the backbone. When Stability
After the changes on the Branch have been accumulated to a certain extent, a new release will occur. At the time of release, a release branch will be split up on the stable branch. Take 6.x as an example.
6.0, 6.1, 6.2... .
This release method is very suitable for Product Line release management. Products are to be sold. The versions previously sold to customers still need to be maintained, and new functions will be continuously added for the future market. This management method
Maintenance of released products and development of next-generation products are isolated. For published products, only maintenance patches are released. The newly released products include not only all bug modifications, but also
New features.
This method does not have any disadvantages. First, you must control the new features on the trunk. Only new features planned to be integrated in the next release can be added. In addition, new features that have been integrated on the trunk
If any of them fails to meet the milestone requirements, the stable branch cannot be created, which may affect the next release plan. Open-source projects may be under less pressure, but if commercial product development
This situation is dangerous. Another drawback is that the bug modification must be merged between different branches. From the perspective of some practical experiences in branch and merge, the long-term existing branches must be periodically merged.
Otherwise, merge conflicts are easily triggered. However, stable branches and release branches cannot be merged and must exist for a long time. Therefore, using this branch policy may touch
The biggest problem is the conflict that occurs when the bug modification content on a branch is routed to the merge of another branch. In addition, once a bug is found, it is necessary to investigate which branches are affected by the bug.
The number of release branches is increased.
In non-product development outsourcing software projects, the benefits of this release method cannot be reflected, but the disadvantages still exist. Outsourcing projects feature that customers always need the "latest" code.
Branches are rarely maintained (during testing ). The release method is different from the product release method. To publish a product, you only need to compile the code on the Production Branch into an installation disk,
The outsourced release usually sends the code that changes between the last release and this release to the customer. If each release is a branch, the comparison between the two branches will appear. Powerful version control tools
Of course, this comparison is supported, but many version tools do not support comparison between branches, but only support comparison between different versions within the branch. Therefore, to prevent the publishing method from being limited by tools, avoid inter-branch
Comparison. In special situations of outsourcing development, only another branch management policy is adopted.
Contrary to the first branch policy, the master is always a stable version and can be released at any time. All bugs and new features are modified on the branch. In addition, each bug and new function has different development branches, which are completely separated. Make a label instead of a branch for each release on the trunk. After the development and testing on the branch are completed, it is merged into the trunk.
The advantage of this release method is that it is easier to adjust the content of each release. If a new function or bug cannot be completed before the next release, it cannot be merged into the trunk, and other changes will not be affected.
More releases. In addition, the life cycle of each branch is relatively short, and the only long-term existence is the trunk, so the risk of each merge is very small. Before each release, you only need to compare the latest and previous versions on the master
The scope of the released file will be known.
This release mode also has shortcomings. If a Development Branch is not merged into the trunk for a long time because of its complicated functions or the requirements of the release plan, conflicts may occur during the final merge. Therefore
Always pay attention to the time when the branch leaves the trunk. If some branches do have to exist for a long time due to special requirements, the updates of the trunk must be merged on a regular basis. To reduce the number of such mergers, and
To limit the scope of the merge, you must create a Production Branch in advance for each release, and then merge all the development branches into each production branch according to your own release plan. All
After the change is completed and the test is complete, merge the content of the Production Branch to the master, publish the master, and then lock or delete the branch. Then, merge all updates on the trunk into the next several production branches. Outsourcing
The release cycle of a project is generally relatively short, and the customer acceptance test cycle is usually the release cycle. So this method is enough. If the release cycle is long, the branches of each release must be periodically merged from the beginning to the back.
Another disadvantage of this release method is testing. Unlike the first branch policy, the released branch is the test branch. The test branch of this release mode is usually the branch of each release, before the formal release
Merge updates on the next production branch to the trunk. This introduces the risk of merging errors, and the programs on the trunk are not tested. Fortunately, from the perspective of this release mode, we can see the basis for merging the next release branch.
It should be the same as the previous release of the trunk, so the risk of introducing merge errors is very low. Another suggestion is that you do not set the trunk. The next branch is the trunk. You can directly publish the change content of the next branch,
Merge the changes to the next release branch. And so on. Have a chance to try it.
Finally, let's talk about some notes about Branch merge management:
1. Leave the trunk as short as possible. Branches that leave the trunk for a long time must be merged regularly.
2. auxiliary documents are required. To observe the process of creating and merging branches, at least one document similar to a swimming track graph is required to mark the process of creating and merging each branch.
3. the number of times that a development branch merges into a trunk or publish branch should be as small as possible. Generally, you should merge the test to the master or release branch at the end of the test and then perform the test. If a bug is found in the test, it should not be modified on the original Development Branch, but should be modified by creating a new branch.
4. The branch creation and merge logs must be standardized. For later search. The basic log information should include the version from which the Branch is created, and the version from which the Branch is to which version.
The version of the branch to which the changes are merged. Some of this information can be easily found by the version control tool itself, and can be omitted.