Git: master / develop / feature branch merge commits

Here’s the flow I’m following:

  • master branch is always in sync with production
  • develop branch is always the next version to be released
  • feature/feature-name branch is the feature currently being developed.

After the feature is done, a pull request is raised from feature/feature-name into develop branch, then from develop branch into master branch. We do all these in github.

However, whenever there is a pull request on github, here’s the merge branch created. Therefore, after feature/feature-name merged into develop branch, a merge commit is created; after a develop branch merged into master branch, another merge commit is created.

Therefore, in order to have 1 feature merged, I have to create 2 merge commits.

What is worse, now master branch and develop branch are no longer in sync, because master branch has 1 extra merge commit.

I got 2 questions:
1) am I following the right structure / practice?
2) how to avoid extra merge commits? Esp. how to keep the master branch do not create extra commit when fast-forwarding from develop?

  • Git: Merging and Submodules
  • How to rebase commits from another repository with a different history?
  • Merging two git repositories from some specific commit
  • GIT :: Merging 2 branches overwrite the content in one branch with the other
  • Magento upgrading with Git
  • while merging two branches. My files are getting lost
  • Git Mergtool: No files need merging + git status all conflicts fixed
  • Git. Merging changes from one file to another files WITHIN the same branch
  • 2 Solutions collect form web for “Git: master / develop / feature branch merge commits”

    There seem to be a few misconceptions in your question which I will attempt to resolve. First, you said that

    Therefore, in order to have 1 feature merged, I have to create 2 merge commits.

    What is worse, now master branch and develop branch are no longer in sync, because master branch has 1 extra merge commit.

    Yes, you are creating two merge commits, but you are only creating one commit in each branch (develop and master). This is how merging in Git works; when you merge one branch into another, it creates a merge commit.

    With regard to master and develop not being in sync, they might not have been in sync anyway if someone else merged a different feature into develop before you did. From a functional point of view, assuming that no one else made changes to master since the previous sprint, when you merge develop into master then both branches should be functionally equivalent (although their histories might look different).

    You asked this question:

    how to keep the master branch do not create extra commit when fast-forwarding from develop?

    If your develop branch actually fast-forwards the master branch, then I don’t consider you to be doing a Git merge. However, if you cannot fast forward master, then one way to resolve this is to do a manual merge. In this case, the merge commit is unavoidable.

    If you really hate merge commits, then you should consider using rebasing instead. Using git rebase, the source branch always “stays ahead” of the destination, allowing you to always fast-forward your commits into the destination.

    There is no right way it depends on you how you want to manage the branches. Some do it feature wise, some may do it module wise, some create separate branch for developers. But the key idea is to keep your local code in sync with master and develop branch, pull the updated code from the development branch more frequently.

    Git Baby is a git and github fan, let's start git clone.