我们组长说从子分支到主分支一定要用变基保持 dev 的提交记录的干净，我在子分支里又喜欢写一段代码只要完成一小部分的功能就立刻提交，这样方便恢复，但是最后等变基然后合并到主分支的时候，我那一大堆提交记录也跟着带过来了，就让 dev 变得很难看，大概是这样
我后面学着用这个压缩提交，可以将多个提交记录压缩成一个然后再合并到主分支上，但是用完之后提交记录变得更加诡异了，甚至会变成两个我有两个完全一样的提交记录，给我都整不会了，合并的时候也特别麻烦，审阅了很多东西，最后还让组长帮忙看看最终的内容有没有预期之外的修改才敢合并的，出了这事之后我就不敢再用压缩提交了
下面是提交记录，之所以有两个一样的提交就是因为当时用了压缩提交
后面我又跟组长学修正提交，可以修正前一个提交来解决问题，但是我用修正提交的时候有时候不知道为什么还是会触发自动合并和更新，最后虽然说可以效果没变化，但是提交记录还是变得很难看，具体来说如下图所示
到这里为止我是真没办法，不知道该怎么解决这个问题，有没有懂得大佬来说一下，虽然说这个问题也不影响开发，但是这么乱的记录我看着心里挺膈应就是
 | 1 tinypig Aug 15, 2025 我猜你需要的是 git-rebase https://git-scm.com/docs/git-rebase |
 | 2 MonkeyJon Aug 15, 2025 全选右键，create patch 切换到主分支 apply patch commit |
 | 3 ooo4 Aug 15, 2025 github 的 squash merge ？ |
 | 4 msg7086 Aug 15, 2025 Squash merge |
 | 5 hwdq0012 Aug 15, 2025 git rebase -i 想合并到的分支~1 ， 会弹出一个可编辑的文档，在上面修改 pick 为 f 表示合并到父提交， 或 s 表示 合并到父提交，并修改父提交的 commit message |
 | 6 clino Aug 15, 2025 |
 | 7 evan1 PRO  4 我一般不处理，直接用 idea 过滤下就行了。  |
 | 8 faceRollingKB Aug 15, 2025 可以用 reset 把分支重置到之前的某个点，再 force commit 覆盖 history ，缺点是这种做法有风险，建议开干之前先 checkout -b 一个备用分支以便恢复代码 |
 | 9 walle1530 Aug 15, 2025 我本地一般一点一点的 commit ，提交整个功能的时候 git rebase -i HEAD~x ，然后 push 或者 push 完有修改，最后 git rebase -i HEAD~x 合并一整个功能, 然后 git push --force-with-lease |
 | 10 vvvVictoria Aug 15, 2025 Squash merge +1 |
 | 11 nilaoda Aug 15, 2025 你需要的是 squash merge 吧 或者新开一个分支，idea 选中你原分支要合入的所有 commit ，右边会出现这些 commit 的修改文件列表，全选把变更拿到新分支上提一个 commit |
 | 12 dizheyoulan Aug 15, 2025 合并成一个的话，直接 git reset --soft 2ebc134 # 软重置到第一个提交 git commit --amend -m "新的提交信息" # 修改第一个提交 |
 | 13 momocraft Aug 15, 2025 git rebase -i 可以自由地重排序，squash 连续的 commit 成一个，增减 commit 等 |
 | 14 lenglengyuchen Aug 15, 2025 via Android 1 为啥主分支要合并提交呢？我们团队是没合并，我个人也觉得保留每次的提交比较好，提交次数是会很多，变更也不连贯，但比较容易追根溯源，感觉合并之后，出问题的风险更大些，解决难度也大 |
 | 15 skiy Aug 15, 2025 git rebase -i main 然后使用 %s#pick#f#g 将里面的 pick 全部替换成 fixup 。再 1G 跳到第一行，将第一行的 f 改成 p 。即可。当然，你也可以选择保留 commit message 。将上述的 f 改为 s 即可（好像就是 s ？） |
 | 16 cnhongwei Aug 15, 2025 如果是使用 idea ，不要在原分支上压缩，你在分支上开发完了，从这个分支上创建了个新分支，不要 push ，再压缩你的所有提交再 push ，再 merge 或 rebase 到主分支。 |
 | 17 FlashEcho Aug 15, 2025 你 squash 和 commit --amend 之后是不是直接 push 了，所以出现两个一样的 commit ，这种情况应该 force push ，不然没法覆盖掉前一个 |
 | 18 jjwjiang Aug 15, 2025 1 squash 之后你自己的当前分支是废掉的了，不能继续用，因为 squash 合并的这个 commit 在你本地是不存在的，你本地是一堆合并前的 commit ，所以如果你在你这个分支继续修改提交就会出现很诡异的记录。squash 之后要新建分支，这点要注意。 |
 | 19 user1284 Aug 15, 2025 你是不是把已经提交的也压缩了, 我自己的使用经验是压缩只用于本地多个 commit 只做一件事的时候先压缩再推送, 然后再合并 |
 | 20 peakmuma Aug 15, 2025 如果这个分支只有你自己的代码那么就本地先进行 squash merge ， 如果这个分支之前 push 到远端过，那么新 push 需要强制推送 git push -f |
 | 21 clue Aug 15, 2025 你们组长也奇怪，都要求用变基 (rebase) 了，结果 mr 最后又走的 merge commit 而不是 fast-forward ，搞了半天结果最后一步又放弃了 rebase 的最大优势 |
 | 22 chen1314 Aug 15, 2025 Squash merge |
 | 23 Donne Aug 15, 2025 @lenglengyuchen 不合并的话根本没法看，大部分开发的时候都是频繁提交，commit 的信息也不会写的很仔细，每次看 commit ，完全找不到重点 |
 | 24 junbaor Aug 15, 2025 永远有人争论 rebase merge ，个人更建议多人协作时用 merge, 会保留最真实的历史记录，rebase 的优点是让 history 好看，但出问题的风险更大。 |
 | 25 qq362220083 Aug 15, 2025 我用小乌龟，先变基，把多个提交合并成一个提交，最后再推送。中间有冲突就解决冲突。 |
 | 26 Phariel Aug 15, 2025 用 Squash merge Rebase 我用了十几年 Git 一直敬而远之 总觉得危险 |
 | 27 cinlen Aug 15, 2025 每次提交采用 git commit amend 不断向上一个 commit 合并，或是 git rebase -i 然后选择要合并的多个 commit. 采用 rebase + squash 可以得到干净的提交历史， 只是你要有能力 hold 得住这套机制。 |
 | 28 lianhuayu420 Aug 15, 2025 squash and merge |
 | 29 jqtmviyu Aug 15, 2025 方法 1: 用 git rebase 修改自己的本地分支, 同一个功能的 fixup 方法 2: 新建一个功能分支, 开发完 cherry-pick 到功能子分支, 子分支再合到主分支 |
| 30 lenglengyuchen Aug 16, 2025 @Donne 开发时是会提交很多次 commit ，但每次肯定不是随便提，说实话我没遇到过太多要查 commit 的场景，可能查问题时要找 commit 的人，与合并提交的 commit 没啥差别 |
 | 31 kongkongkong101 Aug 16, 2025 patch squash 二选一 |
 | 32 cymok Aug 17, 2025 1. git rebase -i + squash 2. 先在当前 commit 节点创建 branch 或 tag 作备份，git reset --mixed 重新按自己想要的样子一个个 add + commit ，再 rebase 过去 |
 | 33 harlen Aug 17, 2025 以前都用 rebase -i 后面， 然后 开源节流的时候，就说你提交记录只有那一点点，无法证明你的工作量， 现在都直接用 merge --squash |
 | 34 guanzhangzhang Aug 17, 2025 自己分支上 定期 git pull --rebase origin 主干分支名字 提交之前 git rebase HEAD~数字 合并 |
 | 35 flashBee233 Aug 18, 2025 新创建一个本地分支 再进行提交合并的操作 最后合并到主分支 |
Select Language