我们公司有一个项目，我们制作了一个系统，然后卖给其他公司，我们遇到一个问题，就是项目管理的问题，每个客户都应该有自己独特的系统，我们的系统也在开发中怎么管理这些项目的开发。
我们已经尝试过使用git分支功能，客户是我们掌握自己开发项目的分支，为客户在分支上面定制。
每个主更新，首先在分支变基中使用。
但是过了几天，因为master的频繁改动，rebase我们遇到了很多的冲突。当时我们花了很多时间解决冲突。时间成本太高了。
我们应该怎么做？
问问题
59 次
1 回答
1
这是一个很难解决的问题。以下是一些想法：
你的编码风格越干净，在 master 之上重新定位客户端就越容易。像 Bob Martin 的“Clean Code”这样的书籍有很多关于如何编写简单、干净、可重用的代码的信息。所有这一切的要点之一是干净的代码很容易更改。这不会消除修复冲突的需要，但可能会使它们更容易修复。像 Michael Feathers 的“有效地使用遗留代码”或 Fowler、Beck 等人的“重构：改进现有的设计”这样的书，可能会帮助你弄清楚如何清理 master 以便更好地使用分支，但我不能保证。
好的抽象会有所帮助。如果你有 10 个客户需要的东西，不要把它放在 10 个客户分支中。尝试将它 - 干净，不破坏其他东西 - 移动到 master，然后简单地在分支中使用该新代码。其他分支机构/客户应该能够安全地忽略它。
尝试将客户细节从代码转移到数据。如果您在代码中有任何客户特定的设置，请将它们移出文本/JSON/YAML 文件。每个客户分支都有自己的这些文件版本，而主分支则没有。现在您可以处理使用这些设置的代码部分，并让它随着需求的增长而增长，然后所有客户都将拥有该代码，但这些设置将有助于决定每个分支中实际发生的情况。这种方式没有冲突。
将客户特定的功能移动到插件或帮助脚本中。这就像上面的＃3。如果文件甚至不存在，您就不会与 master 发生冲突。如果客户需要自定义格式化程序，请将 formatter.foo 放在他们的分支上，然后在该分支的主代码中调用该格式化程序。如果您在主程序中遇到冲突，至少它们只会在一个导入行上，或者在调用该导入文件中的函数的行上。
另外，我不会为此使用rebase。我会继续将 master 重新整合到其他分支中。Rebase 有点违反合同。它说“这个分支从这里开始”。这不是真的，而且你越频繁地变基长寿命分支，它就越不真实。Git 很好地完成了每次提交中的所有更改，因此代码仍然有效，但代码注释可能开始不同步，因为它们不断移动到可能重构的部分之上。评论可能会说“修复了 foo 中的问题”，但 30 次提交前 'foo' 被重命名为 'bar'，现在阅读该消息的人不会在代码中看到 foo，因为变基会擦除所有 'foo'离开。合并将基地留在原处，并让您正确了解最初制作事物时的历史位置。此外，分支获得的时间越长，将所有提交重新定位到顶部所需的时间就越长。合并只会带来新的东西。
于 2013-09-14T06:25:48.913 回答