使用Git更新基础库，但保留更改

我有一个案例，我创作的图书馆的历史和我的作品的历史发生了分歧。在我从包含library 1.0的原始分支分支分支出来一段时间后，该库的开发人员发布了一个更新，我需要将其合并到最终结果中，保留在此基础上所做的更改

类似的问题已经有了答案。然而，许多有经验的Git用户不建议对已经公开的提交进行重定，原因很好：历史记录将被重新编写。附加到先前提交的任何内容都将丢失。保留“簿记”的请求将变得无用。因此，如果我想获得类似的结果，但要保持历史记录正常，而且更重要的是，让合作者的本地存储库保持一致，那么最好的方法是什么

我希望底层库的开发人员会时不时地发布新的版本，并且这个过程需要每次重复，尽管有很多缺点。图中的内容如下所示：

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

---

有人吗？

使用

git merge

而不是

git rebase

。这将创建“合并提交”，而不是重新编写历史记录

例如：

git fetch
git merge library/master

---

我找到的答案是使用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

---

我知道合并将覆盖我对库所做的更改。不？不，不应该。是什么让你这么想的？比方说，你创建了一个文件，然后提交（a）。然后，删除该文件，并提交（B）。然后，你将一个包含该文件的分支合并到你位于B的头中。该文件将再次创建。这就是逻辑告诉我的。文件将不会被再次创建。Git比这更聪明。它知道您希望自己的更改保留在分支中。但是，如果由于分支发生分歧而在另一个分支中更改了文件，则会出现合并冲突（可以通过删除该文件来解决）。这与rebase的行为相同。试试看：

cd test

，

echo foo>a.txt

，

git init

，

git add a.txt

，

git commit

，

git branch library

，

git rm a.txt

，

git commit

，

git merge library

。Git说

已经是最新的。

文件没有被再次创建。这可能是因为他们有一个共同的祖先，并且库中的分支没有被再次添加。在您的例子中，

库

分支有一个历史记录，并且该历史记录没有显示“再次添加文件”。在我的情况下，图书馆由与我分开的其他人维护；新版本每次都作为一个整体出现。那么我在回答中描述的解决方案呢？到目前为止似乎有效的解决方案是：创建一个名为

integration

的

product

的临时分支，将其重新定位到

库

，然后将

integration

合并到

product

。哎呀，这将导致

集成

分支的新提交，这是重新基础的结果，将在

产品