Rebasing a branch before doing the real merge

Jan 18, 2017  

When working on a branch with tools like GitLab, I can then easily create a merge request and merge the branch back into master using a GUI. However, this happy path is only available if there is no conflict between the development branch and master.

So what should the process look like? This has been taken from a post on StackOverflow and adapted for my use case, as a reference for my furure self:

  1. git checkout master
  2. git pull
  3. git checkout issue/123-blah
  4. git rebase master
  5. …fix any conflicts…
  6. git pull
  7. …fix any conflicts…
  8. git push
  9. accept the merge request

Fix conflicts while rebasing

The git rebase command is quite helpful and provides guidance about the steps which need to be taken. The step 5 above can be described as:

  • Open the Git panel in Visual Studio Code (Ctrl+Shift+G).
  • Edit the files which need our attention; usually, this means choosing between two conflicting sections identified by <<<===>>> markers (known as conflict markers).
  • Add the files to staged (just git add them).
  • If there is a conflict with a submodule, you can’t use Visual Studio Code to add the submodule to the staged files; you’ll need to manually to the git add from the command line.
  • Continue rebasing with git rebase --continue until done.

Fix conflicts after pull

After fixing the conflicts with master the working copy of the development branch might no longer merge with the upstream development branch. So I just do a git pull, edit conflicts (if any) using Visual Studio Code and then commit the changes back before pushing the result to GitLab.

Accept the merge request

When accepting the merge request in GitLab, it might be a good idea to edit the automatically generated merge message rather than letting GitLab do everything by itself.