Practice branching strategy vocabulary: Gitflow, trunk-based development, short-lived feature branches, feature flags, and the impact of branching strategy on deployment frequency.
0 / 10 completed
1 / 10
What are the main branches in the Gitflow branching strategy?
Gitflow (Vincent Driessen, 2010) defines: main (always production-ready), develop (integration branch for completed features), feature branches (created from develop, merged back to develop), release branches (created from develop for stabilisation before merging to main), and hotfix branches (created from main to fix production bugs, merged to both main and develop). It's structured but complex.
2 / 10
What is trunk-based development?
Trunk-based development means developers integrate their work into the main branch (trunk) very frequently — at least daily. This eliminates long-running feature branches and the painful merges that come with them. It's the foundation of continuous integration and is used by high-performing engineering teams at companies like Google and Facebook. It requires feature flags for work-in-progress features.
3 / 10
'Short-lived feature branches.' What defines a short-lived feature branch?
Short-lived feature branches (a practice advocated in trunk-based development) exist for a day or two at most. They reduce merge conflicts (less divergence from main), enable continuous integration (code integrates to main daily), and force smaller, more focused changes. Long-lived branches (weeks or months) accumulate changes that are painful to merge and delay integration feedback.
4 / 10
'Feature flags instead of feature branches.' What problem do feature flags solve?
Feature flags (also called feature toggles) wrap new code in a conditional that can be switched on/off without deployment. This allows teams to merge incomplete features to main (keeping branches short-lived) while the feature is controlled separately from the code. Features can be released gradually (canary), A/B tested, or rolled back instantly without a code deployment.
5 / 10
'The branching strategy impacts deployment frequency.' How does Gitflow affect deployment frequency compared to trunk-based development?
DORA research consistently shows that high-performing teams use trunk-based development and deploy multiple times per day. Gitflow's structure — long-running feature branches, formal release branches, strict merge protocols — creates batch releases that are less frequent and larger in scope (higher risk). The branching strategy is a significant factor in determining how quickly a team can respond to market needs or fix production issues.
6 / 10
Alice from the QA team just left a comment on your PR describing a potential regression. She says: 'I'm seeing unexpected behavior after merging branch develop into main. It seems like the new authentication logic is interfering with older data retrieval.' Which of the following best describes Alice's concern in relation to branching strategy?
Alice's comment directly points to the risk of integrating code from a branch with significant divergence (develop) into main. This can lead to integration conflicts and unexpected behavior. The core issue isn't just about merging; it's about the longevity and isolation of branches, which is precisely what branching strategies like Gitflow aim to mitigate by encouraging shorter-lived feature branches.
7 / 10
You're discussing a proposed change with your team. You want to emphasize the benefits of using short-lived feature branches for faster feedback and reduced risk. Which statement most accurately reflects the core advantage of this approach?
Short-lived feature branches are designed to be integrated frequently with the main branch (main or trunk). This reduces the size and complexity of merge conflicts, making integration much smoother. The key benefit is rapid feedback cycles – changes can be tested and validated quickly before they become deeply intertwined with the main codebase.
8 / 10
Consider this API response from a microservice: `{"status": "error", "message": "Branch conflict detected. Feature branch 'feature/new-payment-flow' is older than 72 hours and has diverged significantly from the main branch."}`. What does this response primarily indicate?
This API response directly relates to the branching strategy. The message explicitly states that the feature branch has diverged significantly and is too old, triggering a conflict detection mechanism. This confirms that the team isn't adhering to best practices around short-lived branches and frequent integration, resulting in integration difficulties.
9 / 10
During a standup meeting, your manager asks: 'How are we managing deployments with the current branching strategy?' You respond: 'We're using Gitflow. It allows us to maintain stability on main while enabling rapid feature development on separate branches.' What aspect of deployment frequency does this primarily address?
Gitflow's architecture—with distinct branches (develop, feature, release, and main)—facilitates a more controlled deployment process. The main branch remains stable while new features are developed in parallel on feature branches, allowing for staged deployments after testing.
10 / 10
You're explaining the concept of 'trunk-based development' to a junior developer. Which statement best describes its core principle?
Trunk-based development emphasizes a single, shared 'trunk' (main or trunk) and frequent integration. Developers commit directly to this trunk, typically using feature flags, minimizing the risk of large merge conflicts and enabling continuous integration and deployment.
What does this Version Control Strategy Language exercise cover?
This exercise, "Branching Strategy Vocabulary", tests your understanding of version control strategy language vocabulary and phrasing through 10 multiple-choice questions drawn from real workplace scenarios.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 10 questions. Each one presents a realistic sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Who is this Version Control Strategy Language exercise for?
It's designed for IT professionals and learners who want to sound natural discussing version control strategy language topics in English — useful for meetings, documentation, interviews, and day-to-day communication with English-speaking teams.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more Version Control Strategy Language exercises?
Browse the full Version Control Strategy Language exercises hub for more practice, or explore other exercise categories covering vocabulary, grammar, interviews, and workplace communication.