1

How does git handel a situation like this.

A project managed by git and hosted on Github has a number of collaborators. Two people working on a project make changes to the same file on there local computer. Say for example they are both working on the stylesheet. And then they both commit the latest changes and send them over to Github.

Would this not cause issues, if they both changed different things within the stylesheet, only one persons work would become the lastest version, and the others would fall into the history.

I dont quite understand how this situation would be handeld to prevent new changes being lost when multiple people are working on the same file.

Can anyone explain how it works?

Ben_hawk
  • 2,476
  • 7
  • 34
  • 59

3 Answers3

3

To complement the answer of Charlie Rudenstal: The push of the first collaborator will succeed. The push of the second collaborator will fail with the message "rejected, non-fast-forward". Then the second collaborator fetches the last changes, merge them with his changes (maybe resolve merge conflicts) and pushes again, then it will succeed.

dunni
  • 43,386
  • 10
  • 104
  • 99
  • And, of course, the answer depends on whether the two collaborators were committing conflicting changes to the same file to the same branch, which seems to be assumed... If they're using different branches, which is usually highly recommended, then someone just needs to do a merge down the road, where the decision of which change to accept can be left to someone who might have a little more insight than if it's just left to commit order... – twalberg Jul 30 '12 at 19:45
  • If they're using different branches, then chances are high that the push is not rejected, since default behaviour for "git push" is pushing the current branch. – dunni Jul 30 '12 at 20:23
0

If the first collaborator has already made a push, the push from the second collaborator will be rejected. The second collaborator will then have to git fetch and git merge the changes from the first collaborator before he or she can try to push the commits again. (or git pull but be aware of the quirks http://longair.net/blog/2009/04/16/git-fetch-and-merge/)

git merge will try to auto-merge as much as possible. Files that cannot be auto-merged will show up as conflicts. These have to be resolved manually, either by editing the conflicting files by hand or with a mergetool using git mergetool.

The contents of the conflicting file may look something like this:

<<<<<<< HEAD:file.txt
Hello world
=======
Goodbye
>>>>>>> 77976da35a11db4580b80ae27e8d65caf5208086:file.txt

Resolved files are marked as resolved and staged using git add. If any conflicts appeared during the merge the collaborator will now have to make a git commit before pushing the changes.

Also. Another approach using git pull --rebase: When should I use git pull --rebase?

Community
  • 1
  • 1
Charlie Rudenstål
  • 4,318
  • 1
  • 14
  • 15
  • 1
    -1. This answer is misguiding. `git` will try to merge automatically only if a user fetches and runs `git merge`. You're discussing merge conflict resolution. The questioner is asking about the concurrency model. – Noufal Ibrahim Jul 30 '12 at 12:59
  • You are absolutely right. I shouldn't have been so quick to answer. I will be more thoughtful in the future. – Charlie Rudenstål Jul 30 '12 at 13:31
  • I've only been here for six days so I didn't really know how to treat a down voted answer. I read up on it at Meta Stack Overflow and learned that you are supposed to fix it. So there we go. I'm thankful for the feedback @NoufalIbrahim – Charlie Rudenstål Jul 30 '12 at 19:35
0

The first person to push to the server on github wins. This is resolved via git, and not so much Github. The next person will get a message saying their push was rejected.

! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'ssh://<url>'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again.  See the
'Note about fast-forwards' section of 'git push --help' for details.

See http://gitref.org/remotes/#push

Thong Kuah
  • 3,263
  • 2
  • 19
  • 29