当我所做的只是压缩提交时，为什么 git-rebase 会给我带来合并冲突？

Question

我们有一个包含 400 多个提交的 Git 存储库，其中前几十个提交经过了大量的反复试验。我们希望通过将许多提交压缩为单个提交来清理这些提交。当然，git-rebase 似乎是最佳选择。我的问题是它最终会产生合并冲突，而且这些冲突并不容易解决。我不明白为什么应该有任何冲突，因为我只是压缩提交（而不是删除或重新排列）。很可能，这表明我没有完全理解 git-rebase 是如何进行压缩的。

这是我正在使用的脚本的修改版本：

---

repo_squash.sh（这是实际运行的脚本）：

---

rm -rf repo_squash
git clone repo repo_squash
cd repo_squash/
GIT_EDITOR=../repo_squash_helper.sh git rebase --strategy theirs -i bd6a09a484b8230d0810e6689cf08a24f26f287a

---

repo_squash_helper.sh（此脚本仅由 repo_squash.sh 使用）：

---

if grep -q "pick " $1
then
#  cp $1 ../repo_squash_history.txt
#  emacs -nw $1
  sed -f ../repo_squash_list.txt < $1 > $1.tmp
  mv $1.tmp $1
else
  if grep -q "initial import" $1
  then
    cp ../repo_squash_new_message1.txt $1
  elif grep -q "fixing bad import" $1
  then
    cp ../repo_squash_new_message2.txt $1
  else
    emacs -nw $1
  fi
fi

---

repo_squash_list.txt：（使用此文件仅由 repo_squash_helper.sh 提供）

---

# Initial import
s/pick \(251a190\)/squash \1/g
# Leaving "Needed subdir" for now
# Fixing bad import
s/pick \(46c41d1\)/squash \1/g
s/pick \(5d7agf2\)/squash \1/g
s/pick \(3da63ed\)/squash \1/g

---

我将把“新消息”内容留给您想象。最初，我在没有“--strategy thoses”选项的情况下执行此操作（即使用默认策略，如果我正确理解文档，则该策略是递归的，但我不确定使用哪种递归策略），而且它也没有'不工作。另外，我应该指出，使用 repo_squash_helper.sh 中注释掉的代码，我保存了 sed 脚本所处理的原始文件，并对其运行 sed 脚本，以确保它正在执行我想要它执行的操作（是的）。同样，我什至不知道为什么会发生冲突，因此使用哪种策略似乎并不那么重要。任何建议或见解都会有所帮助，但大多数情况下我只是想让这种挤压发挥作用。

更新了与​​ Jefromi 讨论中的额外信息：

在使用我们的大型“真实”存储库之前，我在测试存储库上使用了类似的脚本。这是一个非常简单的存储库，测试运行顺利。

当它失败时我得到的消息是：

Finished one cherry-pick.
# Not currently on any branch.
nothing to commit (working directory clean)
Could not apply 66c45e2... Needed subdir

这是第一次压缩提交后的第一个选择。运行 git status 会生成一个干净的工作目录。如果我随后执行 git rebase --Continue，在多次提交后我会收到非常相似的消息。如果我再次这样做，在几十次提交后我会收到另一条非常相似的消息。如果我再次这样做，这次它会经历大约一百次提交，并产生以下消息：

Automatic cherry-pick failed.  After resolving the conflicts,
mark the corrected paths with 'git add <paths>', and
run 'git rebase --continue'
Could not apply f1de3bc... Incremental

如果我然后运行 ​​git status，我会得到：

# Not currently on any branch.
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
# modified:   repo/file_A.cpp
# modified:   repo/file_B.cpp
#
# Unmerged paths:
#   (use "git reset HEAD <file>..." to unstage)
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
# both modified:      repo/file_X.cpp
#
# Changed but not updated:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
# deleted:    repo/file_Z.imp

“两​​者都修改了”位对我来说听起来很奇怪，因为这只是选择的结果。还值得注意的是，如果我查看“冲突”，它可以归结为一行，其中一个版本以 [tab] 字符开头，另一个版本以四个空格开头。这听起来可能是我如何设置配置文件的问题，但其中没有任何此类内容。 （我确实注意到 core.ignorecase 设置为 true，但显然 git-clone 会自动执行此操作。考虑到原始源位于 Windows 计算机上，我对此并不完全感到惊讶。）

