Question

在这种情况下，我们有master，fix-a和fix-b个分支。

| A fix-a wip (HEAD of fix-a)
|/
| 
| B fix-b wip good enough (HEAD of fix-b)
|/  
M  (HEAD of master)
|

假设我正在fix-a上工作，而其他人正在fix-b上工作。 fix-a和fix-b彼此不依赖，完成后可以任意顺序合并到master中。但是，修复了 issue-b 会使使用 issue-a 更加方便。现在， issue-b 已足够固定，尚未完成，因此未合并到master中。因此，基本上我想将fix-b合并到fix-a中，但是当将fix-a合并到master中时，不包括对fix-b的更改-考虑到fix-b将继续发散，我不希望分支机构半熟。

所以我将fix-b合并到fix-a中并继续进行黑客入侵。

| E  a fixed! (HEAD of fix-a)
| |
| D  merge fix-b in to fix-a
| |\
| | A  fix-a wip
| |/
|/| C  fix-b still wip (HEAD of fix-b)
| |/
| B  fix-b wip good enough
|/  
M  (HEAD of master)
|

现在，我想将更改A和E合并到主文件夹中。因此，我结帐了E，进行了git rebase -i并丢弃了B。然后合并到master。

问题是，是否有更优雅的方法来做到这一点？假设A和B是一长串提交。 git rebase -i是繁琐的工作。我想说的是，在合并提交D之后跟随父A。

Answer 1

现在我想将更改A和E合并到主版本中

只需合并即可。我看不出重新跳舞的目的是什么。 E具有父D，而D具有父A，因此A所做的更改仍在E中，并且在合并之后，A在主历史中仍将是合并提交的祖先之一。不再有欲望。

您的犹豫可能是由于误认为A和E是变更集。他们不是。提交是当时所有文件的快照。合并提交D包括执行A所做的任何文件，提交E也包括它们。（除非在准备E的过程中删除了这些文件或以撤消任何A的方式进行操作，但是您当然没有这样做–您的整个目标是使用 A的贡献，而不是与之矛盾。）

您最初的愿望可能根本不是合并，而是将“借入” A到您的分支中。在这种情况下，您应该只挑选它。然后，您可以对下一个提交进行本地交互性变基，以将其压缩为A。这样，它将看起来，就好像您独立提出了A的功能一样。我不同意这一点，因为您现在在说谎这些功能的来源，但在我看来，这比尝试回退合并提交要干净得多。

Answer 2

我偶尔会做这样的游戏....虽然可以管理，但是当您要移动内容时需要付出更多的努力.... 合并不是一个好主意（就与另一个功能一起从功能中获取更改而言）。

假设您分别开发fea-A和fea-B。然后，您就想将fea-B放在fea-A之上，只是因为它很有趣：

git checkout fea-B
git rebase fea-A # assuming fea-A was started _after_ fea-B was started

然后，fea-A完成了更多工作（无需重新定级）...如何获得fea-B进行这些更改：

git checkout fea-B
git rebase fea-A # no problem.

一个棘手的部分（不是唯一的部分）是fea-A是否偏离当前基准（在基准上）。那么fea-B是左悬挂。您可以尝试

git checkout fea-B
git rebase fea-A

这是不能。您将以fea-B ... plus 的原始fea-A修订为基础。那是个问题吗？好吧，是的……因为fea-A在重新设定基础时可能已经进行了重大修改……甚至从头开始重建了完全不同的内容。您不想要为fea-A重新配置您拥有的内容。因此，您应该尝试以下操作：

git checkout fea-B
git rebase --onto fea-A fea-B~3 fea-B # assuming fea-B is only 3 revisions

最后但并非最不重要的是，您想如何再次将它们分开：

git checkout fea-B
git rebase --onto main fea-A fea-B

在没有所有fea-B内容的情况下，哪个将再次在main之上获得fea-A。

并保持分支笔直而不合并。随处移动内容将更加容易。

Git：临时合并到并行修订工作流程中

2 个答案: