我们有一个包含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他们的”选项（即，使用默认策略，如果我理解文档正确是递归的，但我不确定使用哪种递归策略），它也没有'工作。另外，我应该指出，使用repo_squash_helper.sh中注释掉的代码，我保存了sed脚本工作的原始文件并对其运行了sed脚本，以确保它正在执行我想要它做的事情（它是）。同样，我甚至不知道为什么会成为冲突，所以使用哪种策略似乎并不重要。任何建议或见解都会有所帮助，但大多数情况下我只想让这种压力得以实现。
在开发我们庞大的“真实”存储库之前，我在测试存储库中使用了类似的脚本。这是一个非常简单的存储库，测试工作干净利落。
失败后收到的消息是：
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）和一个版本认为不应该存在的文件之间。如果我通过说我确实想要这个文件（我这样做）来修复这个冲突，稍后我会得到另一个冲突（在同一个文件中），现在有一些相当重要的变化。它仍然只是冲突中的25％左右。
我还应该指出，由于这可能非常重要，因此该项目始于svn存储库。该初始历史很可能是从该svn存储库导入的。
在云雀（受Jefromi的评论影响）上，我决定改变我的repo_squash.sh：
rm -rf repo_squash
git clone repo repo_squash
cd repo_squash/
git rebase --strategy theirs -i bd6a09a484b8230d0810e6689cf08a24f26f287a
然后，我接受原始条目，原样。即，“rebase”不应该改变一件事。它最终得到了之前描述的相同结果。
或者，如果我省略策略并将最后一个命令替换为：
git rebase -i bd6a09a484b8230d0810e6689cf08a24f26f287a
我不再得到“没有提交”的rebase问题，但我还是留下了其他冲突。
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
P.S。：是的，我知道有些人在看到我使用emacs作为后备编辑时会感到畏缩。
P.P.S。：我们知道在rebase之后我们将不得不吹掉现有存储库中的所有克隆。 （按照“在发布后不得对存储库进行修改”这一行。）
P.P.P.S：谁能告诉我如何为此添加赏金？我在这个屏幕上的任何地方都没有看到该选项，无论我是处于编辑模式还是查看模式。答案 0 :(得分：62)
好吧，我有足够的信心拒绝回答。也许必须编辑它，但我相信我知道你的问题是什么。
你的玩具回购测试案例中有一个合并 - 更糟糕的是，它与冲突合并。你在整个合并中进行了变革。如果没有-p（不完全与-i一起使用），则忽略合并。这意味着，当你的rebase尝试挑选下一个提交时，无论你在冲突解决方案中做了什么，所以它的补丁可能不适用。 （我相信这显示为合并冲突，因为git cherry-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，所以你必须自己做冲突解决。*
<子>
*或者，您可以尝试使用git-contrib中的rerere-train.sh脚本，该脚本会尝试“从现有的合并提交中重新启动数据库” - 基本上，它会检出所有合并提交，尝试合并它们，以及如果合并失败，它会抓取结果并将其显示给git-rerere。这可能非常耗时，而且我从未真正使用它，但它可能非常有用。
答案 1 :(得分：41)
如果您不介意创建新分支，我就是这样处理问题的方法：
在主人身上：
# 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 master
git commit -m "Squashed changes from original_messy_branch"
答案 2 :(得分：3)
我正在寻找类似的要求，即放弃我的开发部门的中间提交，我发现这个程序对我有用。
在我的工作分支上
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我们已将最新提交连接到分支的开始提交！ 没有合并冲突问题！ 在我的学习实践中，我在这个阶段得出了这个结论，是否有更好的方法达到目的。
答案 3 :(得分：2)
如果你想从一个很长的提交分支中创建一个提交，其中一些是合并提交，最简单的方法是将你的分支重置到第一次提交之前的点，同时保留所有更改，然后重新提交它们:
git reset $(git merge-base origin/master @)
git add .
git commit
将 origin/master 替换为您分支的分支的名称。
add . 是必需的，因为新添加的文件在重置后显示为未跟踪。
答案 4 :(得分：1)
在上面{@ hlidka的一个很好的答案（可以最大程度地减少手动干预）的基础上，我想添加一个版本，该版本可以保留master上所有不在分支中的新提交。
我相信在该示例的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
答案 5 :(得分：0)
请注意，在交互式rebase中使用-X和策略选项时会被忽略。
请参阅commit db2b3b820e2b28da268cc88adff076b396392dfe（2013年7月，git 1.8.4 +），
不要忽略交互式rebase中的合并选项
合并策略及其选项可在
git rebase中指定，但-- interactive则完全忽略。签名：Arnaud Fontaine
这意味着-X和策略现在可以使用交互式rebase，以及普通的rebase，您的初始脚本现在可以更好地工作。
答案 6 :(得分：0)
我遇到了一个更简单但类似的问题，我曾经在那里 1）解决了本地分支上的合并冲突， 2）继续工作添加更多的小提交， 3）想要改变并打击合并冲突。
对我来说，git rebase -p -i master有效。它保留了最初的冲突解决方案，并允许我将其他人压在一起。
希望能帮助别人！