How to sync up your git dev branch after you've merged+squashed a PR to master, in GitHub?

Question

So GitHub has the ability to merge+squash commits for a PR.

We follow the process of PR'ing code from dev -> master.

Previously, I've been just 'merging' the PR's but that generates a new commit which says: "Merge Pull Request #1 from foo/bar". :( Boooo...

So I thought I might try the new Squash Commits thingy with GH. This created a new commit with all my previous commits squashed. Ok, so far so good.

I then went back to my dev branch (on my developer machine) .. pulled down upstream/master (which was where the PR and squash-merge happened)) and it now added another commit to my local history! It didn't go "Oh .. wow. you're waaay out of line .. lets sync up". It just did a merge.

So the Squash+Merge button squashed 4 commits and replaced it with 1 ... the pull upstream/master on my localhost machine now has my 4 commits still there AND the Squashed-commit the PR did AND a new commit which is "Merge branch master .. blah ... noise ..spam" commit :( :( :(

Is there a special trick/workflow I should be doing after a merge-squash has occurred .. to make sure my dev branch is properly sync'd? Like .. does everyone just delete their localhost dev branch before they do a pull upstream/master back down to their localhost and into a (newly created) dev branch?

Remember: the goal here is to avoid those crappy "Merge Pull Request #2.." merge bubble messages.

Or are people just doing this via the CLI for the time being until GitHub learns how to do this :(

Preset

The easiest option is to create a unique feature branch off master and squash merge back to master when CI passes. Then delete the branch. – Alanis

Actually, the whole "rebase instead of merge" idea is quite misleading. The history with merge is correct. It has the development history of the feature, which hopely contains information about why changes were made. It has the merge commit which shows when the feature was merged. Rebased or merge-squashed branch does not link in any way to the original branch, thus losing the important information. If you don't like how git log or UI shows history with merges, then you should fix that. For example using option --first-parent – Alenaalene

Answer 1

I think the problem is with your workflow: usually once you merge a pull request (no matter which method you use) you are then done with that branch. If you want to do further changes, you better create a new feature branch out of current upstream/master and later you could open another pull request to merge it back.

In case you really want to stick to a single long-lived branch for all development (the one you call dev), there are a few caveats you have to keep in mind:

• If you are not the only one working on that branch, you have to avoid any kind of history rewriting. No rebasing, no squashing, no resetting, not even amending commits. This basically rules out using squash merge.
• If you are sure you are the only one working on that branch, and you use GitHub's squash option to merge pull requests as you did, then you must reset you local dev branch to latest upstream/master before resuming your work there. That also means that later you will need to force-push to upstream to create a new pull request.

The last point is error-prone and will affect previous code reviews so personally I would choose to just use short-lived feature branches.

Siskind

Answer 2

If your dev branch was merged and squashed then you don't need it anymore. Just reset it to upstream/master.

If there is some newer changes you can call git rebase -i upstream/master instead and remove all commits which was merged, rebasing the rest.

Alenaalene

Answer 3

There is a better solution for merging and squashing your commits without an extra commit saying "Merge Foo branch in Bar" . You should always prefer rebasing instead of merging and then squashing. So rebase will help you in merging two branches without any extra commit. You should try rebasing the branch instead of merging. Here is the detailed explanation for the same here.

Neb

So Github needs the 'merge' button to have a new option: 'Confirm rebase' (along side 'confirm merge' and now 'confirm squash and merge') ? – Preset

Merge will always create a new commit. Either you do by UI or console. But if you want to avoid a extra merge commit you should rebase. This rebase option is not present there right now in UI. – Neb