Question

I am in the process of changing my git-merge-workflow and encountered following problem:

Up to now, i have been merging (–no-ff) my changes on the develop branch back to master whenever i released a new version. This generated a new merge-commit containing the history (–log) of all the develop-commits.
I realized that this is sub-optimal, and want to actually do fast-forward merges from my develop branch to master (having changed my commit-messages on develop to reflect my changes in a “cleaner” way).

My current problem: The most recent commit on master is a still a merge-commit from the last time, due to that I can’t do an ff-merge from develop to master now, since the 2 branches “diverged” (the merge-commit is missing on develop).

My idea to solve this would have been, being on develop: git rebase master, which would pull in this merge-commit, and then enable me to do a git merge develop on master.
But would this generate a new commit on develop (this particular merge-commit) or will git be smart enough to recognize that the changes of this merge-commit are already part of develop?

Answer 1

git rebase master while on develop will work fine for your purposes.

If your branches are currently like this:

A-B-C-D-E <-- master
       /
  F-G-H-I-J <-- develop

then they’ll wind up like this (because I-J is the only bit not reachable from E):

A-B-C-D-E <-- master
         \
          I'-J' <-- develop

which will then fast-forward merge back into master like this:

A-B-C-D-E-I'-J' <-- master