github团队工作流程-分叉还是不分叉？

Question

我们是一个由web开发人员组成的小组，目前正在使用subversion，但很快我们就会转向github。

我正在研究不同类型的github工作流，我们不确定对于每个开发人员来说，github中的整个分叉概念是否是一个好主意。

如果我们使用分叉，我知道每个开发人员都将拥有自己的私有远程和本地存储库。我担心这会让改变变得更加困难和复杂。另外，我最关心的是，它将迫使每个开发人员都有两个遥控器:原产地(这是远程分叉)和上游(用于“同步”主存储库中的更改)。不知道这是否是一种简单的做事方式。

这类似于这里解释的工作流：https://github.com/usm-data-analysis/usm-data-analysis.github.com/wiki/Git-workflow

如果我们不使用分叉，我们很可能可以通过使用中央回购为我们正在处理的每个任务创建一个分支，并将它们合并到同一个存储库中的开发分支中。这意味着我们将无法限制分支的合并，而且在中央存储库中有许多分支可能会有些混乱。

那些尝试过这两个工作流的团队有什么建议吗？

Answer 1

我认为你对分叉的恐惧来自于SVN的小于恒星的合并--因为不是分叉引起了麻烦--而是合并。

潜入水中-你会发现这真的很棒！您不需要过份分叉(不要对每个文件中的每一个更改进行分叉)，但是您可以对功能进行分叉，然后重新合并。

将GitHub看作是在源代码管理中的许多核心概念上值得改进的几个版本。

“稳定”分支和“主动开发”叉的概念也涵盖了其中的许多问题，如果您对分叉犹豫不决。:P

Answer 2

在git中，叉子实际上是另一根树枝。通过对每个开发人员的分叉工作流程，您实际上要求每个开发人员都有一个公共(远程)分支来跟踪他们的开发更改。这有助于开发人员之间的直接协作(对等)。在任何情况下，您都必须将每个开发人员的更改合并到中央回购中，所以我不认为这会增加太多的开销。

Answer 3

对于一个由2-3个开发人员组成的小组来说，可以使用repo上的分支来管理修复和特性。问题是，当您有更多的开发人员和更多的特性和修复正在开发。

如果是这样的话，您在Github的主要回购将有数百个分支；有些将是旧的，被遗忘的和未合并的。那些被遗忘的老树枝会影响git push性能也一样。

你也会有问题的协作，有人是武力-推动一个共享的分支，是在回购。这意味着没有人能够在这一分支上进行适当的合作，因为武力推动是对历史的改写。

分叉回购可以更容易地跟踪哪些分支正在进行中，哪些分支是好的。它保持主要的回购清洁剂。

但是，您的测试基础结构可能依赖于使用主回购，因此，除非您已经将分支推到上游，否则测试分叉回购中的更改可能会更加困难。分叉和分叉是最好的，但通常情况下，当团队有超过4人，并且有很多修复和特性时，分叉是最好的选择。