合并并与Git并行工作

Question

我有一个git项目的几个分支，差异主要在于配置文件和blob。我想保持这些项目大部分合并并同步，因为一个分支上的开发也需要在其他并行分支上进行，但我不确定如何去做。

我见过的大多数git指南都没有真正谈论它，我不确定这种问题的最佳方法是什么。

Cherrypicking可能是一种选择，但当然这意味着在其中一个分支上工作的人几乎失去了各种变化的整个历史。如果有一种方法可以说“在这个巨大的项目中解决所有问题，除了在这个文件中定义的文件”之外的东西，那么这可能仍然有效。不知何故，它似​​乎仍然是错误的。

Answer 1

听起来你有一个带有几组配置文件的主分支。如果您只想在任何时间点在每个分支中保留一组此类文件，则可以维护一个主分支（包含所有公共文件），并将这些配置文件作为单独的提交提交到其他每个分支中。每当主分支更新时，您将需要针对它重新绑定其他分支，以便在最新更改之上应用其配置提交。

main-------update 
      \
       \--branch1 for env1 (commited config for env1)

变为

main---update-- 
               \
                \-- rebased branch1 for env1 (commited config for env1)

甚至

main---update------------------------------merged with branch1-- 
               \                        /                       \
                \-some work in branch1-/                         \-rebased branch1 for env1 (commited config for env1)

Answer 2

我会把你的项目分成两部分：

• 核心项目（所有共享代码）
• configuration / blob assets。

您的核心项目应该拥有最少数量的分支 - 只有您需要开发的分支。

您的配置仓库包含其余部分。

在“每个项目”的基础上，您可以使用Piston，submodules或puppet等工具合并来源（具体取决于项目的结构）。

通过此设置，您可以根据开发，测试和部署的需要将核心分支的数量降至最低。如果您的配置分支不同，因为您永远不必合并它们并不重要，并且它们之间的挑选更容易，因为您不必确定更改是核心还是配置。

它允许您拥有修复核​​心项目中特定标记或提交的每个应用程序配置，因此在测试等版本之间移动也应该更容易。

Answer 3

你真正想要的是一个很好的分支模型。你应该看一下this。它本质上是管理许多相关分支的好方法。它确实需要纪律，但从长远来看，这是值得的。

当然，我假设您的配置文件和blob不是很大（千兆字节）。如果是，您可能希望使用子模块在@Hamish建议的单独存储库中管理它们。