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
?