Your company uses a Git repository in Azure Repos to manage the source code of a web application. The master branch is protected from direct updates.
Developers work on new features in the topic branches.
Because of the high volume of requested features, it is difficult to follow the history of the changes to the master branch.
You need to enforce a pull request merge strategy. The strategy must meet the following requirements:
-> Consolidate commit histories.
-> Merge the changes into a single commit.
Which merge strategy should you use in the branch policy?
Click on the arrows to vote for the correct answer
A. B. C. D.A
Squash merging is a merge option that allows you to condense the Git history of topic branches when you complete a pull request. Instead of each commit on the topic branch being added to the history of the default branch, a squash merge takes all the file changes and adds them to a single new commit on the default branch.
A simple way to think about this is that squash merge gives you just the file changes, and a regular merge gives you the file changes and the commit history.
Note: Squash merging keeps your default branch histories clean and easy to follow without demanding any workflow changes on your team. Contributors to the topic branch work how they want in the topic branch, and the default branches keep a linear history through the use of squash merges. The commit history of a master branch updated with squash merges will have one commit for each merged branch. You can step through this history commit by commit to find out exactly when work was done.
https://docs.microsoft.com/en-us/azure/devops/repos/git/merging-with-squashIn this scenario, the objective is to enforce a pull request merge strategy in Azure Repos to consolidate commit histories and merge changes into a single commit. The pull request merge strategy should be selected to meet the requirements.
Option A: Squash Merge A Squash Merge creates a single commit from a branch, while incorporating all of the changes made to the topic branch. This is accomplished by creating a new commit on the destination branch that represents the changes made in the pull request, while discarding the original commit history. A Squash Merge is a good option when there are many small, unimportant commits that are not needed in the commit history. In this scenario, it is desirable to consolidate commit histories, so Squash Merge can be a suitable strategy.
Option B: Fast-Forward Merge Fast-Forward Merge is a simple and common merge strategy that applies when the source branch is strictly ahead of the destination branch, with no changes on the destination branch. In this case, Git applies the changes from the source branch to the destination branch in a fast-forward merge, and the result is a linear commit history. Fast-Forward Merge is not a suitable strategy in this scenario since it does not consolidate commit histories, and it does not create a single commit.
Option C: Git Fetch Git Fetch is a command that downloads changes from a remote repository and updates the local branch pointers. It does not merge changes into the local branch, nor does it consolidate commit histories, so it is not a suitable strategy in this scenario.
Option D: No-Fast-Forward Merge No-Fast-Forward Merge is a strategy that creates a new commit on the destination branch that incorporates changes made in the source branch, while preserving the original commit history. This strategy is useful when multiple developers are working on the same branch and you want to maintain a detailed history of changes. In this scenario, the requirement is to consolidate commit histories, and No-Fast-Forward Merge does not merge changes into a single commit, so it is not a suitable strategy.
In summary, the best option to meet the requirements is Option A: Squash Merge. It creates a single commit from a topic branch while discarding the original commit history, which is desirable to consolidate commit histories.