CODEWITHSUNDEEP
gitversion-controlgithub
Ben_hawk
Ben_hawk

Reputation: 2486

Github file class

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?

Upvotes: 1

Views: 90

Answers (3)

Charlie Rudenstål
Charlie Rudenstål

Reputation: 4338

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?

Upvotes: 0

dunni
dunni

Reputation: 44555

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.

Upvotes: 3

Thong Kuah
Thong Kuah

Reputation: 3283

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

Upvotes: 0

Related Questions