Common branching development patterns
- Trunk development, trunk release
- Trunk development, branch release
- Branch development, branch release
Trunk development, trunk release
Mode:
The developer submits code to the trunk branch, which is used for software delivery. The development code for all new features is committed to the trunk branch, and when new features need to be released, the trunk code is deployed directly to the production environment.
Advantages: Simple branch, less workload of branch management
Disadvantages: During the defect repair phase, not all developers do defect repair, which can lead to a waste of resources.
When the branch development cycle is long, the branch is difficult to merge into the trunk branch
Best Software quality management practice: Unfinished feature code should not be carried into a release
Trunk development, branch release
Mode:
- The developer submits the written code to the trunk
- When the functionality of the new book is fully developed or near the release point, a new branch is pulled from the trunk
- Integration testing is performed on this new branch, and defects are fixed and release quality polished. When the quality is up to standard, release the version to the public.
Features:
- Trunk code submission activities are frequent, which poses great challenges to ensure the quality of trunk code.
- Branching only fixes defects and does not add new functionality;
- After the release of a new version, if a serious defect is found and must be fixed immediately, just release the patch version again after showing valley on the branch to which the version belongs, and then fix the merge trunk on the branch. You can also fix a defect in the trunk, and then pick out the code that fixes the defect and merge it into the branch where the defect resides. (FaceBook Mobile)
Advantages:
- People who are not associated with the new functionality to be released can continue to work on the development trunk, unaffected by the release
- When a bug occurs in a new release, it can be fixed directly in its own release branch, which is easy and convenient. Even if the code on the current development trunk has changed, this branch is not affected.
Disadvantages:
- The code on the trunk can usually only be developed for the functionality of the next new release. A release branch cannot be created until any of the features of the release have been developed in the trunk. Otherwise, it may affect the development plan for the next release. Open source projects are under less pressure in terms of release timing and features, so this branch approach is often used.
- With this development model, there is no constraint on the number of release branches, and the branch cycle is long, and it is easy to have the tendency of “branch hell”, which is common in “series product cluster + personalization” projects. (Custom development)
Branch development, trunk release
Mode:
- The team pulls branches from the trunk and develops new software features or fixes bugs on the branches
- Only when functionality on a branch (or branches) has been developed and is ready for release
- Defect fixes are usually done on the trunk, and when quality is achieved, the code on the trunk is packaged and distributed.
Advantages:
- Until the branches are merged, development activities between each branch are not affected by the other
- Teams can choose which branch to publish features on
- If a bug occurs in the new version, you can fix it directly in the trunk or use the Hotfix branch to show valley, which is easy and convenient, without considering other branches.
Disadvantages:
- To minimize impact between branches, developers often merge code into the trunk less frequently, delaying the discovery of code conflicts in each branch and preventing timely code refactoring
- If there are too many branches, code merge and acceptance success will increase rapidly when the life cycle of a branch (the time between pulling the branch from the trunk and merging the trunk) is too long. The amount of cost increase is proportional to the number of branches in the life cycle that join the main stem.
Specification of use:
- Keep the trunk in a releasable state as long as possible
- The life cycle of each branch should be as short as possible
- The trunk code synchronized with the branch this morning
- Do everything with trunk code, and do not merge code between feature branches if possible
Derivatives:
- Feature branching mode
- Team branching pattern
Feature branching mode:
Mode:
- Multiple development branches exist at the same time, and each branch corresponds to a feature development effort
- When the feature is developed, immediately close the main trunk.
- Other feature branches that have not yet joined the trunk need to pull trunk code from the trunk and merge it with code on their own branch before they can join back to the trunk
Advantages:
- Teams can work in parallel at the “feature” level while maintaining a stable release-ready state of the trunk branch
- It’s easy to adjust each release
Disadvantages:
- If there are too many feature branches, there will be a lot of merge costs
Specification of use:
- The life cycle of each feature branch should be short, with development and testing on the branch being completed in as little as three days. This requires breaking down features into smaller requirements as much as possible.
- Developers pull the latest deliverables from the trunk daily and merge them with their branches.
- Do not pull code from other feature branches
Team branch mode:
Mode:
- A group of people work together on the same branch, and that branch usually involves the development of a set of similar or related features.
- Because it is a set of feature development, the branch lasts longer than the feature branch
Large development teams (more than 40 people) work together to develop a product. The team is divided into multiple teams, and each team develops different system components. Only after a series of components are developed, can a new software version be released to the public.
Specification of use:
- Each team plugs high-quality code into the trunk as early as possible, even if it’s not released right away.
- Get the trunk to a deliverable state as soon as possible after it is plugged into the code
- Other teams pull deliverable code from the trunk early and merge it with code on their branches
Evolution of branching patterns
“Three Carriages” branch mode:
Mode:
The team maintains only three branches: development, pre-release, and release
- The development branch is the target branch for all developers to submit code to.
- As release approaches, cherry pick code from the development branch ready for release onto the pre-release branch
- The pre-release branch does bug fixes, documentation, and release-related work, not new feature development
- Release Alpha when the pre-release branch reaches Alpha release quality
- Further beta releases
- When the beta is stable, join the Release branch and Release the RC(Release Candidate) Release
- The RC version is stable and can be used as a stable release
Gitflow branch mode
The pattern that many enterprises apply
Mode:
- The Master branch is the release branch of the official version
- The Release branch is the pre-release branch used for quality polishing. If the Rlease branch is of the right quality, you can merge it into the Master branch, and you also need to merge the code into the Development branch
- The Development branch is the branch that integrates new functionality
- A Feature branch is a branch that a developer pulls from the Development branch in order to develop a Feature. When feature Development is complete, join the Development branch.
- If the release version (V0.1) has a serious defect, pull the hotfix branch from the v0.1 release TAB on the Master branch, fix the defect on the Master branch, verify and rejoin the Master branch, and release the new patch version v0.2. At the same time, the same defect exists on the Development branch, so the developers have to move the Hotfix branch code all the way to the Devemlopment branch to fix the defect on the Development branch.
The Gitflow branching mode is a combination of the characteristic branching mode and the troika branching mode.
Advantages: Each branch is clearly defined and unambiguous,
Disadvantages: Lack of branches, lack of feature branches
GithubFlow branch pattern
Source github work team practices
- Create a new branch from master and name the branch after the number of the feature or defect
- Commit code on this newly created branch
- Completed function development and passed self-test, created PR (Pull Request)
- Other developers will review the PR, confirm its quality, and then join the master
If the feature branch is short-lived, the pattern can be considered high-frequency: the “trunk build, trunk release” pattern
* Excerpt from Continuous Delivery 2.0