An Interest In:
Web News this Week
- March 26, 2024
- March 25, 2024
- March 24, 2024
- March 23, 2024
- March 22, 2024
- March 21, 2024
- March 20, 2024
Git(Hub) Flow, Trunk Based Development, And Code Reviews
The right branching model will improve any teams collaboration, quality, and speed. The wrong model will do exactly the opposite. These are the 3 most used branching models.
Name a company that develops software, theres a very high chance theyre are using Git to source control their codebase. Actually, theres a 77% chance, according to Smartbears State of Code Review 2020 Report.
Theres also a very high chance this company has a code review process in place. An 84% chance according to Codegrips Code Review Trends in 2020 report.
However, there isnt a single standardized methodology to develop software using Git and Code Reviews because its highly dependent on the team and the project characteristics. Its entirely up to the team to choose which methodology better suits their software development needs and goals.
Well go over the 3 main methodologies (also called branching models or branching strategies):
- Git Flow
- GitHub Flow
- Trunk Based Development
The original: Git Flow
Rarely a blog post has such an impact in the industry as the one Vincent Driessen published on January 05, 2010, named A successful Git branching model.
In his post, Driessen laid out Git Flow, a robust and strict branching model that became the industry standard for software development for years.
It brought parallel development to the masses, created the perfect conditions for collaborative programming, and it scaled easily.
With it, many companies managed to grow large and efficient teams and to deploy very complex software.
With Git Flow, the repository is centered on the main
and develop
branches, and it is supported by feature-n
, release
, and hotfix
branches, as described in this diagram:
Code Reviews play an essential part in ensuring the code is up to standard and bug-free when merging feature
branches to the develop
branch.
Git Flow allows for a very methodic and orchestrated software development but comes at a very high cost:
- the sheer volume of branches and its overhead is a nightmare to maintain
- teams have to be extremely disciplined otherwise they will end up with long-lived branches impossible to merge
The successor: GitHub Flow
With the advent of web apps and continuous delivery, a lighter and faster branching model gained traction: GitHub Flow. As you mightve guessed, it was created and popularized by the very own GitHub.
Its centered on the main
and feature
branches. Main
is always releasable. Developers create a new feature
branch to make changes. After reviewing these changes for bugs and code quality they will be deployed to production. If they cause problems, a rollback from main
will take place, otherwise, the feature
branch is merged to the main
branch.
Compared to Git Flow, GitHub Flow is much lighter. Maintenance is very low because the only long-lived branch is Main
.
However, GitHub Flow inherits other drawbacks from Git Flow. Undisciplined teams that keep feature
branches open for weeks risk serious problems when trying to merge. Ultimately, a failed merge can leave main
undeployable, and thats a big red flag for continuous delivery.
The shift: Trunk-Based Development
Also going by TBD, Trunk-Based Development is somewhat famously documented at trunkbaseddevelopment.com. In this branching model, developers make changes directly in a single branch called trunk
.
Trunk
is deployable at all times. Changes should be summited daily. Unfinished features should be unexposed with the help of feature flags.
Yes, you read it right. It sounds like Yolo Software Development. There are is no code review in TBD, either.
The catch is that this method can only work in small teams, with seasoned developers, and pair-programming is highly recommended. The pace is very fast because there is very little, if any, overhead. The team must be very skilled and cautious because everything goes directly to the trunk
.
This TBD model is actually officially called Trunk-Based Development For Smaller Teams. Despite its shortcomings, TBD for Smaller Teams is highly regarded by the software development community for its extremely lightweight workflow.
The seasoned: Scaled Trunk-Based Development
Luckily TBD has another trick up its sleeve: Scaled Trunk-Based Development. In order to operate at scale, this branching model uses short-lived feature
branches with a life span of a few days (maximum) before merging to the trunk
, which is deployable at all times.
Work in progress should be kept to a minimum, not only to avoid merging problems with long-lived feature
branches, but also to make up for easier and faster code reviews.
Code reviews will guarantee only quality code is merged to the trunk
and will allow for very early defect detection.
With Scale TBD, continuous integration is guaranteed, parallel development is supported, and quality is ensured with simple code reviews. It allows for quicker iterations with fewer errors, and its always deployable with very little branch management.
Own it!
It goes without saying that each team and/or product might warrant different needs in a branching model. Teams should take extra care choosing one.
Whichever branching model is chosen, it is very (!) important that its crystal clear to every team member what are the rules and steps in the workflow. Without it, any model will fail to bring out the best of the team and the product.
Original Link: https://dev.to/reviewpad/git-hub-flow-trunk-based-development-and-code-reviews-58ng
Dev To
An online community for sharing and discovering great ideas, having debates, and making friendsMore About this Source Visit Dev To