GIT:附加几次提交后制作的补丁

Question

我使用 git 来跟踪我们的开发团队所做的更改并提交到我们的中央 cvs 样式存储库中。由于它的 cvs，它跟踪文件而不是提交，因此有时很难准确判断哪些文件构成了错误修复的完整补丁。我刚遇到一个并做了以下事情:

1) trolling，检查 CVS 日志并将它们作为完整补丁提交给 git

A--B--C--D

2) 发现另一个实际上是针对工单 (B) 的文件更改，所以我使用

将当前分支重置为 B

git reset --soft <sha1 ID for commit B>

3) 我复制了更改，并将其附加到提交 (B) 中

git commit --amend

4) 令我惊讶的是，树现在显示为

A--B

仅在工作树中提交 (C) 和 (D)。他们的详细信息从日志中消失了，我认为我无法找回它们。我哪里做错了？我唯一的选择是在 (D) 之上进行额外的提交，并且只知道它确实是 (B) 的一部分吗？

Answer 1

发生了什么

你的意思是修改，而不是追加，对吧？为了方便起见，我将假装这是在一个名为 master 的分支上。这是您的存储库现在的样子:

A---B' (master)
 \
  \-B---C---D

Git 提交明确依赖于它们的父级 - 不同父级之上的相同补丁是不同的提交。

如何恢复

您可以通过几种方式恢复之前的位置。以前的职位有一个很好的简写，您可以使用它直接 checkout 或创建分支:

git checkout master@{1}
git branch oldmaster master@{1}

这是假设它是前一个位置。它可能是第二个 (master@{2})...或者如果您知道它是什么时候，您可以使用 master@{7:35} 或 master@{23.hours.ago}。有关这些形式的摘要，请参阅 man git-rev-parse ( online here ) 的“指定修订”部分。

如果您不确定如何到达它，请尝试

git reflog show master

这将为您提供 master 以前职位的列表，您应该能够从描述中分辨出您想要哪个(或者尝试几个)。您可以简单地从列表中复制散列，然后使用 git checkout 或 git branch 如上所述。

你应该做的

警告:如果历史已经发布，则编辑历史是个坏主意 - 在这种情况下，您应该简单地提交修复。是的，在存储库中将它分成两个提交有点丑陋，但其他用户必须能够相信他们在公共(public)存储库中看到的内容不会更改!

也就是说，要进行这种特殊的历史编辑，您需要交互式 rebase :

git rebase -i master~4 master

master~4代表master提示前四次commit。您可以在这里使用任何您想要的形式 - 也许它是另一个分支，也许是一个提交散列 - 任何有效的。

这将在编辑器中打开您正在处理的提交列表:

pick <hash-A>  <message-A>
pick <hash-B>  <message-B>
pick <hash-C>  <message-C>
pick <hash-D>  <message-D>

# Rebase <hash-A^>..<hash-D> onto <hash-A^>
#
# Commands:
#  p, pick = use commit
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

注释掉的帮助文本非常不言自明。在这种情况下，您想在提交 B 的行上将“pick”更改为“edit”，保存并退出。 rebase 将开始，并在应用 B 后暂停，让您进行更改。你会做你需要做的，添加，使用 git commit --amend，然后 git rebase --continue。它将应用 C 和 D，您就完成了。如果中间出现任何问题，请使用 git rebase --abort 返回到开始的位置。

rebase 可能有点可怕 - 例如，不要不小心删除该列表中的行!如果您还不习惯，最好大量使用 gitk 和备份分支名称。