AZ-400 Question 63
Single answerYour team manages an enterprise application that must maintain multiple production releases concurrently. You often need to apply urgent fixes (hotfixes) to older releases while developing new features for the next major version. The team also wants a clear separation where integration testing can take place before committing changes to the main branch. Which branching strategy best meets these requirements in a Git-based repository?
- A
Adopt trunk-based development with short-lived feature branches merging directly into main
- B
Implement GitFlow, using a develop branch for new feature integration and release branches for older versions
- C
Use GitHub Flow, merging all changes directly into main after pull requests
- D
Maintain a single main branch with long-lived feature branches for each release cycle
Show answer and explanation
Correct answer: B
Explanation
GitFlow is particularly suited for teams that need to maintain multiple active releases and apply hotfixes quickly. It helps isolate development in the 'develop' branch, separates stable code in 'main', and provides dedicated release branches for older versions. This structure minimizes merge conflicts and ensures each production release can be patched independently. Refer to Microsoft Documentation (docs.microsoft.com/azure/devops/repos/git/git-branching-guidance) for details on implementing GitFlow in Azure Repos.
- A. Incorrect.
Option 1: This approach (trunk-based development) is very useful for continuous integration and frequent merges. However, supporting multiple older releases concurrently for hotfixes can become cumbersome, as there is typically no separate release branch structure to track older versions. Merging hotfixes or partial feature code into main can complicate version control.
- B. Correct.
Option 2: GitFlow includes a develop branch used for ongoing feature integration and testing, as well as separate release and hotfix branches. This structure is well-suited for maintaining multiple production versions and applying urgent fixes to older releases without disrupting main or ongoing feature development. It aligns with the scenario� need for clear separation and multiple production versions.
- C. Incorrect.
Option 3: GitHub Flow relies on a simplified model of merging feature branches directly into main. While it works well for smaller teams or single-version development, it does not natively accommodate multiple simultaneous production releases without additional branching conventions.
- D. Incorrect.
Option 4: A single main branch with long-lived features tends to complicate merges and integration. Keeping multiple long-lived branches in sync is challenging, and it does not inherently address hotfix needs for older versions in production.