这个产品开发的理想git分支策略是什么?

时间:2012-07-28 19:19:52

标签: git version-control merge branch branching-and-merging

假设我想在Twitter(神奇的开源)iPhone应用程序中添加一组相关但独立的功能。在应用程序中,您可以点击“家庭自动化”并显示一系列用于控制家中功能的按钮:灯光;电视;温度;灯罩;和音乐。

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

以下是一些假设:

  • 一个人(同一个人)将开发所有功能。
  • Twitter鼓励将变基作为其整合模式。
  • 所有功能都共享一些基本代码。

这是我的很好的东西模型,虽然我很想听听所有模特选项:

  • 代码审核者应该很容易在最后独立审核每个功能。换句话说,审查Lights代码的人不应该处理实施电视时所做的任何更改。

  • 每个功能在开发过程中都应该具有漂亮,干净的历史记录。在使用Lights时查看foo.m时,我应该只看到实现Lights的更改,而不是为实现电视所做的更改。

  • 即使我让电视处于凌乱/破碎状态,我仍然可以编辑和测试灯光。

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

我原来的本能是设置这样的分支:

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

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

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

例如,假设Automation分支中的共享UI代码具有函数num_buttons_to_render,该函数返回在Home Automation UI中呈现的按钮数。 Automation分支在此处返回0,因为它本身不实现任何功能。每个子分支(灯光,电视等)将返回1,因为它们仅实现各自的工作流程而不关心其他功能。但测试分支机构希望在这里返回5,因为它想要渲染所有5个自动化功能(灯光,电视,温度,阴影和音乐)。所以我想在测试分支中修复一次冲突,然后继续整合来自所有功能分支的后续更改。但是我甚至不清楚我能做到这一点,因为所有功能分支都使用了Twitter的开发标准所规定的rebase模型。

我是git的新手,所以我希望我在这里有所作为。如果没有,我会在这里积极回答任何后续问题。非常感谢你的帮助!

1 个答案:

答案 0 :(得分:0)

  

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

听起来似乎有道理。

  

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

所以要处理它们。最好早点而不是晚点。

  

但测试分支机构希望在这里返回5,因为它想要渲染所有5个自动化功能(灯光,电视,温度,阴影和音乐)。所以我想在测试分支中修复一次冲突,然后继续整合所有功能分支的后续更改。

为什么会发生冲突?

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

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

  

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

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