并行开发：开发人员应该在同一分支上工作吗？

Question

多个开发人员应该在同一个分支中工作，然后更新-修改-提交吗？还是每个开发人员都应该拥有自己的独立分支？如果共享分支，对于进行例行维护而不是未维护代码流的环境会产生什么影响？此外，如果您在每个开发人员完成并通过测试后立即部署他们的工作（快速部署），而不是将所有工作放入单个发布中，这将如何运作？

- Zombies

Answer 1

一般来说，我发现让开发人员（在同一个项目上工作的）使用相同的分支更有利于尽早发现集成问题。如果每个开发人员都使用单独的分支，则只是将可能的集成问题推迟到稍后，当您合并这些分支时。

当然，让开发人员在同一分支上工作意味着您需要在这些开发人员之间进行实际的沟通，但这是一个社交问题而不是技术问题。

当存在良好的原因使该分支首先存在（例如软件的先前版本的补丁发布或特定客户的特殊构建）时，开发人员会在单独的分支上工作。

请注意，Git和Mercurial等工具允许开发人员轻松创建自己的私有分支来组织自己的工作。这与多个开发人员共享分支的情况不同，并且应该鼓励使用（通常短暂的）私有分支。

- Greg Hewgill

---

我理解你对于集成的看法，但如果你正在使用像Hudson或Cruise Control这样的工具呢？ - Zombies

@Zombies：持续集成系统有助于更早地发现集成问题，但前提是您尽早进行集成。如果两个开发人员正在独立分支上开发同一项目，则 CI 工具不会为您尝试合并这些工作。如果存在合并冲突，则它确实无法做到。 - Greg Hewgill

我想补充一点，夜间构建系统将解决因不同工程师在同一代码上工作而可能出现的任何编译问题。这也有助于发布过程，至少知道一个分支在昨晚能够编译。 - omermuhammed

你能详细说明开发人员之间需要沟通什么吗？ - Zombies

@Zombies：开发人员需要相互交流，以免出现以下情况：（a）重复工作，（b）进行不兼容的工作，或者（c）在彼此不理解项目优先事项时不必要地互相等待。 - Greg Hewgill

Answer 2

分支被用作版本控制功能或实验性代码的方式，以防止这些代码破坏主线/干线。

尽管开发者有自己的个人分支进行深入实验，但通常分支围绕着添加新功能展开。这些新功能通常需要多人提交。

例如，在一个 Web 项目上，两名开发者和一名设计师可能正在为公司网站进行整体更新。他们仍然需要保持主线/干线代码的清洁，以防在整体更新完成之前需要快速更改它。所以他们创建了一个“facelift”分支并在其中工作。当开发人员提交 JavaScript 时，设计师可以提交 CSS 和图像。一旦完成 facelift 功能，他们就可以将其合并到主线/干线并发布。

他们需要个人分支的唯一原因是进行实验。例如，设计师正在尝试实现“滑动门”选项卡，在 IE6 中无法正确设置填充。如果他解决了问题，他可以将其合并到 facelift 分支中，否则，他会忽略它并继续回到 facelift 分支的其余设计。

- Soviut

Answer 3

在某种程度上，你使用的版本控制软件会引导你采取特定的方法。GIT面向开源贡献者，类似于“一个开发者”模型（分支甚至不是GIT中的概念。GIT更多地关注管理变更）。Clearcase更适合企业，因此您可以在一个分支上有多个开发人员，但每个开发人员都可以在自己的视图中进行操作。

我同意格雷格的答案，这更多是社交规划问题。许多开发人员在一个分支上会互相干扰。我曾经参与过一个项目，其中开发人员比单个源文件还要多 :)

- Mike Yam

---

我认为说“在Git中分支甚至不是一个概念”是具有误导性的，因为有一些重要的命令，比如git branch。 - Greg Hewgill

抱歉回复晚了。是的，Git支持分支，但不是传统意义上的。请阅读Joel On Software关于分支非概念的文章：http://www.joelonsoftware.com/items/2010/03/17.html。此外，搜索“从底层开始学习Git”。在抽象层面上，讨论分支、更新、修改和提交都很好，但真正的版本控制软件会以微妙和明显的方式影响您组织代码和团队的方式。我现在正在使用Perforce... 呕吐。 - Mike Yam

Answer 4

我认为合并分支可能存在问题（功能丢失或不一致），无论源代码控制工具有多好。我更愿意选择多个开发人员在单个主分支上工作。可以有其他分支用于生产错误修复或概念验证（POC），在这些分支中，合并应该尽快进行更改（错误修复）或很有可能不需要合并（POC）。

- Sherwin James