我试图确定我正在寻找的工作流程是否存在。也许我没想出这个概念的正确名称。
一群同事组织了一场幻想牦牛赛车联盟。因为牦牛比赛有悠久的历史，并且在传统上有很大的步伐，所以我们一直关注哪个主要的规则变化（藏语或蒙古语），以及是否允许身体上油。最后，决定联盟将按地区细分，并允许每个子联赛进行内部比赛，以便在他们认为合适的情况下修改规则。
当组织者起草规则文档时，他们决定应该有一个主规则集，该规则集将在赛季后观察，并且每个子联赛都会有一个独特的修改版本。内部观察。
行政人员制定了以下规则集：
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个左右的子联赛。
几天之后，法律部门以某种方式抓住了热门幻想牦牛赛车行动的风，并坚持要求我们为所有规则文件添加法律免责声明，指出如果有足够的免责声明，他们可以允许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个左右的子联赛规则来反映变化，他们只是< strong>合并对主文档所做的更改子联盟规则。
藏文版成功合并（在单词级别），现在看起来像这样：
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
虽然蒙古语版本会发生合并冲突，因为它还修改了＃;;没有锣＆＃34;规则集。手动解析后，它现在看起来像：
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来度过余下的一天。
我无法想到任何可以实现此功能的现有系统（开源，非单片）：
下游修改可能相对复杂，也可能不是简单的插入，因此模板系统无法在文档看起来不那么快的情况下工作。
有太多不同的＆＃34;叉子＆＃34;如果我们只是使每个文件独立分支修改主文件，则进行有效管理。可能很容易有数百种不同的变化。
主文件应该是独立的，可以按原样修改。如果只是因为这会将下游文档的所有依赖关系编码到主文件中，并且很快就无法维护，那么在程序上生成下游文档是没有用的。
答案 0 :(得分：2)
这听起来与git branches非常相似。它们是一个很好地模拟多个下游版本概念的概念，所有这些概念都来自主版本。
在此示例中，管理人员将首先制定基本规则：
git init
<Create the RULES file>
git add RULES
git commit -m "Initial rules"
然后西藏人根据原来的分支（默认为名字大师）为他们自己的一套规则创建一个分支：
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"
当律师想要添加他们的免责声明时，他们会向主分支添加另一个提交。
git checkout master
<Edit the RULES file>
git add RULES
git commit -m "Add legal disclaimer"
为了使这些更改在分支上生效，必须将它们合并。
git checkout tibet
git merge master
不幸的是，由于git在行级别而不是单词级别上运行，因此此时存在非常严重的合并冲突。在没有如此高修改密度的情况下，这会更好。
在git中，有另一种方法可以合并＆＃34;分支称为rebase。在使用西藏分支时，合并主服务器将导致在在西藏分支上进行提交后应用主服务器上的新提交，并重新定位 on master将导致在在西藏分支上进行提交之前应用新提交。
答案 1 :(得分：2)
为什么不使用单独的文档，而不是使用修改过的版本（之后你必须同步/合并），
这将在很大程度上防止冲突。
如果单个文件是绝对必要的，您可以例如编写一个脚本，将常用规则和subleague特定的更改合并到一个 not 保存在git中的组合文件中。 （但生成它的组件是。）
答案 2 :(得分：1)
我刚才描述的工作流程是否有正确的名称？
是。你叫什么＆＃34;分叉＆＃34;通常被称为＆＃34;分支＆＃34;在这个规模。你叫什么＆＃34;合并＆＃34;通常被称为＆＃34;合并＆＃34;也是。因此，西藏的subleague已经分支他们自己的版本关闭主规则集，他们可以随时合并更新的主规则集。< / p>
什么样的工具可以促进这种工作流程？
（分布式）版本控制系统，如Git和Mercurial。
我可以使用现有版本控制工具完成此操作吗？
是的，只需将主规则集放在主分支上，让每个subleague从主分支开始拥有自己的分支。更新主规则集时，将主分支合并到每个子分支中。
据我所知，唯一的限制是这些系统可以在行级别合并但不能在单词级别合并。在您的示例中唯一的区别是，西藏团队必须手动合并来自主版本的at most 5 bottles of oil allowed at pit stops和来自他们自己版本的at most 2 bottles of butter tea allowed at pit stops。除此之外，您还可以获得所描述的所有便利。
答案 3 :(得分：1)
这种分支方案似乎出现了很多，对我来说它看起来像一个反模式。分支在短期（主题分支）或很少变化（发布分支/标记）时效果最佳。你在这里描述的设置 - 长期存在的分支 - 事物就像＆＃34;并行历史＆＃34;不断变得不稳定 - 它不会扩大规模。每个分支都具有对master的隐式依赖关系，这些依赖关系在以后进入合并时才会被隐藏。 ＆＃34;手动解决＆＃34;你在蒙古人的例子中描述的步骤当它只是一两行时并不是太糟糕，但只要一个分支试图保持任何严重的变化（比如整个文件中的英国和美国拼写），它会变成持续的痛苦。看看要求：
下游修改可能相对复杂，可能不是简单的插入......
......可能很容易有<数百种不同的变体。
工具无法为您处理。每次进行更改时，您都会遇到一百次合并冲突，并且所有这些冲突都需要一个人，因为计算机不知道您的意味着什么变化。
如果你认真对待数以百计的变化，我认为你有两个真正的选择：
1）承认这些是真正独立的文档，并且不再尝试自动化合并过程。这可能是自然会发生的事情。你的英国拼写维护者会意识到git rebase总是会遇到无用的冲突，他们会学会只读原始的差异并手工重做所有的变化。此时，您的分支机构基本上是独立的回购。
2）实际上生成所有不同的变体。部分原因是聪明并且认识到避免重复自己的方法。 （比方说，每个分支*可以有一个替换字典用于拼写更改，使用干净的共享逻辑来实际执行替换。）但更重要的部分是强制所有不同的变体共享结构。 ＆＃34;你想交换规则3和4？很难，你不能。因为我们不想维护另一个愚蠢的布尔/地图/界面。＆＃34;
好的我骗了你有三个：
3）使用git rerere。我基本上不知道它是如何工作的，但这是它解决的问题。我怀疑你最终会遇到许多非常重要的状态，这些状态实际上并不受版本控制，这让我感到害怕。
*如果你实际上与世代相关，那么变体就不再是分支了。它们应该是单个项目下的数据目录，具有一致的历史记录。