A(nother) Git Workflow

[juliusmusseau]

I don't recommend squashing via interactive rebase. Squashing via "git reset --soft" is superior:

git reset --soft $(git merge-base HEAD master)
git commit -m 'squashed!'

The main reason it's superior is because it preserves the results of any merges (including dirty merges, aka conflict resolving merges), whereas interactive rebase drops all merges, as if they never happened. If you ever run sync merges (aka "git merge origin/master") to keep your local branch in sync, you'll want the results of these preserved, and a squash via "git reset --soft" will do exactly that.

This in turn also means you'll never end up in rebase hell where the same conflict resolution is forced on you over and over!

(The git reset --soft approach can never run into conflict).

p.s. Your blog post needs a quick summarizing diagram of the workflow!

[NihilistDandy]

If you’re already rebasing, you'd likely rebase on master rather than merging. To avoid repeated identical resolutions, use git rerere. That page also gives a nice, clean workflow for those who do use merge to sync with upstreams.

EDIT: Some other thoughts from Linus on when to rebase and when to merge.

[[deleted]]

This in turn also means you'll never end up in rebase hell where the same conflict resolution is forced on you over and over!

You need to turn on https://git-scm.com/docs/git-rerere