Git chooses wrong ancestor commit

I'm using git with a few other people. W开发者_如何学编程e have a central repository and then local tracking branches. Recently, we've come across a problem where git will incorrectly think that the last common ancestor commit of the main branch and the new branch is a commit that was only pushed after we created the new branch, leading to changes being undone when we merge the new branch back in. An example:

Alice makes some changes in her local copy of the main branch and commits them, but does not push. Say she changes the first line of file foo.txt.

Bob pulls from the central copy of the main branch. As far as he can tell, he is up to date.

Both continue to work. At some point, Alice pushes. Later, Bob calls git log and sees that his branch is allegedly an ancestor of the commit in which Alice changed foo.txt, even though he never pulled her changes. When Bob merges, as expected, Alice's changes have disappeared.

I've been unable to reproduce this, but can tell from the logs that it did happen at one point (i.e. we have one branch which is allegedly a successor of a commit in which changes were made to a source file, but in which those changes were not present). How is this kind of thing possible, and how can I stop it?

---

Did someone at some stage force-push some changes and overwrote a specific hash commit (using -f in push). That sounds like your case scenario could happen with this.

If that can help you, our workflow at work is to always use rebase when pulling/pushing:

Person A has done changes and push them.

Person B continues working, doing local commits

At some stage Person B wants to push live. To do that.

• Person B make sure the local branch is clean (stash if not).

• Person B runs git pull --rebase (this will download all changes and re-apply his own on top of the new HEAD)

• If there is any conflict Person B resolves conflicts.

• Person B finaly pushes local copy live.

And reapply the same process, with Person A being the one behind the origin head and needing to pull rebase

And NEVER use -f when pushing live, it's really bad.

More Info: A force push is tempting when, say person A did a commit, pushed it live, then realised there was a bug left. Person A does an ammend to the last commit. The only way to then push that commit live is to do a push -f ... and that's really bad for people working on their own copies having done local commits to their copy and pushing live