Branching strategies
How a team organises its Git branches: Git Flow with its five kinds of branches, GitHub Flow and its short branches, trunk-based development; where each branch starts and returns, and which strategy to choose.
- 25 cards
- 4 topics
- Free
The outline, topic by topic
Each topic is weighted the way the exam weighs it.
- Concepts
- Questions
- Sort and link
- Scenarios
A few cards from the deck
Git branch: what is it?
Show the answer
A movable pointer to a commit, which moves forward by one each time a new commit is made on it.
A branch copies no files: creating one is almost instant, which is what makes branching strategies practical.
In Git Flow, what does the main branch contain?
- Only the versions shipped to production, each one tagged
- All the developers' work, merged as the days go by
- The next version, being stabilised
- The urgent fixes awaiting validation
Show the answer
Only the versions shipped to production, each one tagged
Current work is integrated into develop and stabilisation happens in release: main only receives finished versions, hence the version tag on each main commit.
In Git Flow, a feature branch starts from … and returns into it; a release branch starts from develop and returns into develop and into ….
Show the answer
In Git Flow, a feature branch starts from develop and returns into it; a release branch starts from develop and returns into develop and into main.
The release branch stabilises a version: only fixes go in. When it is ready, it is merged into main, tagged, then into develop.
Git Flow: what is it?
Show the answer
A strategy with two permanent branches, main for shipped versions and develop for integration, completed by feature, release and hotfix branches.
It suits software shipped in numbered versions, but it adds branches and merges: it is heavy for a site deployed continuously.
Branches live for three weeks and every merge causes dozens of conflicts. What is the most likely cause?
- The branches drift away from the shared branch for too long
- The developers commit too often on their branch
- The team has too few permanent branches
- The commit messages follow no convention
Show the answer
The branches drift away from the shared branch for too long
The longer a branch lives, the more the others change the same files in the meantime. The fix: short branches, frequent integration of the shared branch into your own, and changes cut into small pieces.