如果我手动修复 file_X.cpp，然后不久之后，它会因另一次冲突而失败，这次是一个版本认为应该存在的文件（CMakeLists.txt）与一个版本认为不应该存在的文件（CMakeLists.txt）之间的冲突。如果我通过说我确实想要这个文件（我确实想要）来解决这个冲突，那么几次提交之后我会遇到另一个冲突（在同一个文件中），现在有一些相当重要的更改。冲突还只完成了大约 25%。

我还应该指出，因为这可能非常重要，所以这个项目是在 svn 存储库中开始的。最初的历史记录很可能是从 svn 存储库导入的。

更新#2：

一时兴起（受到 Jefromi 评论的影响），我决定将我的 repo_squash.sh 更改为：

rm -rf repo_squash
git clone repo repo_squash
cd repo_squash/
git rebase --strategy theirs -i bd6a09a484b8230d0810e6689cf08a24f26f287a

然后，我就按原样接受了原始条目。即，“rebase”不应该改变任何事情。最终得到与前面描述的相同的结果。

更新＃3：

或者，如果我省略该策略并将最后一个命令替换为：

git rebase -i bd6a09a484b8230d0810e6689cf08a24f26f287a

我不再遇到“无需提交”变基问题，但仍然存在其他冲突。

使用重现问题的玩具存储库进行更新：

test_squash.sh （这是您实际运行的文件）：

#========================================================
# Initialize directories
#========================================================
rm -rf test_squash/ test_squash_clone/
mkdir -p test_squash
mkdir -p test_squash_clone
#========================================================

#========================================================
# Create repository with history
#========================================================
cd test_squash/
git init
echo "README">README
git add README
git commit -m"Initial commit: can't easily access for rebasing"
echo "Line 1">test_file.txt
git add test_file.txt
git commit -m"Created single line file"
echo "Line 2">>test_file.txt 
git add test_file.txt 
git commit -m"Meant for it to be two lines"
git checkout -b dev
echo Meaningful code>new_file.txt
git add new_file.txt 
git commit -m"Meaningful commit"
git checkout master
echo Conflicting meaningful code>new_file.txt
git add new_file.txt 
git commit -m"Conflicting meaningful commit"
# This will conflict
git merge dev
# Fixes conflict
echo Merged meaningful code>new_file.txt
git add new_file.txt
git commit -m"Merged dev with master"
cd ..

#========================================================
# Save off a clone of the repository prior to squashing
#========================================================
git clone test_squash test_squash_clone
#========================================================

#========================================================
# Do the squash
#========================================================
cd test_squash
GIT_EDITOR=../test_squash_helper.sh git rebase -i HEAD@{7}
#========================================================

#========================================================
# Show the results
#========================================================
git log
git gc
git reflog
#========================================================

test_squash_helper.sh （由 test_sqash.sh 使用）：

# If the file has the phrase "pick " in it, assume it's the log file
if grep -q "pick " $1
then
  sed -e "s/pick \(.*\) \(Meant for it to be two lines\)/squash \1 \2/g" < $1 > $1.tmp
  mv $1.tmp $1
# Else, assume it's the commit message file
else
# Use our pre-canned message
  echo "Created two line file" > $1
fi

PS：是的，我知道你们中的一些人在看到我使用 emacs 作为后备编辑器。

PPS：我们确实知道在变基后我们必须清除现有存储库的所有克隆。 （沿着“你不应该在发布后重新设置存储库”的思路。）

PPPS：任何人都可以告诉我如何为此添加赏金吗？无论我处于编辑模式还是查看模式，我都没有在屏幕上的任何位置看到该选项。

Answer 1

如果您不介意创建一个新分支，这就是我处理问题的方式：

在主分支上：

# create a new branch
git checkout -b new_clean_branch

# apply all changes
git merge original_messy_branch

# forget the commits but have the changes staged for commit
git reset --soft main        

git commit -m "Squashed changes from original_messy_branch"

Answer 2

好吧，我有足够的信心给出答案。也许需要编辑它，但我相信我知道你的问题是什么。

您的玩具存储库测试用例中有一个合并 - 更糟糕的是，它有一个存在冲突的合并。并且您正在合并过程中进行变基。如果没有 -p （它不能完全与 -i 一起使用），合并将被忽略。这意味着当 rebase 尝试挑选下一个提交时，您在冲突解决中所做的任何操作都不存在，因此其补丁可能不适用。 （我相信这显示为合并冲突，因为 gitcherry-pick 可以通过在原始提交、当前提交和共同祖先之间进行三向合并来应用补丁。）

