[richardwhiuk]

No warning on rebasing or amending pushed changes make this pretty unhelpful.

Edit: Hang on it's worse then that, it just says 'always force push your changes' - wonderful, you might drop commits that were previously on the branch head that someone else has pushed. Hooray.

[kartikkumar]

Yea, I read the force push and was a little shocked. Admittedly, having local and remote branches that have diverged has ended up being one of the biggest problems for me using Git. I was force pushing to my remotes to sync everything up until I read up on this and realised that this screws things up if anyone else has checked out your remote. So little puzzled that they recommend this. I also haven't found out what the modus operandus is to get everything to sync up easily. Anyone know if a workflow to deal with local/remote divergence is documented somewhere?

[lmm]

I'm not sure you need a "workflow". In the case of a complex divergence on branch "foo" my procedure would be:

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

1. Create a new branch "m":

    git checkout -b m

2. Merge origin into m, in several pieces if necessary:

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

3. Once you're happy with all this, switch back to foo and merge it, and push it upstream

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

[aidenn0]

Usually you have some sort of concept of which branches are rebasable and which aren't. For example, I keep a fork of the canonical repository I work on, and do force-pushes to that all that I want.

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

[k88hudson]

Force pushing to your own remote is fine in my opinion, when making a pull-request -- necessary for our particular workflow (I originally created this for contributors on my project)

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

[thinkstoomuch]

I follow this workflow:

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

[jordigh]

> No warning on rebasing or amending pushed changes make this pretty unhelpful.

Btw, Mercurial Evolve makes this completely safe for hg. No more warnings about "git push -f"!

[TimWolla]

Yeah, this should rather read: "Never ever rebase pushed commits, unless you absolutely know what you are doing".