When you are developing code in a branch, at some point, there will come a time to merge those changes back into development or master, thereby kicking off your release pipeline, for example. We will talk about release pipelines in Chapter 11, VSCode and PowerShell Release Pipelines. At the very least, you will need to merge your local changes back into the original repository so that others can see and use your code.

Merging code is pretty simple. You make sure that everything is committed. Afterwards, you change into the branch that you want to merge into, and specify the branch that you want to merge. The next code sample shows how to merge changes into a specific branch:

# Merge changes back to master
git checkout master
git merge develop

# Git log shows that master and develop are pointing to the same commit
git log

This merges all changes into the selected branch. It is possible that merge conflicts might appear (when multiple people changed the same files, for instance). This is usually no problem at all, but, depending on the number of conflicts, it can get quite confusing at the beginning:

# Provoking a merge conflict
# File change on master
Add-Content .NewFile2.ps1 -Value 'I can change'
git add .
git commit -m 'New release!'

# File change on dev
git checkout develop
Add-Content .NewFile2.ps1 -Value 'I hate change'
git add .
git commit -m 'Sweet new feature'

# All hell breaks loose
git checkout master
git merge develop

The following screenshot shows the message Git displays when encountering merge conflicts on the command line:

VSCode helps you by showing you what changes are incoming and current. Incoming changes are the changes that you are trying to merge into your current branch:

Accepting both changes is usually not the greatest choice, as it will often require at least some manual input. For example, if you and your colleague both add a new parameter to a function, you still have to decide what to do when accepting both changes. Does the code still make sense? Do my tests still work?