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.
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.