Github "Squash and Merge" - subsequent pull request showing all previous changes

Question

I have a branch which I pulled from master branch. Let's call it integration.

In the integration branch, I made various commits (C1, C2, C3). When I am done, I made a Pull Request to the master branch. From the master branch, I did a "Squash and Merge" so it results in only a single commit in the master. This all seems great.

But then later, I made some additional changes to the integration branch and when I make a pull request again, I am seeing all the commit comments of previous changes (C1, C2, C3, C4) that I have already committed. This issue is not seen if I use the default "Create an Merge commit" in my earlier commit. What did I do wrong?

Answer 1

It's easier to understand visually. Here's your repo. master is at commit B, and your feature branch is at commit C3.

A - B [master]
     \
      C1 - C2 - C3 [feature]

A normal merge does this. A new merge commit, BC123, is added combining the content in master with those in feature. The histories are linked together. Note that feature does not move, it's still at C3.

A - B ------------- BC123 [master]
     \            /
      C1 - C2 - C3 [feature]

A squash and merge does this.

A - B ------------- BC123 [master]
     \
      C1 - C2 - C3 [feature]

BC123 contains the same merged content as before, but there's no connection to the feature branch. And again, feature does not change. feature does not get squashed, it sticks around. Instead BC123 contains the squashed changes from feature.

When you did more work on feature, commits C4 and C5 here, this happened.

A - B ------------- BC123 [master]
     \
      C1 - C2 - C3 - C4 - C5 [feature]

And when you issue a pull request, all the changes in feature not in master will appear. As far as Git is concerned that's C1 to C5. If you were to squash & merge again, there would be a new commit on master, but only with the content of C4 and C5 because Git is pretty good at figuring out duplicate content between branches.

A - B ------------- BC123 - C45 [master]
     \
      C1 - C2 - C3 - C4 - C5 [feature]

While you can work this way, it's confusing.

Long story short: once you merge a branch, don't work on it anymore. Delete it. If you need to do more work open a new branch.

This issue is not seen if I use the default "Create an Merge commit" in my earlier commit.

Going back to the merged version...

A - B ------------- BC123 [master]
     \            /
      C1 - C2 - C3 [feature]

If you do more work on feature...

A - B ------------- BC123 [master]
     \            /
      C1 - C2 - C3 - C4 - C5 [feature]

And then do a pull request, Git will show you the commits in feature which are not in master. Because of the merge, master contains C1, C2, and C3. So the PR only shows you C4 and C5. This is still confusing, and the same advice applies: once you merge a branch, delete it. Open another one if you need to do more work.

While squash & merge is simpler, merging (done right) provides a healthier history and more information for Git to work from. You'll get more out of Git if you understand how branching and merging works.

Answer 2

If I'm understanding your situation correct...

The main thing you're doing wrong is continuing to use a branch after it has been merged. After you merge, delete the branch. Additional work should be on a new branch.

The first "Squash and Merge" does not affect the integration branch; just how the integrated commits appear on the master branch. So, it makes sense that A, B, & C would still be there since you are reusing the old branch.

Good luck.