Build fluency in the vocabulary of a branching model with dedicated develop, release, and hotfix branches.
0 / 5 completed
1 / 5
At standup, a dev mentions a branching model with dedicated long-lived develop and main branches, plus separate feature, release, and hotfix branches that each follow strict, defined rules about where they're created from and merged back into. What is this branching model called?
Gitflow is exactly this: it is a branching model with dedicated long-lived develop and main branches, plus separate feature, release, and hotfix branches that each follow strict, defined rules about where they're created from and merged back into, giving a project a structured, predictable release process. A hash collision is an unrelated hash-table concept about two keys sharing a bucket. This structured-branch-types-with-strict-rules approach is exactly why Gitflow is chosen for projects that need a formal, predictable process for staging and releasing versioned software.
2 / 5
During a design review, the team adopts Gitflow for a project that ships versioned releases on a fixed schedule, specifically because dedicated release branches let the team stabilize and test a release candidate separately from ongoing feature development on develop. Which capability does this provide?
Gitflow's dedicated release branch here provides isolated release stabilization separate from ongoing development, since a dedicated release branch lets the team stabilize and test a release candidate without ongoing feature work on develop disrupting it in the meantime. Testing a release candidate directly on the same branch where ongoing feature development continues means a new feature merged mid-testing could destabilize the very release candidate being validated. This isolate-stabilization-from-ongoing-development behavior is exactly why Gitflow's release branches are used for projects with a formal, versioned release process.
3 / 5
In a code review, a dev notices a project ships versioned releases on a fixed schedule but has no dedicated release branch at all, testing each release candidate directly on the same branch where ongoing feature development continues to merge in new work. What does this represent?
This is a missed Gitflow opportunity, since a dedicated release branch would let the team stabilize and test a release candidate without ongoing feature development destabilizing it in the meantime. A cache eviction policy is an unrelated concept about discarded cache entries. This test-release-candidates-on-the-active-development-branch pattern is exactly the kind of instability risk a reviewer flags once a project ships versioned releases on a fixed, formal schedule.
4 / 5
An incident report shows a release candidate that had passed testing broke right before shipping, because a new feature was merged into the same branch the release candidate was being tested on, and no dedicated release branch existed to isolate the two. What practice would prevent this?
Adopting Gitflow's dedicated release branch stabilizes and tests a release candidate in isolation, without ongoing feature merges destabilizing it before it ships. Continuing to test release candidates directly on the same branch as ongoing feature development regardless of how often a late feature merge destabilizes a nearly shipped release is exactly what caused the breakage described in this incident. This isolate-the-release-branch approach is the standard fix once a formal, versioned release process is confirmed to need protection from ongoing feature development.
5 / 5
During a PR review, a teammate asks why the team adopts Gitflow's structured develop, release, and hotfix branches instead of simply using trunk-based development, given that trunk-based development is simpler and involves fewer branch types. What is the reasoning?
Gitflow's structured branches give a project with a formal, versioned release schedule dedicated space to stabilize a release candidate and patch production hotfixes without disrupting ongoing development, while trunk-based development is simpler and reduces merge risk for teams that ship continuously, but has no dedicated mechanism for isolating a release candidate from that same ongoing stream of small integrations. This is exactly why Gitflow remains chosen for formally scheduled, versioned releases, while trunk-based development is favored for teams shipping continuously.