Take the 2-minute tour ×

I'm working with a few other people on projects, and today I ran into a situation I'm sure I'll see often. One of my co-workers and myself had split up some tasks to do on the same project and began working. He finished his tasks, and pushed his changes to our shared repository. I was still working on my changes, but I was afraid to push them and overwrite the code he had worked on with my project, only containing half the needed changes.

For this situation (just to be safe, I had a presentation on the code in a few minutes and didn't want any major setbacks), I made a copy of my local code, pulled his new code, copied the files I had edited into the project I had just pulled (we were working in two separate sections, but I'm curious as to how git/GitHub handles this issue when working in the same files), and then pushed our combined code. So how does git (or how should we) handle one project with two different changes to the same file?

share|improve this question

1 Answer 1

up vote 4 down vote accepted

Let's say we have Git repo A.

  1. Dev 1 clones Git repo A. Dev 2 clones Git repo A

  2. Dev 1 modifies files: foo, bar, and baz (from cloned Git repo A). Dev 2 modifies files: baz, bar, and foo (from cloned Git repo A).

  3. Dev 1 commits and pushes back to Git repo A. Dev 2 has to pull (fetch and merge) the latest snapshot of Git repo A before he can push to Git repo A

Git forces this behaviour. GitHub is just another Git repository hosted by a 3rd party online. Stop manually doing what Git was written to do and let it do its thing! You'll save a lot of time as well.

If there are merges in step 3 that cannot be resolved by Git's merge algorithm, you will be notified and will be given options on performing the merge manually.

share|improve this answer
Excellent! That answers my question perfectly. Thank you. –  Zachzor Jul 19 '11 at 3:47

Your Answer


