压缩线性提交历史时发生冲突

Question

当尝试压缩/修复线性分支时，我仍然需要进行手动合并，这怎么可能？该存储库已从 Subversion 转换。每个冲突要么是“自动挑选失败”，要么是“由于提交消息为空而中止提交”。后者我可以理解，但是 --fixup-empty 或其他东西会很有用。

典型输出：

user@machine:/path (master|REBASE-i)$ git add * && git rebase --continue 
[detached HEAD c536940] fixup!
 Author: John Doe <[email protected]>
 2 files changed, 57 insertions(+), 4 deletions(-)
Automatic cherry-pick failed.  After resolving the conflicts,
mark the corrected paths with 'git add <paths>', and
run 'git rebase --continue'
Could not apply 8854a54... >6d5f180 foo
user@machine:/path (master|REBASE-i)$ git st
# Not currently on any branch.
# Unmerged paths:
#   (use "git reset HEAD <file>..." to unstage)
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#   both modified:      filename.ics
#
no changes added to commit (use "git add" and/or "git commit -a")

Answer 1

这些工作：

git mergetool
git rebase --continue

Answer 2

这是我的建议，用于实现您拥有某种 --fixup-empty 功能的想法：

git filter-branch --msg-filter "sed 's/^$/Unknown/'"

这会将空提交消息替换为“未知”，并且如果您想在使用 git-svn 转换具有一些空提交消息但无法转换的 Subversion 存储库，因为它失败并显示“由于空提交消息而中止提交”。

Answer 3

我遇到了同样令人费解的问题。我想将更改从一大堆顺序提交转换为单个提交，但是使用带有一系列挤压的交互式变基会令人沮丧地产生合并冲突。这是不久前的事了，我刚才无法在一个最小的例子中重现它。无论如何，我确实知道如何解决它，所以在这里：

我将提出两种不同的方法来完成帖子所要求的操作 - 一种笨重但“不那么可怕”，因为很清楚你要做什么正在做的，第二个是优雅的，仅使用 git 命令，但需要您更加相信自己对 git 的理解。

设置

假设您有一个提交 ID idA 作为初始状态，将提交 ID idB 作为最终状态，中间还有一堆其他提交。事实上，您想要压缩所有中间提交，这表明您不再关心如何从初始状态到最终状态 - 您只想要一个使您从 idA 点移动的提交指向idB。

假设 idB 对应于当前的 HEAD 并说它也是您的 master 分支。我们将创建一个名为 squashed 的新分支，它具有与 master 相同的工作树内容，但在提交 ID idA.

解决方案 1

1. git checkout master（您可能已经在 master 上）
2. 使用 bash 或文件资源管理器将整个工作树复制到其他位置。只需确保忽略 .git 目录——这是大多数操作系统上的默认行为。因此，需要明确的是，打开存储库文件夹，选择全部，复制并将其粘贴到桌面上或任何您想要的位置的新文件夹中。
3. git checkout -b scraped idA 创建一个名为 squashed 的新分支，并将 idA 作为其最新提交，并将其设为当前分支。
4. 将 master 的内容（您在步骤 2 中放在其他位置的内容）粘贴回 repo 文件夹中。如果您的文件资源管理器询问，请告诉它替换所有已更改的文件。
5. 在存储库的顶层，git add .，然后git commit。您的新提交将包含从 idA 到 idB 的所有更改。

解决方案 2

git branch squashed idA # make a new branch called `squash` with `idA` as its latest commit 
git checkout master # master is "idB" in this case.
git symbolic-ref HEAD refs/heads/squashed
git commit

瞧。当您使用symbolic-ref将HEAD移动到squash分支的尖端时，工作树状态和新HEAD位置之间的差异集将被计算并暂存。

我想回应一些人表示这是“危险”、“低级”git hack 的担忧。我将尽力解释它的工作原理，让您感到轻松自在。您的 .git 文件夹是所有版本化文件内容所在的位置。其中两个文件夹是 objects 和 refs。 refs 文件夹包含告诉 git 您的分支名称以及它们对应的提交的文件。例如，如果您打开 .git/refs/heads/master，您将看到 master 最新提交的提交 ID。 objects 文件夹包含一堆文件，这些文件位于具有两个字符的十六进制名称的子文件夹中。对象可以是多种不同的东西，包括补丁、提交和整个文件。在 .git 文件夹的顶层还有一个 index 文件。 这是一篇关于索引文件内容的精彩文章。对于当前的讨论，您需要了解的是，索引文件告诉您哪个对象（在 objects 文件夹中）对应于当前分支和提交上每个文件的最新提交版本。

在此背景下，解决方案的作用如下：symbolic-ref命令只是“突然”告诉 git 您位于 squash 分支而不是 master 分支不接触工作树。这意味着您的文件都对应于您了解和喜爱的 master 状态，但是 git 将此视为带有一堆未提交的 idA更改（即，index 文件指定所有文件的当前签出版本是 idA 的版本，这是衡量工作树更改的参考）。事实上，正是这些变化让您声明idB。这也正是解决方案 1 所做的。在这种情况下，由于 symbolic-ref 的实现方式，所有上述更改都已上演（即 git add-ed），因此您所要做的就是是git commit。这没有什么“危险”，因为它不会改变 master 或 git 正在跟踪的任何 objects。您刚刚在 refs 文件夹中创建了一个名为 squashed 的新文件，并在 objects 文件夹中创建了一个与该新组合提交相对应的新文件。您的 master 就在您离开的地方，您只是有一个名为 squashed 的新分支，其内容相同，但提交历史记录较短。如果您不确定发生了什么，请放心，您可以git checkout master，它会在您离开的地方。

如果您想采用 squashed 作为新的 master，您可以继续，

git branch -m master old-master
git branch -m squashed master

然后您将拥有旧分支，其中所有多余的提交都保存为 old -master 和 master 正是您想要的。

希望这有帮助！