(第一段只是上下文，可能对实际问题有用，也可能没有用。我正在开发一个具有复杂文档格式和许多奇怪遗留问题的应用程序。我们有兴趣过渡到一种旨在与 Git(以及潜在的其他 VCS)很好地配合使用的新格式。我们正在为我们的格式开发自定义差异和合并驱动程序。
我想我已经偶然发现了一种巧妙的方式来支持一种向前兼容性，我很好奇是否有人知道世界上已经存在这种兼容性。
假设 Alice 正在处理版本 73 中的一个项目，她想聘请承包商 Bob 来帮助完成该项目，但他只有版本 67 的软件。我认为像下面的草图这样的VCS工作流程可以使他们的协作相当方便。
E---F---G---K"降级"分支 / \/---------------L "重新升级"提交 / \ A---B----C----D----H----J- 主干
Alice 明确将提交E从 73 降级到 67;这可能涉及删除一些数据和其他格式更改。鲍勃和爱丽丝同时工作了一段时间。Bob 以提交K结束，然后 Alice 通过运行具有以下输入的奇怪合并来重新升级降级的分支：
- 我们的 -
B - 他们的 -
K - 基地 -
E
这会在图中生成提交L，然后可以使用原版合并或变基或其他方式将其合并回去。
这对其他人有意义吗？在 Git 中实现它最干净的方法是什么？我正在想象某种cherry-pick，但如果鲍勃的分支有一些复杂的内部分支/历史黑客攻击，我不确定这是否正确。我认为我试图摆脱 Git 只是 Bob 的最后一次提交 (K) 和原始降级提交 (E) 之间的增量，然后将此增量应用于降级前提交 (B)
我认为最接近您在这里寻找的是"变基"：接受某人的更改，并在新的上下文中重新应用它们。
如果我们以开头带有"降级提交"E 的分支为起点，再加上另一个没有它的分支：
E---F---G---K <-- "downgraded" branch
/
A----B----C----D----H <-- trunk
在 git 中，"变基"允许我们在新基数 H 之上仅包含F、G 和 K 的变化的新分支：
E---F---G---K <-- "downgraded" branch
/
A----B----C----D----H <-- trunk
F2---G2---K2 <-- rebased changes
在 git 中，这将类似于git rebase F K --onto H，或者可以通过删除提交 E 的待办事项行来实现交互式变基。
或者，您可以变基到基础 B，然后执行正常合并：
E---F---G---K <-- "downgraded" branch
/
A----B----C----D----H---M <-- trunk
/
F2---G2---K2---+ <-- rebased changes
无论哪种方式，关键是您希望提交 E不在最终历史记录中。这比更简单的解决方案要干净一些，后者只是在过程结束时还原提交 E(撤消它所做的更改，创建一个新的提交"ER")，然后从那里合并：
E---F---G---K---ER---+
/
A----B----C----D----H----------M <-- trunk