Git V is a branching model. In other words, it’s a way for teams of humans working in parallel on software to serialize their work into useful and organized streams of commits.
At a high level, Git V divides work into two primary streams: destabilizing work (master) and stabilizing work (release branches). To keep the commit graph clean, Git V also takes advantage of specific merge mechanics (fast-forward) and pull-request policy (mandatory squash).
Example repo running Git V with two active release branches (including merge-backs).
It’s called “Git V” because that’s how it looks. In a typical repository running “Git V” there are two main branches: master and the current release branch. They diverge from each other at a join point, creating a “V” in the commit-graph. The two branch types receive two distinct classes of work: destabilizing work goes to the master, and stabilizing work goes to the release branches.
The two mainline branch types when using the Git V are “cutting edge” and “reinforcement.” These map to master and release/*, respectively.
Here are the mandatory and optional requirements to implement Git V in your shop:
Note: I suspect that fast-forward policy breaks down once you have 200 or more developers per day actively pushing their work to a single shared master branch. Nonetheless, I highly recommend a fast-forward policy to keep history clean as long as such does not devolve into a perpetual rebase fight.
These are not really part of the primary mechanics of Git V, but I recommend these for any PR (pull-request) based workflow.
While stricter review policies will result in even higher quality, such also require increased effort and tend to particularly distract senior engineers. I suspect a lightweight approach such as BYORS/ARA buys you the largest quality bang for the overall corporate effort expended.
BYORS/ARA is inappropriate for software projects where high quality is critical (e.g., flight control systems, medical equipment, etc).
Here are the steps for deploying Git V to your environment (these steps assume you are the git guru for your team).
Instead of trying to train your staff to use Git V, it’s much easier to just configure your central Git server to only allow sanctioned Git V operations and block non-compliant actions. Your staff will quickly figure out how Git V works because your Git server won’t allow them to do otherwise!
At a high level, the key config you want in place should cover the following:
Since I’m very familiar with on-prem Bitbucket, I’ve included very specific instructions below for implementing Git V in that environment:
(Note: these leverage each repo’s “Branching Model” configuration, in particular, the definitions for master and release/*).
4. For every project in your Bitbucket instance, enable “Automatic Merging.” It’s far fewer mouse clicks if you do this at the project level instead of the repository level:
Branching Model –> Automatic merging –> [x] Enable Automatic Merging
Similarly, for every project, adjust the “Merge Strategy” to disable the “–no-ff” strategy and enable the “–ff” strategy. At the very least, make sure “–ff” is the default:
5. If your policy is to block PR’s on failed CI builds, we strongly recommend also installing Bit-Booster – Rebase Squash Amend to avoid rebase fights thanks to the “build status propagation” feature.
This add-on also helps make squashing easier since you can squash directly on the PR screen when this is installed.
Note: On teams of 200+ developers working on a single repo (typically a monorepo), the fast-forward policy can become a bottleneck. Disable the fast-forward policy if you notice developers rebasing repeatedly just to get a merge in.
Question: I applied a bugfix to ‘master,’ and now I realize it really should have been applied to an older release branch. How do I fix this
Answer: Cherry-pick it to the release branch.
Question: I want to know the exact process a developer went through to develop a particular feature, but the history was squashed. How can I reconstruct the true history?
Answer: Some people prefer a more accurate history of exactly how a feature was developed in a branch. Git V is incompatible with those people because of how it aggressively sanitizes history to make history more succinct, focused, cleaner, and easier to understand.
Git Flow was ground-breaking in its time, and it was a great initial map for teams trying Git for the first time. If you look closely, you’ll see Git Flow makes the same primary classifications: destabilizing work (Git Flow designates a ‘develop’ branch for this) and stabilizing work (“release branches” in Git Flow terminology).
My main complaints about Git Flow:
Git Flow also does not properly anticipate multiple active release branches, though such is common in practice. If version 0.3 is already in production, where does 0.2.1 go (also in production) in the Git Flow map?
Git V is very similar to Microsoft’s Release Flow branching model. There are a few cosmetic differences and one significant difference that some might prefer!
The significant difference: Release Flow mandates that all stabilizing commits must land in master first before they are allowed to propagate to release branches. This is the inverse to Git V’s rule (stabilizing commits must land in a release branch first).
I suspect the Release Flow approach here allows bugfixes to receive more smoke testing in a highly active environment (presumably many devs build & run master every day). It also eliminates a common source of regressions (missed back-merges to master).
The downside to Release Flow’s master-first policy is it forces a cherry-pick, which makes an automatic merge-back cascade impossible. A hybrid approach could require the cherry-pick target the oldest reasonable release branch, in which case an automatic merge-back cascade could bring the fix to the remaining release branches.
The cosmetic differences: Release Flow does not mandate a squash policy or a fast-forward policy.
The Linux Branching Model employes a hierarchical trust model. Lieutenants and sub-lieutenants responsible for particular subsystems review and (publicly) sign-off on commits from developers, and use merges to encode this trust structure. Even Linus Torvalds is said to not always trust himself, and sometimes passes off his own commits to a lieutenant so that it passes through the proper review channels before it finally makes its way back to him for his final merge into his mainline.
The Linux model aims for maximum patch throughput with maximum patch quality through intensive public code-review by senior engineers assigned to specific ownership areas.
In the Git V model, review happens external to the branching model through PR-based systems like Bitbucket or Github. Git V is able to simplify the resulting git history by completely avoiding this merge-based review support baked into Git by its original designer.
The benefit of Git V here is a simpler commit graph. Also, the review and trust relationships between your staff can be more dynamic and fluid compared to the Linux model. The downside is your review metadata is stored in a separate system and thus may be harder to access. (E.g., answering the question “who signed-off on this commit?” is trickier in a PR based system).
Git V divides work into two main branch classes: destabilizing cutting-edge work, and stabilizing reinforcement work. It leverages automatic merge-backs to avoid regressions. It empowers developers to run their features branches however the like, while promoting fast-forwards and squashes to keep the mainlines neat and tidy.
Additionally, the three main headaches that would normally arise from implementing Git V are eliminated thanks to a pair of Bitbucket Server plugins:
If you do find yourself in a Git V shop or any shop that permits force-pushes, please remember:
Always use git pull –rebase, because it always does the right thing! (ps.2 Check our blog post on how prevent git rebase fights)
Regardless of whether you end up using Git V or not, I hope you found this to be a nuanced and interesting blog post on Git!
Thanks for making it this far!
About the author: Julius Davis - MergeBase Co-founder & Advisor. Senior architect and developer with strong academic background and roots in the open-source community. Contributor to a number of important open-source projects.