Contents
Outline
The branch strategy is a way to efficiently manage code when multiple developers collaborate. There are various types of branch strategies, and you need to choose and use the appropriate branch strategy according to the characteristics of each. In this blog post, I will introduce the types and usage of branch strategies.
git-flow strategy
The git-flow branch strategy is a branch strategy proposed by Vincent Driessen. It is the most famous branch strategy among branch strategies, and many companies use it.
The git-flow branch strategy consists of master, develop, feature, release, and hotfix branches.
- master branch
- The master branch is used to maintain stable code that can always be released as a product.
- The releasable version is managed as a Tag on this branch.
- develop branch
- The develop branch contains the code for the next release.
- Branches for new features and bug fixes are created here.
- feature branch
- A branch for developing new features, created from develop.
- Each feature is developed in a separate branch, and when development is complete, it is merged into the develop branch.
- release branch
- A branch used in the preparation stage for a release, created from the develop branch.
- After preparing for deployment (updating version numbers, documents, etc.) and testing, it is merged into the master and develop branches.
- hotfix branch
- A branch for urgent bug fixes, created from the master branch.
- After the fix is complete, it is merged into the master and develop branches.
In git-flow, when the release branch is merged into the master, and the hotfix branch is merged into the master, it is released. Then, the release point is managed using Git tags.
GitHub flow strategy
The GitHub flow is one of the easy and intuitive Git branch strategies proposed by GitHub. This strategy mainly provides a simple workflow for release management in web development.
The GitHub flow branch strategy consists of master and feature branches.
- master branch
- The master branch is always used to maintain stable code that can be released as a product.
- feature branch
- A branch for developing new features, created from the master.
- Modify and commit the code to this branch.
- Pull Request (PR)
- When the feature is complete, the developer creates a Pull Request to merge it into the master branch.
- It cannot be merged if it does not pass code review or tests.
- Code review and test
- Another developer reviews the Pull Request.
- If automated tests pass, the code is considered safe.
- Merge
- When the Pull Request meets all conditions, it is merged into the master.
In GitHub flow, when the feature branch is merged into the master, it is released. In GitHub flow, it is essential to release frequently to provide new features and bug fixes to users quickly.
GitLab flow strategy
The GitLab flow is a branch strategy proposed by GitLab. The GitLab flow is the same as the basic GitHub flow. However, it is a strategy that can be used when there is a release timing (such as app review for iOS app deployment and services that are regularly deployed).
The GitLab flow branch strategy consists of master, feature branches, and branches for deployment (production, staging, etc.).
- master branch
- The master branch is always used to maintain stable code that can be released as a product.
- feature branch
- A branch for developers to develop new features, created from the master.
- Modify and commit the code to this branch.
- Merge Request
- When the feature is complete, the developer creates a Merge Request to merge it into the master branch.
- It can be merged if it passes code review or tests.
- Code review and test
- Another developer reviews the Merge Request.
- If automated tests pass, it is considered safe.
- production(stable, staging) branch
- A branch that has stable code that can be deployed to the production (stable, staging) environment.
- A branch created for deployment, created from the master branch.
- hotfix branch
- There is no hotfix branch in the GitLab flow. If there is a problem, create a branch from the master branch and merge it into the master branch. Then, use the cherry-pick feature of Git to merge it into the production branch.
The GitLab flow is a branching strategy that can be used when there is a release timing. The developed content (feature branch) is merged into the master branch, and when the release is needed, a production (stable, staging) branch is created from the master branch and released.
Trunk-Based Development strategy
The Trunk-Based Development(TBD) strategy is a simple and effective Git branch strategy aimed at rapid software releases and high collaboration. The TBD strategy emphasizes continuous integration (CI) and continuous deployment (CD).
The TBD branch strategy consists of single branch (trunk, master, main).
- Single branch (trunk, master, main)
- TBD mainly uses the master (main) branch. The master branch is used to maintain stable code that can always be released as a product.
- Frequent commits
- Developers mainly commit to the master branch. This makes changes shared to the code quickly to avoid cross-branch conflicts.
- Direct commit and code review instead of Pull Request
- Instead of creating a Pull Request for small changes, developers commit directly to the master branch for code review. This can minimize conflicts between branches.
- Release
- Since only the master branch is managed, releases are made at a specific timing.
TBD requires all members to commit within 24 hours. In other words, it is important to frequently write small chunks of code that can be committed within 24 hours.
TBD is famous for being used by Google.
- https://www.youtube.com/watch?v=W71BTkUbdqE&t=869s
- https://trunkbaseddevelopment.com/game-changers/#google-revealing-their-monorepo-trunk-2016
Scaled Trunk-Based Development strategy
The Scaled Trunk-Based Development(STBD) strategy is the same as the Trunk-Based Development strategy, but it creates a feature branch and commits to the feature branch. After that, the feature branch is merged into the master branch.
The STBD branch strategy is the same as TBD, consisting of single branch (trunk, master, main) and a feature branch.
- Single branch (trunk, master, main)
- STBD mainly uses the master (main) branch. The master branch is used to maintain stable code that can always be released as a product.
- feature branch
- It is a branch with a short life cycle for small commits.
- Release
- Since the master branch is directly committed, releases are made at a specific timing.
TBD needs its own development system by committing directly to the master branch and reviewing the code. STBD is a branch strategy that takes advantage of TBD and can be used in situations where it is difficult to construct its own TBD development system.
Completed
Done! We’ve seen the types and usage of branch strategies for software development. If you want to know more about each branch strategy, please check the link provided.
The branch strategy is a way to efficiently manage code when multiple developers collaborate. There are many different kinds of branch strategies, and there is no best or worst strategy. You can choose and use a branch strategy for each project and team, or to create and use your own branch strategy based on this branch strategy.
Was my blog helpful? Please leave a comment at the bottom. it will be a great help to me!
App promotion
Deku.Deku created the applications with Flutter.If you have interested, please try to download them for free.
