如何在GIT中将一个分支合并到另一个分支？

Question

让我详细解释一下这个问题。

我有一个主 git 分支，在上面创建了一个新的侧分支 bug10101010，现在我不想将 bug10101010 合并到主分支。到目前为止一切都很好。 现在我有同一产品的不同分支，名为legacy。我不想将 bug10101010 合并到 GIT 中的旧分支。

有什么想法吗？

我不能直接合并它，因为分支 bug10101010 是从主分支中分离出来的，在遗留版本中我只需要分支 bug10101010 与其父分支之间的差异。

Answer 1

您应该在此处使用 git rebase --onto 并指定一个范围。
（请参阅 git rebase 手册页：

将基于一个分支的主题分支移植到另一个分支，假装您使用rebase --onto从后一个分支分叉了该主题分支。

）。

当然，这会将您的 bug10 分支移动到 legacy 分支之上，这不是您想要/需要的。

因此，一种解决方法是在克隆存储库中执行变基操作，然后合并该“增强”遗留分支（克隆存储库中的分支，与bug10 修改）到本地和当前的legacy 分支（您要修改的分支，同时保留 bug10独自的）。

现在：

• 这涉及到一个额外的存储库（这可能会导致磁盘空间限制）
• 总而言之，这相当于定义一个补丁并将其应用到legacy分支，所以其他答案（补丁）是有效（并且更简单）。
• 我在这种方法中看到的唯一优点是有机会定义一个遗留环境，在该环境中您可以在仅推送该分支legacy之前重新设置您想要的内容（例如bug10提交）到您的原始存储库（您不会推送 bug10，因为它的历史记录将被完全重写！）

我只是想看看它是否有效，所以...让我们测试一下该方法。
（Git1.6.5.1，在旧的 XP SP2 上，具有 Powershell 1.0 会话，因为 Start-Transcript 命令)

---

PS D:\> mkdir git
PS D:\> cd git
PS D:\git> mkdir tests
PS D:\git> cd tests
PS D:\git\tests> git init mainRepo

^{我喜欢我不再需要先创建 git repo 目录，然后在其中输入 git init ！ 自 1.6.5 起：}

“git init”学会了在给定额外参数时将 mkdir/chdir 放入目录（即“git init this”）。

^{这太棒了！}

让我们创建 3 个文件，用于 3 个不同的目的。
（为了举例，我将在每个分支中单独保留文件修改：在此处合并或变基期间不会发生冲突。）

PS D:\git\tests> cd mainRepo
PS D:\git\tests\mainRepo> echo mainFile > mainFile.txt
PS D:\git\tests\mainRepo> echo contentToBeFixed > toBeFixedFile.txt
PS D:\git\tests\mainRepo> echo legacyContent > legacy.txt
PS D:\git\tests\mainRepo> git add -A
PS D:\git\tests\mainRepo> git ci -m "first commit"
PS D:\git\tests\mainRepo> echo firstMainEvol >> mainFile.txt
PS D:\git\tests\mainRepo> git ci -a -m "first evol, for making 1.0"
PS D:\git\tests\mainRepo> git tag -m "1.0 legacy content" 1.0

此时， git log --graph --oneline --branches 返回：

* b68c1f5 first evol, for making 1.0
* 93f9f7c first commit

让我们构建一个legacy分支

PS D:\git\tests\mainRepo> git co -b legacy
PS D:\git\tests\mainRepo> echo aFirstLegacyEvol >> legacy.txt
PS D:\git\tests\mainRepo> git ci -a -m "a first legacy evolution"

我们返回master，进行另一个提交，我们将标记为“2.0”（一个需要修复一些错误的版本！）

PS D:\git\tests\mainRepo> git co -b master
PS D:\git\tests\mainRepo> git co master
PS D:\git\tests\mainRepo> echo aMainEvol >> mainFile.txt
PS D:\git\tests\mainRepo> git ci -a -m "a main evol"
PS D:\git\tests\mainRepo> echo aSecondMainEvolFor2.0 >> mainFile.txt
PS D:\git\tests\mainRepo> git ci -a -m "a second evol for 2.0"
PS D:\git\tests\mainRepo> git tag -m "main 2.0 before bugfix" 2.0

我们有：

* e727105 a second evol for 2.0
* 473d44e a main evol
| * dbcc7aa a first legacy evolution
|/
* b68c1f5 first evol, for making 1.0
* 93f9f7c first commit

现在我们做一个bug10 错误修复分支：

PS D:\git\tests\mainRepo> git co -b bug10
PS D:\git\tests\mainRepo> echo aFirstBug10Fix >> toBeFixedFile.txt
PS D:\git\tests\mainRepo> git ci -a -m "a first bug10 fix"
PS D:\git\tests\mainRepo> echo aSecondBug10Fix >> toBeFixedFile.txt
PS D:\git\tests\mainRepo> git ci -a -m "a second bug10 fix"

让我们在主分支上添加最终提交

PS D:\git\tests\mainRepo> git co master
PS D:\git\tests\mainRepo> echo anotherMainEvol >> mainFile.txt
PS D:\git\tests\mainRepo> git ci -a -m "another main evol"

主存储库的最终状态：

* 55aac85 another main evol
| * 47e6ee1 a second bug10 fix
| * 8183707 a first bug10 fix
|/
* e727105 a second evol for 2.0
* 473d44e a main evol
| * dbcc7aa a first legacy evolution
|/
* b68c1f5 first evol, for making 1.0
* 93f9f7c first commit

