在日常开发中，功能分支上常常积累多条琐碎提交，比如修复拼写、补充注释、调整格式等。这些提交单独来看并不具备独立意义，合并到主分支时容易让历史变得支离破碎。如果分支需要发起合并请求，维护者通常希望看到一条逻辑完整的提交，而不是几十条零散记录。因此，当本地提交数量较多且缺乏清晰的信息划分时，就应该考虑将它们合并为一条commit。判断的标准可以是：这些提交是否服务于同一个功能或修复？如果答案为是，那么合并就是合适的操作。
但这不是一个必须执行的动作。如果提交之间存在明显阶段，比如先重构数据表结构，再调整业务代码，最后补测试用例，三条提交分别承担不同职责，硬合并反而会掩盖变更的演进过程。遇到这种情况，我会保留原来的提交粒度。真正需要合并的，通常是那些没有独立意义的“过程提交”。
合并前确认边界
合并提交的本质是重写Git历史，所以行动之前先确认这个分支是否只有自己在用。如果分支已经推送到远程，并且有其他协作者拉取过，重写历史会让他们本地分支与远程仓库失去同步，之后你只能用强制推送覆盖远程，很容易覆盖别人刚推上来的内容。安全的前提是：分支还没有推送过，或者是个人独占的特性分支。
操作前最好先保留一个备份标签或分支，例如执行 git branch backup/feature-xxx，这样即使合并后的提交信息不理想，还有退路。另外，交互式rebase要求工作区干净，如果有未提交的改动，先 git stash 或者先提交。
如果分支在远程已设为受保护分支，强制推送会被直接拒绝。这时候不能硬来，需要先解除保护，或者改成通过合并请求的方式合入。这种情况其实是保护机制在提示你：这个分支不适合直接改写历史。
交互式变基：最常用的合并方式
确认边界之后，可以开始合并操作。
最常用的操作是交互式变基。先执行git log --oneline确认要合并的提交范围，例如最近三条提交，接着运行git rebase -i HEAD~3。编辑器会列出按时间从旧到新排列的提交，每条记录前的命令默认是pick。保留最早提交的pick，将其余记录修改为squash（会额外提示你编辑新的提交信息）或fixup（直接丢弃原提交信息，使用第一条的提交信息）。保存并退出后，Git会暂停并让你输入合并后的提交信息，确认后历史就被重写为一条commit。操作前后可分别运行git log --oneline对比差异。
在编辑器里，提交记录是从旧到新排列的。我自己的习惯是保留最早的那条为pick，其余都改成squash，这样最后还能统一写一遍提交信息。如果中间有纯格式修改，也可以改为fixup，减少一次交互。
pick 1a2b3c feat: add login module
squash 4d5e6f fix typo in login form
squash 7g8h9i adjust style保存退出后，Git会回到命令行，等待输入新的提交信息。这时可以用默认信息，也可以重写一条更完整的描述。
检查结果并处理冲突
完成rebase后，必须检查结果是否符合预期。首先运行git log --oneline，确认提交数量已从多条变为一条，并且提交信息正确。其次执行git status，查看工作区是否干净，如果提示有未合并的文件，说明交互式rebase过程中发生了冲突，需要手动解决后再用git rebase --continue继续。若仓库已关联远程分支，且之前已经推送过旧历史，则需要对远程执行强制推送。使用git push --force-with-lease而不是--force，后者在某些场景下可能误覆盖他人推送的新提交。推送后，在远程仓库页面刷新提交历史，确认已变成一条commit。
冲突一般发生在合并过程中多个提交改到了同一处代码。这时候Git会停在冲突位置，先用编辑器打开相应文件，把冲突标记后的代码改成最终想要的样子，再执行git add <文件>，然后git rebase --continue。如果发现改错了，可以用git rebase --abort回到rebase开始前的状态。
强制推送只适用于确定分支是个人独占的场景。--force-with-lease会在推送前检查远程引用是否与你上次拉取时一致，相当于加了一道保险。即使这样，也建议推送后立刻在远程页面看一次提交列表，确认目标分支已经变成一条commit。
不想进编辑器？用软重置
如果交互式rebase的操作过程让你头疼，还有一个更直接的替代方案：软重置。
先运行git log --oneline找到你想保留为最终提交的那个哈希，也就是你希望作为起点的版本。然后执行git reset --soft <那个哈希>。执行后HEAD会退回到这个提交，但工作区和暂存区中的改动会全部保留。此时所有从原始提交到当前版本的变化都堆在暂存区，你只需要运行git add -A（如果改动尚未全部暂存）再git commit -m "新的提交信息"，就会一次性生成一条新的commit。原来的多条提交在历史里就不存在了。
这种方法适合本地分支、不需要保留中间提交信息的场景，操作起来比交互式rebase直接。但要注意，reset也会改写历史，而且不像rebase那样可以一步步处理冲突。一旦reset之后又做了提交，原来的提交引用就很难再找回来，所以同样要提前备份分支。
合并本地提交不是每天都需要的操作，但一旦意识到主分支历史被零散记录填满，尽快整理会省下后面不少解释成本。动手前判断分支归属，操作后检查提交数量和冲突状态，再决定要不要强制推送，这三步做到位，基本上不会出大问题。