问什么是有效的git过程来管理我们的中央代码库？

EN

当我每天处理这类事情时，我感觉到了你的痛苦。我的情况是必须维护一个开源项目的多个客户版本，每个版本都有不同的插件、核心黑客等等。如果你有50个插件，那就不好玩了。

我还没有找到理想的(完全干净的)解决方案，但我对GitFlow的修改如下：

• 为每个客户的生产代码建立一个独立的分支(除了主)。使用master最终的所有功能版本，并且只将客户想要的合并到他们自己的版本中。
• 将开发(或添加插件等)保持在严格定义的修补程序和特性分支上，并将它们保留在适当的位置，即使一旦合并，您也可以在需要时合并到其他客户分支中。这也使得通过对日志进行处理来跟踪谁有什么特性变得更加容易了。
• 在开发新功能时，尽可能从所有客户的最新共同祖先开始。这意味着，您将能够合并为开发，然后掌握，但也合并到客户生产部门，而不(在理论上)造成冲突。
• 有一个主要的回购只为开发工作，它看起来像GitFlow。拥有另一个将你的dev repo作为远程设备，它用于存储客户分支，这样你的dev repo就有了干净的历史记录。
• 如果你真的不能轻松地解决一个冲突，并且需要立即挑选一个分支，那么就像这一样使用rebase -onto。只需确保在提交消息中清楚地显示了特性从何而来，以及为什么它没有正常合并。

使用git有一个额外的好处，因为我们现在可以在所有生产服务器上运行cron作业，检查git repos中未分阶段的文件。我们现在知道支持人员是否在没有告诉任何人的情况下就在服务器上讨论生产代码，这就避免了很多麻烦:)

希望这能帮上忙。

这个流程的主要错误是创建客户分支！唯一可能的分支是新的库特性，而不是客户特性。

它是一个公共库，所以它应该提供可以被客户类覆盖的API (来自特性请求)。但是这个定制的类应该在客户端主项目存储库中！

您的开发人员编写的代码耦合程度太高。阅读有关代码模块化、注入、接口等方面的文章，这将大大减轻您的痛苦！

第二件事是图书馆的适当流程。您应该开发版本化库(例如0.5、0.7、1.0、1.2)。库的问题是不同项目的版本使用情况不同。Git流并不以正确的方式支持这一点(只支持最后的版本和当前的开发)。我只是在为这种流寻找合适的支持工具。

总结-你主要的痛苦在于错误的库代码。您的开发人员必须使用默认行为编写代码，不要使用客户端行为，并使用API允许覆盖默认行为。

共享代码的开发和维护成本更高。它必须在多个场景中工作；它必须向后兼容；它应该有测试用例，以确保更改不会破坏现有的客户端。

通常情况下，只有在三个或三个以上的地方使用共享功能才值得。

developers adding custom functionality in the context of their own project.

一个或两个项目的自定义更改不应使其成为共享代码。如果允许这样做，共享代码将迅速增加复杂性，直到无法维护的程度。没有任何工作流能够帮助解决这个问题。