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

Question

假设我想为Twitter的(神奇的开源) iPhone应用程序添加一组相关但独立的功能。在应用程序中，您可以点击“家庭自动化”，并在屏幕上显示大量按钮，用于控制家里的功能:灯光、电视、温度、阴影和音乐。

Git中开发这套特性的理想分支模型是什么？

以下是一些假设：

• 一个人(同一个人)将开发所有的功能。
• Twitter鼓励将其重新定位为其集成模式。
• 所有的特性都有一些基本代码。

下面是我的很适合这个模型的，尽管我很想听听所有的模型选项：

• 代码评审人员应该很容易在结束时独立地检查每个特性。换句话说，审查灯光代码的人不应该必须处理在实现to时所做的任何更改。
• 在开发过程中，每个功能都应该有良好的、干净的历史。在看foo.m时，我应该只看到为实现灯光而做的更改，而不是为实现电视而做的更改。
• 我仍然可以编译和测试灯光，即使我离开电视在一个混乱的/坏的状态。

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

我在这里最初的本能是像这样设置树枝：

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

换句话说，我会从Twitter创建“自动化”分支，它包含所有家庭自动化功能使用的共享代码，包括用于访问这些功能的概览UI的存根代码(即上面提到的“屏幕按钮”)。然后我会创建一系列来自自动化的分支，每个特性都有一个分支。

然而，在这个模型中，我很难理解如何在这个世界上生成完全集成的测试构建。我想，我需要创建其他分支，定期合并灯光/电视/其他分支机构。但是在这次合并中会有明显的冲突。

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

我对git还不熟悉，所以我希望我在这里说得有道理。如果没有，我会主动回答任何后续问题。非常感谢你的帮助！

Answer 1

我想，我需要创建其他分支，定期合并灯光/电视/其他分支机构。

听起来很有道理。

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

那就跟他们打交道吧。最好早点做，不要迟做。

但是测试分支会希望在这里返回5，因为它希望渲染所有的5个自动化功能(灯光、电视、温度、阴影和音乐)。因此，我希望修复测试分支中的冲突一次，然后随着时间的推移，继续集成来自所有特性分支的后续更改。

为什么会有冲突呢？

为什么不让每个特性调用一个函数来注册自己，从而增加功能的数量。如果没有任何功能调用该函数，则计数为零。如果有人叫它，伯爵就是一人。如果是5点，计数是5。这似乎比在某个地方有一个硬编码计数器更好，后者在不同的分支中具有不同的价值。

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

但我甚至不清楚我是否能做到这一点，因为所有的特性分支都在使用Twitter开发标准所规定的重基模型。

也许我错过了什么，但我不明白为什么这是个问题。如果您定期从上游代码重新建立自动化基础，然后从自动化(而不是从上游)重新建立每个功能分支，那么从特性分支合并回自动化分支就没有问题了。