Git 如何在不获取主分支中的主题提交的情况下重新设置主题分支的基础

我有一个相当标准的用例，我将在主分支（master）的基础上创建一个主题分支，接下来，我希望对自创建主题分支以来引入master的主题分支进行更改，以确保我拥有最新的代码。我不喜欢在我的主题分支中合并提交，所以我更喜欢在不将主题分支中的更改放到主分支中的情况下，将主分支中的提交重设为主题分支。有没有一种方法可以在不将来自主题的提交也应用于master的情况下，通过rebase将更改从master转移到主题分支？还是说合并是我唯一的选择

---

谢谢。

一个普通的

rebase

可以做到这一点。如果您是主题分支的唯一开发人员，并且您只使用一个系统进行开发（以及一个用于备份的中央服务器），那么在执行过程中强制推送重新设置基础的主题分支是非常容易的

例如，昨天您有：

        F - G   <-- topic
      /
... E - H - I   <-- master

这是什么意思

        F - G   [abandoned]
      /
... E - H - I   <-- master
             \
              F' - G'   <-- topic

好吧，如果没有“其他人”，这两种情况都不可能发生，你很好

但是如果还有其他人呢？ 你需要另一种选择。您当然可以使用合并或樱桃采摘。但是你仍然可以使用rebase，前提是你和所有“其他人”都同意这可能发生。然后，您需要（或至少强烈想要）一些更新的git工具：

• --分叉点

• ——租赁强制执行

--fork point

所做的是对

git-rebase

进行智能化处理，这样您就可以获得一个移动的主题分支，并使用您自己的重登录来确定复制了哪些提交，这样您就可以只重定您自己的工作的基础，而不是其他人的工作的基础。这并不完美，但这是一个很大的帮助

--force with lease

的作用也许是最重要的。假设您正在执行上面的

rebase

，而其他人已经执行了rebase并添加了一个新的提交

J

。当您转到重新设置基址的

主题
时，您告诉您的git和中央服务器git您想让
主题
指向服务器上的提交
G'
，但前提是当前它指向服务器上的提交
G
。在这种情况下，“其他人”用租约推送击败了您，因此在服务器上，
主题现在指向提交
J
。这会使您的lease push强制失败，然后您可以运行
git fetch
，找出发生了什么，并相应地协调您自己的工作

（请记住，这些大写字母中的每一个都代表一些独特的40个字符的SHA-1。如果您在复制的
F'
和
G'
上有一个新的commit，您仍然可以假设服务器使用了您在commit
G
中拥有的ID，并且所有这些都可以工作：要么服务器确实拥有该ID，因为没有其他人拥有该ID。）s被推，或者它没有被推，因为其他人已经推了。这是仅有的两种服务器端可能性。不过，您必须非常小心，因为在您的
git获取后
yor
origin/topic
现在也指向提交
J
）
这就是rebase所做的。这可能会有所帮助。请记住，rebase需要任何其他开发人员强制更新。因此，似乎我唯一能从master更改主题分支的选项是合并或cherry-pick。你没有很好地解释你为什么这么想，因此我们无法进一步提供帮助。我认为我非常清楚r-我希望将提交从主分支转移到我的主题分支，自我第一次干净地创建主题分支以来，这些主题分支一直被提交到主分支，这样我就不必每次都创建合并提交，这样历史记录就完好无损了。
        F - G   [abandoned]
      /
... E - H - I   <-- master
             \
              F' - G'   <-- topic

... E - H - I   <-- master
             \
              F' - G' - J   <-- topic