Git 关于代码管理的困惑,求指点。

liwei78 · 2014年05月31日 · 最后由 liwei78 回复于 2014年05月31日 · 2668 次阅读

情景:

我们的代码叫 CODE,它在 master 上。我们现在有了 A,B,C 三个客户,我们在这个 CODE 上提供功能。

现在,我们为 A,B,C 分别提供了 b_branch,和 c_branch,A 继续使用 master。

我开发了一个功能,从 master branch 出 feature_1,完成后 PR 回 master。一切正常。

但是,B 和 C 也要用这个功能,B 和 C 的代码早就在自己的分支上走的很远了,feature_1 PR 到 b_branch 有大量的冲突。c_branch 也是一样。

我的问题是:从一开始,我该如何管理这种情况下的开发呢??我这里不是讨论 git 如何操作,而是想求教,在我们的软件开发中,面对此种局面,如何在开始的时候做好准备。

简单的讲,我们有一套代码,应对各种需求,该如何管理我们的代码?

补: 更形象的讲:A 说,我们在 M 功能上加审核(master),B 说,我们在 M 功能上加字段,但是不要审核,C 说,我们又要审核又要字段。

无他,把预计的功能

  • 插件化
  • 组件化
  • 后台管理特性开关

放入主线,等产品慢慢成熟。

抽取出通用模块,甚至封装成 gem,然后利用配置文件来设置不同的需求

这种客户订制的最好不要升级,如果要坚持要升级到最新版本,那么客户的每个需求最好做成 gem

与其说是版本控制问题,不如说是设计问题。笼统地讲,就是要让设计更加模块化,职责明确,高内聚,低耦合,依赖倒置,可拓展性,可配置性。。。嗯,然后就是一大堆软工名词。当我没说。

如楼上几位的建议,把这些 feature 分离出来。code base 就像一个插线板,用主分支维护。特殊的 feature 就是各种插头,按需插拔。

最佳理论是不要面向客户产生那么多的分支,所有功能都做成独立 gem,或者可以启用的模块。

实际情况是不同客户的需求可能有矛盾,而且完全组件化的成本太高,再没有规模的情况下,几个客户需要,按组件化的方式做完美可能收不回本。

所以,最佳实践是收 3 次费用,在 ABC 分支上单独完成该功能。

痛苦的经历告诉我,除非到了万不得已。不要 branch。如果非要 branch 而且要跟着 master 走。那需要一个 专人 负责维护 branch。这个专人,必须资深靠谱。

恩恩。我更倾向 fork 一个新的 repo,再按照 master - develop - release 去管理。至于差别,就各自存在自己的 repo 上。至于麻烦程度,貌似都麻烦的很。。。

感谢楼上及楼下各位,儿童节快乐。。

git 的 branch 太便宜了,以致于基于实际项目各种不种需求场景进行多 branch 开发。然后头头还想 merge 回来。我后来发现每多一个 branch,就多一份人力维护。branch 远了,再回去对照,头都大了,merge 真是不那么好处理的的,尤其是我经常喜欢重构一下代码,这改改那动动的那种 git 提交。

#8 楼 @qichunren 更加潜在的问题是,已经测试通过的东西,再 merge 到别的 branch 出现冲突,可能还会带来新的错误,到头来还得重新测试。这个很可怕,尤其是即将上线之前。

多 branch 维护考验的是测试的程度。肉测的灾难。

需要 登录 后方可回复, 如果你还没有账号请 注册新账号