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?
1 Answer 1
Let's say we have Git repo A
.
Dev 1 clones
Git repo A
.
Dev 2 clonesGit repo A
Dev 1 modifies files:
foo, bar, and baz
(from clonedGit repo A
).
Dev 2 modifies files:baz, bar, and foo
(from clonedGit repo A
).Dev 1 commits and pushes back to
Git repo A
.
Dev 2 has to pull (fetch and merge) the latest snapshot ofGit repo A
before he can push toGit 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.
-
2Excellent! That answers my question perfectly. Thank you.Zachary Orr– Zachary Orr2011年07月19日 03:47:14 +00:00Commented Jul 19, 2011 at 3:47