该产品开发的理想 git 分支策略是什么？

Question

假设我想为 Twitter（神奇的开源）iPhone 应用程序添加一组相关但独立的功能。在应用程序中，您可以点击“家庭自动化”并看到一屏用于控制家中功能的按钮：灯光；电视;温度;色调;和音乐。

在 Git 中开发这套功能的理想分支模型是什么？

以下是一些假设：

• 一个人（同一个人）将开发所有功能。
• Twitter 鼓励将变基作为其集成模型。
• 所有功能共享一些基本代码。

这里是我对模型的不错，尽管我很想听听所有模型选项：

• 代码审查员应该很容易在最后独立审查每个功能。换句话说，审查 Lights 代码的人不必处理在实现 TV 时所做的任何更改。

• 每个功能在开发过程中都应该有良好、干净的历史记录。在处理 Lights 时查看 foo.m 时，我应该只看到为实现 Lights 所做的更改，而不是为实现 TV 所做的更改。

• 即使我的电视处于混乱/损坏状态，我仍然可以编译和测试 Lights。

该模型的一个要求是我需要能够定期生成集成了所有功能的测试版本，就像它们将呈现给用户一样。换句话说，当我运行我的测试构建时，我会看到一个包含所有功能的家庭自动化屏幕。

我最初的直觉是这样设置分支：

Twitter
    \
     Automation
        \
         Lights
        \
         Television
        \
         Temperature
        \
         ...

换句话说，我将从 Twitter 分支创建“自动化”分支，其中包含所有家庭自动化功能使用的共享代码，包括用于访问功能的概览 UI 的存根代码（即上面提到的“全屏按钮”）。然后我会从自动化创建一系列分支，每个功能一个。

但是，在这个模型中，我无法理解如何在这个世界上生成完全集成的测试版本。我想我需要创建一些其他分支，定期将 Lights/Television/etc 分支合并在一起。但是这次合并会有明显的冲突。

例如，假设自动化分支中的共享 UI 代码有一个函数 num_buttons_to_render，它返回要在家庭自动化 UI 中呈现的按钮数量。自动化分支将在此处返回 0，因为它本身不实现任何功能。每个子分支（灯光、电视等）都将返回 1，因为它们只实现各自的工作流程，而不关心其他功能。但是测试分支想要在这里返回 5，因为它想要渲染所有 5 个自动化功能（灯光、电视、温度、阴影和音乐）。所以我想在测试分支中解决一次冲突，然后随着时间的推移继续整合所有功能分支的后续更改。但我什至不清楚我能否做到这一点，因为所有功能分支都使用 Twitter 开发标准规定的变基模型。

我是 git 新手，所以我希望我在这里能说得通。如果没有，我会在这里主动回答任何后续问题。非常感谢您的帮助！

Answer 1

我想我需要创建一些其他分支，定期将 Lights/Television/etc 分支合并在一起。

这听起来很合理。

但是这次合并会有明显的冲突。

所以对付他们。最好早点做。

但是测试分支想要在这里返回 5，因为它想要渲染所有 5 个自动化功能（灯光、电视、温度、阴影和音乐）。所以我想在测试分支中解决一次冲突，然后随着时间的推移继续整合所有功能分支的后续更改。

为什么会有冲突？

为什么不让每个功能都调用一个函数来注册自己，这会增加功能的计数。如果没有特征调用该函数，则计数为零。如果有人调用它，则计数为一。如果五个调用它，计数是五个。这似乎比在某个地方有一个硬编码的计数器更好，它在不同的分支中具有不同的值。

我认为您建议的分支模型没有任何问题，您描述的唯一问题与 git 无关，可以通过改进代码设计来解决。

但我什至不清楚我能做到这一点，因为所有功能分支都使用 Twitter 开发标准规定的变基模型。

也许我遗漏了一些东西，但我不明白为什么这是个问题。如果您定期从上游代码中重新设置自动化基础，然后从自动化（而不是上游）重新设置每个功能分支，那么从功能分支合并回自动化分支就没有问题。