Question

Say I have two branches

master -- A -   -   -   -   -  - merge
          \                    /
           \- develop -- B -- C

Now if I want to merge it will be a fast forward, but should I do

git checkout develop
git merge master

or

git checkout master
git merge develop

And what if I have possible conflicts

master -- A - D -  -  -  -  -  -merge
          \                   /
           \- develop -- B -- C

Should I now merge in to develop or into master? This is a bit confusing, so a good explanation would be really appreciated

Answer 1

Missing Workflow Tasks

First of all, there are a few things missing in your workflow that make it hard to answer your question in a real-world way. For example:

1. You should always pull from upstream before merging branches. Others may have changed develop or master in ways that you haven’t accounted for.

2. You haven’t identified which is your long-lived line of development. One assumes develop, but that’s just a guess because you haven’t identified what happens to your branches after the merge.

General Best Practices for Rebasing Long-Lived Branches

So, assuming that you’ve updated your branches ahead of time, and that master and develop are both long-lived branches and that master is the “official” branch for completed code, then you should do something along these lines.

1. Make a temporary rebasing branch based on develop.

   git checkout -b tmp develop
   

2. Rebase your work onto master to ensure a clean fast-forward merge. I like to make this an interactive rebase, but do it any way you want. For example:

   git rebase -i master
   

3. Merge onto master. I prefer to force the merge to be a fast-forward, but you can do whatever suits you.

   git checkout master
   git merge --ff-only tmp
   

4. Make sure the merged branch pushes cleanly.

   git push origin
   

5. If all went well, dispose of your temporary branch.

   git branch -d tmp
   

6. Re-merge master with develop as a merge commit, rather than a fast-forward. This brings your development into line with the master branch for continued work.

   git checkout develop
   git merge master
   git push origin
   

Natural Consequences

Doing this ensures that the history on your master branch is relatively linear and free from merge conflicts, and still allows you to rebase when needed without screwing up published branches. This is all positive stuff.

However, this process can leave develop with a complex merge history since the re-merging from master to develop may not always be a fast-forward merge. This isn’t a problem, per se, it’s just a natural consequence of any workflow that includes rebasing. It’s something to be aware of, but in my opinion it’s a price worth paying for the flexibility it offers the team.