Resolve Conflicts

Last update: 20 Sep 2018 [History] [Edit]

In our GitLab Flow workflow we do not advise worrying about re-syncing (merge or rebase) with the upstream code, especially for developments that you can do in isolation (because they are fast or because you are the only developer working on that package). When the time comes to merge your changes, git is smart enough to only take your changes into upstream and it matters not at all if other files you did not work on changed in the meantime. (Actually, even if files you were working on did change merges are possible if only different parts of the file were changed.)

However, it can be the case that some changes upstream did affect the ability to apply your patch cleanly. In that case there is a merge conflict and you need to fix it. The GitLab interface will tell you this when case when you look at your merge request:


To start to resolve the conflict, pull in the upstream changes and merge the target branch into your branch:

git fetch upstream         # Fetch changes from upstream
git merge upstream/master
                           # Apply those changes to your branch
                           # Make sure you merge with
                           # your topic's target branch!

Because there are conflicts between your changes and the upstream ones git needs you to resolve them. The affected files are marked up with the usual conflict indicators (>>>>>>>) indicating which pieces of the file came from which versions. As the developer you now need to decide what the correct solution is (StackOverflow has lot of useful guides to understanding the markers, and github has a nice step-by-step).

git status is your friend for telling you what your options are to resolve or rollback as necessary.

Complete the merge by staging (git add) the conflicted files and committing them (git commit).

Once the merge has been done successfully, push your changes up to GitLab (git push origin followed by the branch name). GitLab will see the change and update the merge request automatically.

When to Merge

The strategy of not manually resyncing with upstream a priori before submitting a merge is by far the easiest way for most developers and most changes, so that is why we advise it . But if you do have very long lived developments, or you know that there is already a merge conflict or you want to actually use code that’s been committed upstream then you can integrate changes at any time using a merge. Each time you merge a special merge commit is created, but this is not considered a problem. There is more discussion on the GitLab flow pages.

Warning Git also supports another form of code consolidation called a rebase. This can be a powerful and very clean way to incorporate upstream changes, but it can go very wrong. So we don’t recommend it unless you really know what you are doing and everyone using your branch really knows what they are doing. Basically, do not violate the Golden Rule of Rebasing.