CODEWITHSUNDEEP
git
MiniMe
MiniMe

Reputation: 1285

Git and coordination between programmers in open source/community projects -how does it work?

New to git so please forgive my ignorance.

Assume we have a project with one open source file and two independent programmers decide to change things in that file and this results in two features that are partially conflicting because each programmer modified a certain section of the file to fit his/her needs.

I am assuming that the next step for each of them is to submit a pull request and the owner of the repository will have to resolve the conflicts somehow.

What I don't understand is, in situations when you have large projects (e.g. the Linux kernel) how to they coordinate between these independent contributors? Everybody forking the project and trying to contribute inevitably results in chaos unlike in the case of projects that have coordinated teams of developers led by some kind or overall architect who decides what gets changed by who and when.

Can anybody please explain how this works?

Upvotes: 3

Views: 154

Answers (3)

jthill
jthill

Reputation: 60517

"inevitably"? You're borrowing trouble. Most merge conflicts are easily resolvable, two people added different meanings for the same new flag bit, so you fix one to use a different bit, things along those lines.

It's truly rare for two people to propose entirely incompatible changes to some source, and in those cases what better tool to have than Git, which lets everybody carry both and discuss possible resolutions? Sam says let's do it this way, Kim says that way, this is how collaborative problem solving works.

Upvotes: 1

alfunx
alfunx

Reputation: 3150

I am assuming that the next step for each of them is to submit a pull request and the owner of the repository will have to resolve the conflicts somehow

In case the owner is familiar enough with that code, he could do that. Otherwise he could just accept one of the requests and tell the other guy that he should fix the conflicts - that's the beauty of a distributed VCS. Consider this example:

*        (dev1/feature-A)
| *      (dev2/feature-B)
|/
*        (owner/master)

dev1/feature-A conflicts with dev2/feature-B, so the owner cannot merge both branches into his owner/master. He decides to merge dev1/feature-A:

*        (owner/master)
|\
| *      (dev1/feature-A)
|/
| *      (dev2/feature-B)
|/
*

Then he tells dev2 to fix the conflicts. For that, dev2 for example merges master into his branch:

*        (dev2/feature-B)
|\
* |      (owner/master)
|\ \
| * |    (dev1/feature-A)
|/ /
| *
|/
*

Now the owner can, for example, use that merge by merging dev2/feature-B to owner/master as fast-forward:

*        (owner/master, dev2/feature-B)
|\
* |
|\ \
| * |    (dev1/feature-A)
|/ /
| *
|/
*

This talk by Linus Torvalds on Git might be interesting to you.

Upvotes: 1

bsheps
bsheps

Reputation: 1544

What you said makes sense. The conflicts portion of the code is called merging and it typically happens automatically unless both developers edit the same line of code in the file. If this happens someone manually picks which code gets used.

In larger projects: The main difference (atleast where I work) is we keep a development branch in between the individual developers and the master. In other works, no code makes it to master directly, it always goes through the development branch first. Basically adding a layer to the project structure. The project owner/architect is the only person who can move code into master.

Master <--(Permission restricted)-- Development Branch <-- Individual developers

On larger projects you can have multiple development branches to separate development teams and add layers to this design as needed. If you were to draw a large project, this would look like a big tree.

Hope this helps clarify!

Upvotes: 1

Related Questions