git - "Forking"单个主文件到版本控制下的多个变体

Question

我正在尝试确定我正在寻找的这个工作流程是否存在。也许我只是没有为这个概念想出正确的名称。

工作流程说明

一群同事正在组织一个梦幻牦牛赛车联盟。因为牦牛赛跑历史悠久并且深深 Root 于传统，所以我们对于遵循哪种主要规则集变化(西藏或蒙古)以及是否允许 body 涂油一直没有定论。最终决定联赛按地区划分，允许各子联赛在内部比赛中自行修改规则。

文件设置

当组织者起草规则文件时，他们决定应该有一个季后赛将遵守的主规则集，以及每个子联赛的独特修改版本内部观察。

管理人员制定了以下规则集:

Important rules for the whole yak racing league!
- racing yaks must wear red bandanas
- at most 2 bottles of oil allowed at pit stops
- no gongs
… etc

与此同时，藏亚联盟真的很想用金头巾，而且他们滥用酥油茶的问题比石油更大。管理人员没有复制主规则集，而是派生原始文档并应用更改，因此它看起来像这样:

Important rules for the Tibet yak racing sub-league!
- racing yaks must wear red *or gold* bandanas
- at most 2 bottles of butter tea allowed at pit stops
- no gongs
… etc

出于传统原因，蒙古人总是在星期四敲锣，因此他们的次级联赛版本的规则再次分支，并修改为如下所示:

Important rules for the Mongolia yak racing sub-league!
- racing yaks must wear red bandanas
- at most 2 bottles of oil allowed at pit stops
- no gongs (except on Thursdays)
- bow and arrows are allowed on racers for decoration
… etc

还有 20 个左右的子联赛。

merge 上游变更

几天后，法务部不知何故听说了火热的梦幻牦牛比赛，并坚持要求我们在所有规则集文件中添加法律免责声明，指出如果有足够的免责声明，他们可以允许 5 瓶油对组织者没有影响。此外，他们还认为全面禁止锣声很愚蠢(在延长的午休时间神秘地偷偷溜进去了)。主规则集现在看起来像这样:

Important rules for the whole yak racing league!
**super important legal disclaimer**
- racing yaks must wear red bandanas
- at most 5 bottles of oil allowed at pit stops
… etc

因为管理员足够聪明，在修改子联赛规则时派生这个主文件，而不是必须编辑所有 20 条左右的子联赛规则来反射(reflect)变化，他们只是 < strong> merge 对主文档所做的更改到子联盟规则中。

藏文版本 merge 成功(词层面)，现在是这样的:

Important rules for the Tibet yak racing sub-league!
**super important legal disclaimer**
- racing yaks must wear red *or gold* bandanas
- at most 5 bottles of butter tea allowed at pit stops
… etc

而蒙古文版本会有 merge 冲突，因为它也修改了“无锣”规则集。手动解决后，它现在看起来像:

Important rules for the Mongolia yak racing sub-league!
**super important legal disclaimer**
- racing yaks must wear red bandanas
- at most 5 bottles of oil allowed at pit stops
- bow and arrows are allowed on racers for decoration
… etc

就这样，一个乏味的任务被减少到 5 分钟的工作。然后，管理人员在当天剩下的时间里通过浏览 Reddit 来庆祝。

特征总结

我真的想不出有任何现有的系统(开源的，非单体的)可以做到这一点:

• 下游修改可能相对复杂，可能不是简单的插入，因此如果文档看起来笨拙且非常快速，模板系统将无法工作。

• 如果我们只是让每个文件都成为修改主文件的独立分支，那么会有太多不同的“分支”无法有效管理。可能很容易就会有数百种不同的变体。

• master 文件应该是独立的并且可以按原样修改。程序化生成下游文档是没有用的，因为这会将下游文档的所有依赖项编码到主文件中，并且很快就会变得无法维护。

问题

1. 我刚才描述的工作流程有合适的名称吗？
2. 什么样的工具可以促进这种工作流程？
3. 我是否可以使用现有的版本控制工具完成此任务？

Answer 1

这听起来与 git branches 非常相似.它们的概念很好地模拟了多个下游版本的概念，所有下游版本都派生自主版本。

在此示例中，管理人员将从制定基本规则开始:

git init
<Create the RULES file>
git add RULES
git commit -m "Initial rules"

然后西藏人根据原始分支(默认名称为 master)为自己的规则集创建一个分支:

git checkout -b tibet master
<Edit the RULES file>
git add RULES
git commit -m "Updates for Tibet"

同样，蒙古人也创建了自己的分支:

git checkout -b mongolia master
<Edit the RULES file>
git add RULES
git commit -m "Updates for Mongolia"

当律师们想要添加他们的免责声明时，他们会向 master 分支添加另一个提交。

git checkout master
<Edit the RULES file>
git add RULES
git commit -m "Add legal disclaimer"

为了使这些更改在分支上生效，必须将它们 merge 进来。

git checkout tibet
git merge master

不幸的是，由于 git 在行级而不是单词级运行，此时存在相当严重的 merge 冲突。在没有如此高修改密度的情况下，这会更好。

在 git 中，还有另一种“merge ”分支的方法，称为 rebase。在 tibet 分支上工作时，merging master 将导致 master 上的新提交在在 tibet 分支上进行的提交以及 rebase on master 将导致对 master 的新提交在在 tibet 分支上进行的提交之前应用。