Having multiple branches is extremely convenient to keep new changes separated from each other, and to make sure you don't accidentally push unapproved or broken changes to production. Once the changes have been approved, we want to get these changes in our main branch!
One way to get the changes from one branch to another is by performing a
git merge! There are two types of merges Git can perform: a fast-forward, or a no-fast-forward
git merge --ff
A fast-forward merge can happen when the current branch has no extra commits compared to the branch we’re merging. Git is... lazy and will first try to perform the easiest option: the fast-forward! This type of merge doesn’t create a new commit, but rather merges the commit(s) on the branch we’re merging right in the current branch
git merge --no-ff
Not ever your current branch doesn't have any extra commits compared to the branch that you want to merge. If we committed changes on the current branch that the branch we want to merge doesn't have, git will perform a no-fast-forward merge.
With a no-fast-forward merge, Git creates a new merging commit on the active branch. The commit's parent commits point to both the active branch and the branch that we want to merge!
Although Git is good at deciding how to merge branches and add changes to files, it cannot always make this decision all by itself. This can happen when the two branches we're trying to merge have changes on the same line in the same file, or if one branch deleted a file that another branch modified, and so on.
In that case, Git will ask you to help decide which of the two options we want to keep! Let's say that on both branches, we edited the nineth line of file.txt.
If we want to merge dev into master, this will end up in a merge conflict: which is the correct line? Git can't knows this.
When trying to merge the branches, Git will show you where the conflict happens. We can manually remove the changes we don't want to keep, save the changes, add the changed file again, and commit the changes.