Undoing a commit and fixing a git push

Question 1

In order:

They don't have to re-clone (although that will work), but they do have to do some extra work.

When you did the rebase you made copies of your old commits. Let's say commit B was the one you "removed":
```
A - B - C - D    [old "febupdate", is what you pushed originally]
  \
    C'- D'       <-- HEAD=febupdate
```
Anyone who grabbed a copy of the first "push" has all three original commits, B C and D. Then when they go to grab the update they get the new commits C' and D'. Let's say they added commit E themselves. So they now have (before bringing in your update):
```
A - B - C - D       <-- origin/febupdate
              \
                E   <-- HEAD=febupdate
```
Once they bring in your update they get this:
```
A - B - C - D - E   <-- HEAD=febupdate
  \
    C'- D'          <-- origin/febupdate
```
As far as git is concerned, when it look at this new state, it thinks they wrote commits B, C, D, and E, and you wrote commits C' and D'. Git offers them a chance to merge their four commits (B through E) with your two.

Even if they did not make a new commit E, git still offers them a chance to merge "their" three commits (B through D) with your two. This will, in effect, "resurrect" commit B.

If they have no commits of their own (edit: and no unsaved work of course!), they can easily recover by simply forcing their febupdate to match origin/febupdate:
```
$ git checkout febupdate; git fetch; git reset --hard origin/febupdate
```
If they do have commits of their own (such as E), they need to bring those (and not any to-be-deleted ones) onto the new tip commit D', which they can do with either git cherry-pick or git rebase --onto. The latter is a bit trickier to work¹ but does everything in one fell swoop, as it were. The former (cherry-pick) is easier to think about: they just rename febupdate to oops, create a new local branch febupdate to track origin/febupdate, then git cherry-pick each of their commits (the ones that are really theirs) from oops onto the new febupdate.
The "proper" way is a matter of who's willing to do what kind of work and whether you and they are willing to allow the bad commit B to remain in the commit history. If everyone is willing to do all the above work, and you really don't want B to remain, that's the way to do it.

If it's OK for B to remain, and you want to make it easy for people, you can use git revert. The job git revert does is to add a new commit whose effect is simply "undo what was done in an old commit". Let's say that in commit B you added a file badfile and removed a good line from goodfile. The command git revert <sha-1-of-B> will make a commit that removes badfile and puts the good line back into goodfile. Whatever happened in B, revert "un-does" that and adds a new commit:
```
A - B - C - D - R   <-- HEAD=febupdate
```
Everyone expects new commits to be added, so this "just works" with whatever work-flow everyone already has.
Sort of, but if some people have already grabbed commits C' and D', whatever you do now will still cause someone some extra work (over and above their already-some-extra-work). In this case I'd probably just press on with making people do the recovery (as outlined in part (1) above).

¹There is an upcoming feature in git 1.9/2.0 that should (at least in theory) make it less tricky to work. Also, as a special case, git pull --rebase does the right thing in current git, but only if you have not already run git fetch. (This is a little hard to describe.)

Question 2

Firstly a new git clone is not necessary for other guys. If they know this "rebase", they can use

git fetch  
git reset --hard origin/febupdate

For your first question:

Answer is no, why your febupdate branch got messed up is because of the "rebase". The rebase cause git can not fast forward the changes. For the master branch, we only add new commits when we merge febupdate to it. In this case other guys can just use pull with no problem. (git can fast forward)

So I guess you know the answer of question 2 and 3. If you only add new commits, others can pull with no problem. To do this, a trick is:

backup current HEAD (you may use a tmp branch).
use any way to go to the correct status, your "git rebase HEAD~3" is one way.
copy all files of this correct status to a tmp dir (outside the git dir).
go back to the current HEAD by restoring from the backup branch.
replace your whole git dir by the tmp dir files.
now git status will show you deleted the files you want, commit changes, push

Question 3

The merge problem should stop once everyone gets there histories updated. Or they can do a git reset --hard <sha before the reset> on the branch and do a pull (this will cause them to lose any commits that they have the branch). They should back up the changes by creating a new branch that they can use to cherry-pick their commits from.

This article should give some insight to what is going on. And why doing git rebase on pushed commits is a really bad thing.

http://git-scm.com/book/en/Git-Branching-Rebasing#The-Perils-of-Rebasing

The next time you want to undo changes that have been pushed, you should use git revert <sha of commit>. This will create a new commit that is the inverse of the problem commit. If you want to undo only some of the changes you do git checkout <sha of commit with good files> -- <files to fix> and make a commit.

If you pushed the changes, you need to make a new commit that fixes the changes rather than trying to revise history by removing the commit.

Question 4

It's because they still have objects you reverted in their repos under an older hash. Git has to merge the new pulled data in with that hash in the graph and it is likely asking you for a commit message because it is trying to fast forward the merge. If you could have solved the problem by rm'ing the files that probably would have been cleaner.