在这个阶段，我不会在 mainRepo 中进行任何进一步的操作。我只会克隆它来进行一些测试。如果这些失败，我可以随时返回此存储库并再次克隆它。

第一个克隆实际上是强制性的，为了执行我们的 git rebase --onto ，

PS D:\git\tests\mainRepo> cd ..
PS D:\git\tests> git clone mainRepo rebaseRepo
PS D:\git\tests> cd rebaseRepo

我们需要克隆的存储库中的两个 mainRepo 分支：

PS D:\git\tests\rebaseRepo> git co -b bug10 origin/bug10
PS D:\git\tests\rebaseRepo> git co -b legacy origin/legacy

让我们仅对 bug10 进行变基（即 < 之后的所有提交） code>2.0 标签一直到 bug10 分支的 HEAD）：

PS D:\git\tests\rebaseRepo> git co bug10
PS D:\git\tests\rebaseRepo> git rebase --onto legacy 2.0
First, rewinding head to replay your work on top of it...
Applying: a first bug10 fix
Applying: a second bug10 fix

此时 bug10 已在顶部重放遗留 没有所有其他中间提交。
现在，我们可以将 legacy 的 HEAD 快进到重播的 bug10 分支的顶部。

PS D:\git\tests\rebaseRepo> git co legacy
Switched to branch 'legacy'
PS D:\git\tests\rebaseRepo> git merge bug10
Updating dbcc7aa..cf02bfc
Fast forward
 toBeFixedFile.txt |  Bin 38 -> 104 bytes
 1 files changed, 0 insertions(+), 0 deletions(-)

内容符合我们的需要：

• 我们确实拥有所有遗留内容

：

PS D:\git\tests\rebaseRepo> type legacy.txt
legacyContent
aFirstLegacyEvol

 

• main 分支的内容仅存在于 1.0 标记（legacy 分支的根），并且不再有强>。

 

PS D:\git\tests\rebaseRepo> type mainFile.txt
mainFile
firstMainEvol

 

• bug10 修复如下：

 

PS D:\git\tests\rebaseRepo> type toBeFixedFile.txt
contentToBeFixed
aFirstBug10Fix
aSecondBug10Fix

 

就是这样。
我们的想法是在原始存储库中提取“增强”legacy 分支，该分支的 bug10 仍保持不变（即仍从 2.0 开始） code> 标记，并且不会像我们在 rebaseRepo 上那样在任何地方重播。
在此克隆的存储库中，我跟踪 origin/legacy 分支，以便在其上合并另一个远程源的 legacy 分支：<代码>rebaseRepo。

PS D:\git\tests\rebaseRepo> cd ..
PS D:\git\tests> git clone mainRepo finalRepo
PS D:\git\tests> cd finalRepo

PS D:\git\tests\finalRepo> git co -b legacy origin/legacy

在这个原始存储库中（我克隆它只是为了不弄乱 mainRepo 的状态，以防我还有其他一些实验要做），我将声明 rebaseRepo 为远程，并获取其分支。

PS D:\git\tests\finalRepo> git remote add rebasedRepo D:/git/tests/rebaseRepo
PS D:\git\tests\finalRepo> type D:\git\tests\finalRepo\.git\config
[remote "origin"]
    fetch = +refs/heads/*:refs/remotes/origin/*
    url = D:/git/tests/mainRepo
[branch "master"]
    remote = origin
    merge = refs/heads/master
[branch "legacy"]
    remote = origin
    merge = refs/heads/legacy
[remote "rebasedRepo"]
    url = D:/git/tests/rebaseRepo
    fetch = +refs/heads/*:refs/remotes/rebasedRepo/*

PS D:\git\tests\finalRepo> git fetch rebasedRepo
remote: Counting objects: 8, done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 6 (delta 3), reused 0 (delta 0)
Unpacking objects: 100% (6/6), done.
From D:/git/tests/rebaseRepo
 * [new branch]      bug10      -> rebasedRepo/bug10
 * [new branch]      legacy     -> rebasedRepo/legacy
 * [new branch]      master     -> rebasedRepo/master

我们现在可以更新legacy，而无需触及bug10：

PS D:\git\tests\finalRepo> git merge rebasedRepo/legacy
Updating dbcc7aa..4919b68
Fast forward
 toBeFixedFile.txt |  Bin 38 -> 104 bytes
 1 files changed, 0 insertions(+), 0 deletions(-)

只要需要提交新的bug10，您就可以根据需要多次重复该过程。在旧的legacy分支之上重放，不包括所有中间提交。

Answer 2

这很难做到。 Git 保存合并历史记录，如果你“cherrypick”并指向 bug10101010 中的提交作为父项（表明你已经完成了合并），Git 会假设之前的所有提交（回到它们拆分的点）都已合并为出色地。当您想要进行“真正的”合并时会给您带来问题。

另一方面，您可以从该（且仅该）特定提交手动生成补丁。但是，当您稍后进行“真正的”合并时，这也会给您带来问题，因为它会尝试应用您手动处理的提交两次。

但话又说回来，由于一个分支被命名为“Legacy”，我怀疑您无论如何都不打算进行真正的合并，在这种情况下，您几乎可以自由地按照自己的意愿进行合并。

这是关于该主题的有趣博客文章。

Answer 3

使用 git-diff 然后 git-apply？