git rebase -i 压缩提交最常卡在 HEAD~n 算错：HEAD~3 只覆盖3个提交的起点，压A→B→C→D需用 HEAD~4；squash 冲突时用 git status 查看、手动解决、git add 后 git rebase --continue；切勿中途 git commit；git merge --squash 是内容移植，生成新提交且不改原历史；强制推送须用 --force-with-lease 并确认协作状态。
git rebase -i 选错范围就压不进提交
最常卡住的地方不是操作本身，而是 HEAD~n 算错了。比如你想压缩最近 4 次提交，但执行了 git rebase -i HEAD~3，编辑器里只显示 1 条 pick —— 那是因为 HEAD~3 指的是「当前提交往前数 3 个」，实际只覆盖了 3 个提交的「起点」，你真正想改的那几条根本没被纳入范围。
正确做法是先用 git log --oneline -n 10 看清顺序和数量，再决定 n 值；如果要压 A→B→C→D 这四次，必须用 HEAD~4（即从 D 往前跳 4 步，落到 A 的父提交上）。
另外注意：git rebase -i 只处理「当前分支上、尚未合并到目标分支」的提交。如果别人已基于你的某次提交开发，强行 rebase 会导致他们后续同步困难。
squash 后报 could not apply 不是失败，是等着你解冲突
把多个 pick 改成 squash 保存退出后，Git 报 could not apply，这不是命令写错了，而是冲突触发了暂停机制。
此时运行 git status 会显示 You are currently rebasing，并列出冲突文件；打开这些文件，删掉 <<<<<< / ======= / >>>>>> 标记，保留最终需要的内容；然后 git add <file> 标记为已解决；最后 git rebase --continue 继续流程。
切记不要在 rebase 中途直接 git commit —— 这会生成一个新提交，破坏 squash 流程；想放弃就用 git rebase --abort，一切回退到操作前。
git merge --squash 是内容移植，不是历史合并
git merge --squash 和 git rebase -i 完全不是一回事：前者不改变任何原有提交哈希，只是把另一个分支的所有变更暂存起来，等你手动 git commit 生成一条全新提交；后者是重写本地提交历史，所有被 squash 的提交 hash 全部作废。
使用约定式提交（Conventional Commits）从 Git 历史记录中生成结构化变更日志，支持多种格式、AI 增强型描述以及可自定义的范围……
这意味着：
-
git merge --squash feature/login执行后，feature/login分支的原始提交依然存在，可随时再用 - 它适合合并短期特性分支，尤其当你不想让调试提交污染
main - 但如果你需要保留完整作者信息、时间戳或中间逻辑演进，它就不合适——因为所有元数据都丢失了
执行完 git merge --squash 后必须手动 git commit，否则变更只是暂存，不会产生任何提交记录。
强制推送前务必确认协作状态
无论用 rebase 还是 reset --soft 压缩提交，只要原提交已推送到远程，本地历史就和远端不一致了，git push 会拒绝，提示 non-fast-forward update。
这时必须用 git push --force-with-lease origin <branch>。它比裸 --force 安全：会检查远程分支是否被别人更新过，避免覆盖他人新提交。
但以下情况绝不能 force push：
- 目标分支是团队共享的
main或develop - 已有同事基于你旧提交做了衍生开发
- 仓库启用了
Prevent force pushes或Require signed commits策略
最容易被忽略的一点：压缩后若未及时同步，别人 git pull 时可能自动触发 merge，把旧历史又拉回来——所以压缩完立刻沟通、立刻推送、立刻清理备份分支。
