Question

我有一个案例，我工作的图书馆和我的工作的历史有所不同。在我分支包含库1.0的原始分支之后的一段时间，该库的开发人员发布了一个更新，我需要将其合并到最终结果中，保留我的更改。

对类似问题here已有答案。但是，许多有经验的Git用户不建议重新定位已公开的提交，并且有充分的理由：历史记录将被重写。附加到先前提交的任何内容都将丢失。保持对“簿记”的拉动请求将变得无用。那么，如果我想获得类似的结果，但保持历史正确，最好的方法是什么？更重要的是，让协作者的本地存储库保持一致？< / p>

我希望底层库的开发人员偶尔会发布新版本，并且每次都需要重复此过程，并且存在所有缺点。该图表看起来像这样：

product ------P1--P2--P3--P4'--P5--P6'
             /           /        /
library ---L1----------L2-------L3

任何？

Answer 1

使用{"mid_destinations": ["LA", "SF", "SD"], ...}代替git merge。这将创建一个“合并提交”而不是重写历史。

例如：

git rebase

Answer 2

我找到的答案是使用rebase，然后合并。 rebase是在临时分支上完成的。

product         P1--P2--P3------P4--P5--P6--P7------P8---
               /        |      /            |      /
integration   /         P3--P3'             P7--P7'
             /             /                   /
library ---L1------------L2------------------L3---

这可以这样实现：

$ git checkout library
$ git fetch --no-tags library master
$ git merge library/master
$ git checkout -b integration
$ git rebase library
$ git checkout product 
$ git merge --squash integration
$ git branch -D integraton

使用Git更新底层库但保留更改

2 个答案: