Git

A merge using Git can be performed by switching to the target branch and then merging all of the changes from the source branch. If there are conflicting changes between the branches, you must resolve those just as you would when fetching new changes from the server. After merging the changes from the source branch and resolving any changes, you can commit the changes. This will result in a merge commit, which you push to the remote just as any change.

This can be done using the visual interface of Visual Studio or VS Code, but also using the following sequence of commands:

git checkout targetBranch
git merge sourceBranch

If there are any conflicts, you have to resolve these at this point. Otherwise, you cannot continue:

git commit -m “Merged changes from sourceBranch”
git push

As you will read in the Securing repositories section, it is possible to protect some branches by disallowing merging this way. Especially when it comes to changes to master, you might want to use another mechanism for merging changes, namely, pull requests. Using a pull request, you open a request for someone else to pull changes from your branch to the target branch. This way, another team member can first review your changes and only merge them when they meet all agreed standards. Others can comment on your changes or request updates before they perform the merge. This is the most common way of enforcing the four-eyes principle for source code when working with Git. The four-eyes principle says that every change or action should be viewed by at least two people.

Now, when you are approving a pull request, there are different strategies you can use for generating the merge commit. The most commonly used are a merge commit, squash commit, or a rebase.