Imagine a very simple textdocument (text.txt) with as content just the letters 'ab'. This file has been check-in in a canonical (remote) repository. Two people have a local close of this repository and thus this file and start editing it. Dan changes the content to 'aB' (note the capital B) and John edits his version to 'abc'. Dan does a commit and pushes it to the canonica开发者_如何转开发l repository. John a little bit later does a local-commit and pushes the changes to remote. What happens (message) when John pushes his repository?
It depends on what flags John uses when he pushes.
By default, it will fail to push, because the remote branch head (Dan's commit) is not an ancestor of John's revision.
With -f
or --force
, it will simply overwrite Dan's change with John's, effectively undoing Dan's push -- if the server is set to allow forced pushes at least. Many git servers will simply refuse to do this.
Generally, the 'right' way to do it is for John to try to push normally. He will see the error I mention, and know that someone else has made changes. Then he will do a git pull
to retrieve Dan's changes and merge them with his own. The pull will attempt the merge, result in a conflict on your text file, and leave it for John to fix. After John resolves the conflict (perhaps by making the file contain 'aBc' and then using git add text.txt; git commit
to let git know), his local repository will include a 'merge commit' that is marked as including both changes. He can then push that to the server without further issues.
There is no conflict. John's push will simply be refused because the commit which he is trying to push is not a direct descendant of the remote branch.
If John wants his commit to be pushed he must first either merge it with the commit that is the head of the remote branch or rebate his commit on top of that commit. At this point he will have to choose how to resolve the resulting conflict in the text file.
There will be a merge conflict
精彩评论