0. Be on local branch "foo". If you've just tried to pull and got conflicts, abort the merge. (Note that for this to work reliably, you should never pull without first committing or stashing your changes):

    git merge --abort

    git checkout -b m

    git merge origin/foo
    git merge [hash of some intermediate commit on origin/foo]

    git checkout foo
    git merge m
    git branch -d m
    git push

Similarly the git development involves many throw-away branches, plus the "next" branch may get rebuilt every time there is a release.

People often say: "don't rewrite public history" but that's a simplification of: "don't rewrite public history unless people should have already known it was going to be rewritten"

If someone checks-out a branch from my private fork instead of from the official repo, they better not complain to me that I rebased it. Similarly if they checkout a branch named throwaway/test-integration-of-foo

More needs to be written on this though, thanks for pointing it out

1. Never do work on a branch that is being tracked on the origin. Always segregate your work on a local-only branch by doing a 'git checkout -b my-work'

2. Since I prefer not to have merge commits that don't add value to the history, I always get the latest changes, and rebase my-work off the latest. i.e.,

  git checkout develop (being tracked on the origin)
  git pull (get latest changes)
  git co my-work
  git rebase develop
  git co develop
  git merge my-work (no merge commit as it's fast forwarded)
  git push
  git branch -d my-work