我的交互式变基挤压最终会产生更多提交，而不是减少提交。我做错了什么？

Question

我有一个名为

myBranch

的分支，我长期以来一直致力于开发一个复杂的功能。当我完成工作并想要打开合并请求后，gitlab 显示我的分支中完成了 47 次提交。

我认为如果有一个结合了所有更改的单一提交，MR 会更容易理解，因为大多数单独的提交都会尝试不同的事情，直到它起作用。

我之前听说过“压缩”这个术语，可以将多个提交合并为一个，所以我决定可以尝试学习这一点。

我开始于：

git rebase -i HEAD~47

它向我展示了一个文本文件，其中包含提交列表以及选择、压缩或重写等选项。

文本文件中有一些与我的工作无关的旧提交，所以我将它们保留为“pick”。 我在分支中的第一次提交中输入了“reword”，并将提交消息更改为我在分支中添加的功能。 我为其余的人输入了“squash”，直到最新的提交。

然后继续变基过程。它因合并冲突而停止了几次，并要求我修复然后添加它们。我修复了冲突，使用

git add -A

添加它们，然后使用

git rebase --continue

继续。

修复了一些合并冲突后，流程完成，我运行

git push origin myBranch --force

，并尝试使用我的分支打开合并请求。

现在它显示了高达 101 次提交，比我最初的 47 次要多得多！

我没有将提交数量减少到 1，而是实际上增加了提交数量。

我做错了什么？

Answer 1

当我完成工作并想要打开合并请求时，gitlab 显示我的分支中完成了 47 次提交。

确保这 47 次提交全部来自您当前的工作：我总是更喜欢首先在目标分支之上重新调整我的分支：

git fetch
git switch my-feature-branch
git rebase origin/target-branch

这将迫使您在本地处理任何合并冲突。
如果你想压缩一些提交（如评论

中的

matt所述，每个git rebase -i origin/target-branch或pick

都会创建一个

new

提交：一个交互式变基，其中多个选择或重新措辞提交不一定会将提交数量减少到一个）。

强制推送您的分支（基于目标分支的顶部重新构建），您的合并请求应该是微不足道的。