Practice Test 3 | Designing And Implementing Microsoft DevOps Solutions | AZ-400 | Dumps | Mock Test
Multiple developers are working on a project in your organization. Team members publish, share, review, and iterate on code changes through Git branches and share with others. You designed a Git branching strategy to share and manage code. You are using feature branches for all bug fixes or new features and merging feature branches into the master branch using pull requests.
One of the developers has made three changes to his feature branch. You want to make sure the below.
1. The changes work with the most recent version of the master branch.
2. You avoid any extra commits and ensure that the commit history is straight and linear.
3. Each commit should stand on its own.
Which integration strategy will you opt for?
A. Squash
B. Merge.
C. Cherry-pick.
D. Rebase.
Answer: D
- Option A is incorrect. Squash merge gives only the file changes, not the commit history. Squash merging condenses the history of changes in the feature branch. 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. It adds them to a single new commit on the master branch. This will not satisfy requirement three as each commit cannot have its own history.
- Option B is incorrect. Merge option takes all the commits from the pull request. It adds them to the master branch with a new merge commit. All the individual commits in the pull request will be preserved. A new merge commit will be created to unite the master and feature branch. This will not satisfy requirement two.
- Option C is incorrect. Cherry-pick cannot satisfy any of the requirements. It is a strategy to copy commits from one branch to another. Unlike a merge or rebase, cherry-pick only brings the changes from the commits you select, instead of all the changes in a branch.
- Option D is correct. Rebase takes the changes made in the commits in your current branch. It replays them on the history of the master branch. It takes all the work done on a feature branch and changes the history of the branch. The changes are based on a different version of the code. After the rebase, the feature branch has caught up with the latest changes from the master. When Rebase is used, commit history is straight and linear as in the Squash merge. At the same time, each individual commit stands separately. This satisfies all the listed requirements.
- Reference Links: For more information on pull requests and merge strategies, please refer to the below links from Microsoft- https://docs.microsoft.com/en-us/azure/devops/repos/git/pull-requests?view=azure-devops, https://devblogs.microsoft.com/devops/pull-requests-with-rebase/
Comments are closed, but trackbacks and pingbacks are open.