git 我的交互式rebase squash最终得到了更多的提交,而不是减少它们,我做错了什么?

6tqwzwtp  于 11个月前  发布在  Git
关注(0)|答案(1)|浏览(113)

我有一个名为myBranch的分支,我正在为一个复杂的功能工作很长时间。在我完成工作并想要打开合并请求后,gitlab显示我的分支完成了47次提交。
我认为MR会更容易理解,如果有一个单一的提交组合所有的变化,因为大多数的个人提交是尝试不同的事情,直到它的工作。
我以前听说过“压缩”这个术语,将多个提交合并成一个,所以我决定我可以尝试学习它。
我开始说:
git rebase -i HEAD~47
它向我展示了一个文本文件,其中包含一系列提交和选择,如pick、squash或reword。
在文本文件中有一些与我的工作无关的旧提交,所以我把它们保留为“pick”。我在分支中输入“reword”作为我的第一个提交,并将提交消息更改为我在分支中添加的功能。我输入“squash”作为其余的提交,直到最新的提交。
然后重基过程继续。它停止了几次合并冲突,并要求我修复然后添加它们。我修复了冲突,使用git add -A添加它们,然后继续使用git rebase --continue
经过几次合并冲突修复后,进程完成,我运行git push origin myBranch --force,并尝试使用我的分支打开一个合并请求。
现在它显示了高达101个提交,比我最初的47个多得多!
我没有将提交的数量减少到1,而是增加了它们。
我做错了什么?

yizd12fk

yizd12fk1#

在我完成工作并想打开一个合并请求后,gitlab显示在我的分支中完成了47次提交。
确保这47个提交都来自你当前的工作:我总是喜欢首先在目标分支之上重基我的分支:

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

字符串
这将迫使您在本地处理任何合并冲突。
如果你想压缩一些提交,你可以做一个git rebase -i origin/target-branch(正如matt在注解中所指出的,每个pickreword创建一个 new 提交:一个交互式的rebase,其中多个提交被挑选或重写,不一定会将提交的数量减少到一个)。
强制推送你的分支(基于目标分支的顶部),你的合并请求应该是微不足道的。

相关问题