Git rebase feature branch messes up commits in pull request to develop/master branch

Question

I have the following scenario:

• Master-branch: what is in production, can contain hotfixes
• Develop-branch: the branch my developers are using to create pull requests to
• feature-branches: the branch we create for the feature the developer is implementing.

Once the developer has finished its work, he creates a pull request on the develop branch. After approval, we squash-merge the feature branch onto the develop branch in order to not include all the commits the developer made on the feature branch. This allows us to have a clear and clean git history on the develop branch.

Sometimes the feature branch needs a rebase from the develop branch and this is where the trouble starts.. When we rebase the feature branch with the develop branch, all of the sudden a lot of commits from the develop branch are included in the pull request.

How can this be avoided so that the PR only includes the actual commits from the feature branch?

Concussion

Which branch are feature branches created from at the beginning of their life time? What is the relationship between master and develop? i.e. Is master lagging behind develop slightly, but otherwise identical? Other than feature branches, are there any other branches which contribute to develop too? – Press

@Press the master branch is indeed lagging behind the develop slightly in the sense that develop might contain features that are not release yet. Likewise, the master branch can contain hotfixes for bugs that need to be fixed asap. When this occurs, we immediately rebase the develop branch with the master branch so that those fixes are also available in the develop branch. hope this makes sense? – Concussion

Answer 1

I suspect this happens after you rebase develop from master after a hotfix release.

Consider the following scenario:

master   A->B->C
                \
develop          D
                  \
feature A          E

You then get a hotfix in master, F, and rebase develop off it. The rebase creates a "new" commit (D') with a different hash, so from git's perspective D and D' are two separate and unrelated commits. D still exists, and C is its parent, but it is no longer on develop - only on feature A:

master   A->B->C->F
                \  \
develop          \  D'
                  \
feature A          D->E

So if you then try to rebase feature A off develop, if you don't do an interactive rebase, git won't be able to recognise that D and D' are the same commit, and you'll end up with the following:

master   A->B->C->F
                   \
develop             D'
                     \
feature A             D->E

To get around this, when rebasing feature A from develop, do it interactively and tell git to drop D, as you know that it is identical to D'.

Press

I'll give that a try next time we run in this scenario. In the meantime, I'll accept this answer. Thanks! – Concussion

Would it not be better to merge master into development rather then rebase, so as not to rewrite public history? – Shrink

Or create a higfix bench that is merged into both, with master then rebase to develop (hence creating new master) when you ship? – Shrink

@IanRingrose Merging master into develop would get messy - each merge will create a merge commit which will make its way back to master when it's time to add the finished features into master for release. OP said they want a clean history on the develop branch, merge commits do not make for clean history, subjectively. Your second comment is bit more interesting and I don't think I have enough characters in a single comment to describe its shortfalls but with the available details for OP's git workflow it is still unsuitable. – Press

@IanRingrose Here is a post with another opinion on GitFlow. It talks about how merges pollute your history and can make it a nightmare to work with. – Press

@Press partly a UI is needed that remove merges from the visible history when they have no effect. (Perforce merge system does seem appealing at times) – Shrink

@IanRingrose Not sure I agree about the UI bit. If you remove the merges from visible history, then how will you know when a certain branch has made it onto its target branch (master/develop/whatever)? And if that info is not available, then how will you then know which point of history to test if you suspect a certain feature has caused a regression? – Press