不幸的是，正如我们在评论中指出的，-i 和 -p（保留合并）相处得不太好。我知道编辑/重新措辞有效，而重新排序则无效。不过，我相信它对南瓜效果很好。这没有记录，但它适用于我在下面描述的测试用例。如果你的情况非常复杂，那么你在做你想做的事情时可能会遇到很多麻烦，尽管这仍然是可能的。 （这个故事的寓意：在合并之前使用 rebase -i 进行清理。）

因此，假设我们有一个非常简单的情况，我们想要将 A、B 压缩在一起和 C：

- o - A - B - C - X - D - E - F (master)
   \             /
    Z -----------

现在，就像我说的，如果 X 中没有冲突，git rebase -i -p 将按您的预期工作。

如果存在冲突，事情就会变得有点棘手。它会进行很好的压缩，但是当它尝试重新创建合并时，冲突将再次发生。您必须再次解析它们，将它们添加到索引中，然后使用 git rebase --continue 继续。 （当然，您可以通过检查原始合并提交的版本来再次解决它们。）

如果您碰巧有 rerere 在您的存储库中启用（rerere.enabled 设置为 true），这会更容易- git 将能够重新使用您最初遇到冲突时的重新解决方案，而您所要做的就是检查以确保其正常工作，将文件添加到索引，然后继续。 （您甚至可以更进一步，打开 rerere.autoupdate，它会为您添加它们，因此合并甚至不会失败）。不过，我猜测您从未启用过 rerere，因此您必须自己解决冲突。*

_{* 或者，您可以尝试 rerere-train.sh 来自 git-contrib 的脚本，它尝试“从现有的合并提交中填充 [the] rerere 数据库” - 基本上，它检查所有合并提交，尝试合并它们，如果合并失败，它会获取结果并将其显示给 git-rerere。这可能很耗时，而且我从未真正使用过它，但它可能非常有帮助。}

Answer 3

如果您想从一长段提交中创建一个提交（其中一些是合并提交），最简单的方法是将分支重置到第一次提交之前的点，同时保留所有更改，然后重新提交它们：

git reset $(git merge-base origin/master @)
git add .
git commit

替换 < code>origin/master 替换为您分支的分支的名称。

add . 是必需的，因为新添加的文件在重置后显示为未跟踪。

Answer 4

我一直在寻找类似的要求，即放弃我的开发分支的中间提交，我发现这个过程对我有用。
在我的工作分支

git reset –hard mybranch-start-commit
git checkout mybranch-end-commit . // files only of the latest commit
git add -a
git commit -m”New Message intermediate commits discarded”

viola 上，我们已将最新提交连接到分支的开始提交！
没有合并冲突问题！
在我的学习实践中我现阶段得出了这样的结论，是否有更好的方法达到目的。

Answer 5

基于@hlidka上面的很好的答案，最大限度地减少了手动干预，我想添加一个版本来保留任何新的提交不在分支中的大师要挤压。

我相信这些很容易在该示例中的 git reset 步骤中丢失。

# create a new branch 
# ...from the commit in master original_messy_branch was originally based on. eg 5654da06
git checkout -b new_clean_branch 5654da06

# apply all changes
git merge original_messy_branch

# forget the commits but have the changes staged for commit
# ...base the reset on the base commit from Master
git reset --soft 5654da06       

git commit -m "Squashed changes from original_messy_branch"

# Rebase onto HEAD of master
git rebase origin/master

# Resolve any new conflicts from the new commits

Answer 6

请注意，在交互式变基中使用时，-X 和策略选项将被忽略。

请参阅提交db2b3b820e2b28da268cc88adff076b396392dfe（2013年7月，git 1.8.4+），

不要忽略交互式变基中的合并选项

合并策略及其选项可以在git rebase中指定，但使用--interactive时，它们被完全忽略。

签署人：Arnaud Fontaine

这意味着 -X 和策略现在可以与交互式变基以及普通变基一起使用，并且您的初始脚本现在可以更好地工作。

Answer 7

我遇到了一个更简单但类似的问题，我有
1）解决了本地分支上的合并冲突，
2）继续努力添加更多的小提交，
3）想要变基并遇到合并冲突。

对我来说， git rebase -p -i master 有效。它保留了最初的冲突解决承诺，并允许我将其他人压在上面。

希望对某人有帮助！