使用GIT维护应用程序的不同变体

Question

我目前正在为几个客户开发一个应用程序。代码库在两者中有99%的共同之处，因为它是一个发票应用程序，并且原理是相同的。但是，每个“版本”都有一些次要的特殊需求，这些需求不容易通过设置来控制(表单中的不同字段等)。

我想用GIT来管理主要的代码库，以及“版本特定”的文件，它们最多只能有4-5个文件。我一直在阅读建议，我发现一个好的方法是有一个包含所有代码库的主分支，每个版本有一个特定的分支，合并从主到每个特定分支的共同更改，并在每个分支中提交特定的更改。

这是一种好的方法吗？我不确定如何从我现在所拥有的东西中到达那里:如果我现在分支，然后从主分支中删除特定于版本的文件，它不会将删除合并到特定的分支吗？

谢谢!

Answer 1

您可以将一个分支用于公共代码，然后将其合并到每个项目分支中，但这对于近似git submodule或subtree来说似乎是一种非常奇怪的方式。如果你有一个很好的子目录结构，我强烈建议你使用git subtree。

子模块

在处理一个项目时，您需要在其中使用另一个项目，这种情况经常发生。可能是第三方开发的库，也可能是您单独开发并在多个父项目中使用的库。在这些场景中会出现一个常见的问题:您希望能够将这两个项目视为独立的项目，但仍然可以在另一个项目中使用其中一个项目。

来源：http://www.git-scm.com/book/en/v1/Git-Tools-Submodules

子树合并

..。子树合并的思想是，您有两个项目，其中一个项目映射到另一个项目的子目录，反之亦然。当您指定一个子树合并时，Git足够聪明，能够识别出一个是另一个的子树，并适当地合并-这是相当令人惊讶的。

来源：http://www.git-scm.com/book/en/v1/Git-Tools-Subtree-Merging

Answer 2

我看到这在相对较小的规模、有限的部署数量、一个小的、训练有素的团队中工作得很好，并且在刷新之间和在自定义分支上没有太多的提交。

如果你看到这种扩展，你将不得不及时考虑某种形式的模块化/插件架构，以避免陷入这种境地。

当您看到集成更改开始受损时(通常在拉取最新的主版时会发生损坏)，那么这应该是您的危险信号。