Override Git Repository History - Designing and Implementing Microsoft DevOps Solutions - Exam AZ-400 | Microsoft

Override Git Repository History

Question

You are developing an application. The application source has multiple branches.

You make several changes to a branch used for experimentation.

You need to update the main branch to capture the changes made to the experimentation branch and override the history of the Git repository.

Which Git option should you use?

Answers

Explanations

Click on the arrows to vote for the correct answer

A. B. C. D.

C

Create pull requests to review and merge code in a Git project. Pull requests let your team review code and give feedback on changes before merging it into the master branch.

Incorrect Answers:

A: Use rebase to address the problem of updating your branch with the latest changes from the main branch. Rebase takes the changes made in the commits in your current branch and replays them on the history of another branch. The commit history of your current branch will be rewritten so that it starts from the most recent commit in the target branch of the rebase. Rebasing your changes in your feature branch off the latest changes in the main branch lets you test your changes on the most recent version in the main branch while keeping a clean Git history.

D: Share changes made in commits and branches using the push command. Push your branches to the remote repository. Git adds your commits to an existing branch on the remote or creates a new branch with the same commits as your local branch.

https://docs.microsoft.com/en-us/azure/devops/repos/git/pull-requests

When multiple developers are working on the same codebase, Git allows them to work in separate branches, and then merge their changes back into the main branch once their work is complete. In this scenario, you have made several changes to an experimental branch and need to update the main branch to capture those changes.

Option A: Rebase - This Git option allows you to apply the changes made in one branch onto another branch. In this case, you could rebase the changes made in the experimental branch onto the main branch, effectively replaying the changes made in the experimental branch on top of the main branch. However, this option should be used with caution since it changes the history of the Git repository and could potentially cause conflicts with other developers' changes.

Option B: Fetch - This Git option retrieves the latest changes from a remote repository but does not apply them to the local repository. It is useful for reviewing changes made by other developers before merging them into your local branch.

Option C: Merge - This Git option combines the changes made in one branch with another branch. In this case, you could merge the changes made in the experimental branch into the main branch. This option is safe and preserves the history of the Git repository, but it may result in a complex merge commit that could be difficult to understand.

Option D: Push - This Git option allows you to publish your local changes to a remote repository. However, it does not apply changes made in one branch to another branch.

Therefore, the correct option in this scenario is C. Merge.