Git和开源/社区项目中程序员之间的协调-它是如何工作的?

我假设他们的下一步是提交一个pull请求,存储库的所有者必须以某种方式解决冲突

如果所有者对代码足够熟悉,他可以这样做。否则他就可以接受其中一个请求,告诉另一个人他应该解决冲突——这就是分布式风投的美妙之处。考虑这个例子:

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

dev1/feature-A 与…冲突 dev2/feature-B ,因此所有者不能将两个分支合并到其 owner/master . 他决定合并 dev1/功能A :

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

dev2 dev2型 例如,将master合并到其分支中:

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

例如,现在所有者可以通过合并来使用该合并 dev2/功能B 所有者/主人 快进:

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

This talk by Linus Torvalds on Git 你可能会感兴趣。

在更大的项目中:主要的区别(至少在我工作的地方)是我们保持一个 开发分公司

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

在更大的项目上,您可以有多个开发分支来分离开发团队,并根据需要向该设计添加层。如果你要画一个大项目,这看起来就像一棵大树。

希望这有助于澄清!

“不可避免”?你在自找麻烦。大多数合并冲突很容易解决,两个人为同一个新的标志位添加了不同的含义,所以您可以修改其中一个使用不同的位,沿着这些行的东西。

很少有两个人对某个源代码提出完全不兼容的更改,在这种情况下,还有什么比Git更好的工具呢?Git让每个人都能同时使用这两种工具并讨论可能的解决方案?山姆说让我们这样做,金说这样,这就是合作解决问题的方式。