使用 Git 或 TortoiseGit 合并一系列修订

Question

我正在尝试使用 git 或 TortoiseGit 将存储库主分支中所做的更改合并到开发分支中。我知道我可以使用 git pull 或 合并，但这会一次将太多更改合并到开发分支中，并使解决冲突变得更加困难。

如果我使用 SVN 或 TortoiseSVN，我可以一次一点点地合并来自主干的更改，而不是一次全部合并，使用一系列修订进行合并。我可以用 git 或 TortoiseGit 做类似的事情吗？也就是说，我可以将一系列修订合并到我的开发分支中，而不是一次合并所有更改吗？

Answer 1

摘要

从命令行使用 Git，您可以将 feature 重新设置为 master：

git rebase master feature

# Now force push the changes to your remote
git push <remote> feature --force

警告：不要不小心强制推送重新设置基准（重写）提交/分支如果您与其他人共享这些提交/分支，因为您将导致与他们基于旧版本的提交/分支的任何更改发生冲突。在（非常）小的团队中可以以这种方式工作，但需要良好的协调。

您还可以使用 --onto 标志来指定范围，其中 是范围的唯一开始：

git rebase --onto master <start commit> feature

最后，cherry-pick 实际上可以接受一系列参数。签出 master 分支后：

# Cherry-pick all commits from `<start commit>`
# exclusive, not included) to feature:
git cherry-pick <start commit>..feature

详细说明

我最初的目标是能够将我的 feature 分支与 master 中所做的更改同步，但我不想只合并到 master 中，因为它导致了太多必须立即解决的冲突。我只是希望能够逐渐合并更改，这样我就可以将冲突分解为更小、更易于管理的部分。

输入 git rebase

最好的方法实际上是 git rebase。事实上，这很完美。它将执行的操作是获取我在 feature 中所做的所有提交，并以相同的顺序制作这些提交的副本，除了它在目标分支的最新版本之上重新提交它们，在我的例子中，它是master。

这很重要，原因有二：

1. 这相当于将 master 合并到 feature 中。为什么？因为 feature 基本上是在 master 的最新版本之上重新创建的……所有 master 的提交现在都存在于 的历史记录中>feature，包括 master 中 feature 尚未提交的提交。

2. Git 按顺序一次一个重新应用提交，因此如果存在任何冲突，它们会以几个更小、更易于管理的部分引入到流程中，一次一个，这正是我希望做的！

这就是它在视觉上的样子（示例改编自 官方 Linux 内核 Git 文档）：

      A---B---C feature
     /
D---E---F---G master

在上面的示例中，自从我分支 以来，在 master 上提交了 F 和 G >功能关闭它。我想要做的是将这些更改同步到 feature：

git rebase master feature

现在我的分支如下所示：

              A'--B'--C' feature
             /
D---E---F---G master
     \
      A---B---C (no branch)

提交 A 到 C 已重新创建为 A' 到 C' 位于最新版本的 master 之上。旧的提交仍然存在于 Git 存储库中，但由于没有分支指针引用它们，因此它们最终将被 Git 进行垃圾收集。

Answer 2

是的，你可以这样做。假设您的存储库如下所示：

      master
 A---[B]
  \
   \                       feature
    (c1)---(c2)---(...)---(c100)

您想要将 feature 分支合并到 master 中，但那里有很多提交。相反，让我们创建一个新分支 tmp ，它指向 feature 上的早期提交：

 git branch tmp c2

 A---[B]
  \
   \        tmp               feature
    (c1)---[(c2)]---(...)---(c100)

现在 tmp 指向 c2 。现在我们可以只将提交 c1...c2 合并到 master 中，而不考虑 c3...c100：

 git checkout master
 git merge tmp

现在，将 tmp 移动到下一批提交（我们需要-f来强制它，因为tmp已经存在）。例如，如果我们现在想移动到 c6，请使用：

 git branch -f tmp c6

重复此操作，直到您要合并的所有提交都在其中。

Answer 3

注意：约翰的答案是正确的；这只是基于评论中的后续问题的进一步解释 - 我只是需要更多空间:)

我喜欢不必创建临时分支来合并提交的想法，但使用 git merge的问题是它只合并在单个修订中，不是它们的范围（正确吗？）。如果我有 100 个修订要合并，我是否必须使用该命令 100 次？

不，在 Git 中，历史总是相连的。因此，如果您将一个提交合并到 master 中，并且在 master 的共同祖先和该提交之间存在更多提交，那么这些提交将被完全保留。与 SVN 不同，Git 保留对先前提交的完整引用（具有无限数量的指针，因此您可以一次合并多个分支）。所以最后，你总是会看到一个分支从哪里开始，它发生了什么，之间合并了什么，以及它在哪里合并回主分支——只有名称（或者更确切地说标签 ) 分支不会保留（自动合并文本除外，如果这算 ^^）。

因此，您的历史记录可以如下所示：

* -- A -- * ---------- * ----- * -- * -- M [master]
      \
       \
        B1 -- B2 -- B3 -- B4 -- B5 -- B6 -- B7 -- B8 -- B9 [br]

假设您想要将 B9 （分支 br 上的 HEAD 提交）合并回 M 中，其中是 master 分支所指向的位置。通过直接合并，您将得到以下结果（# 是合并提交）：

* -- A -- * ---------- * ----- * -- * -- M ---------------- # [master]
      \                                                    /
       \                                                  /
        B1 -- B2 -- B3 -- B4 -- B5 -- B6 -- B7 -- B8 -- B9 [br]

因此，即使您删除分支指针 br，您仍然可以看到发生在那个单独的分支。

或者，如果您想分多个步骤进行合并，您可以像这样轻松地合并它：

* -- A -- * -- * -- * -- * -- M -- #---------- # --------------- # --- # [master]
      \                           /           /                 /     /
       \                         /           /                 /     /
        B1 -- B2 ------------ - B3 -- B4 -- B5 -- B6 -- B7 -- B8 -- B9 [br]

同样，您始终可以回顾整个树，以及在分支上进行的所有单独提交 - 即使您删除了分支（同样，只是删除了指针）。

因此，也许这个解释也会告诉您，您不一定需要以如此小的步骤进行合并。在合并过程中您永远不会丢失信息，因为您始终可以回顾所有提交。