rebase 最适合解决两个问题：让功能分支跟上主分支，以及在合并前整理自己的提交历史。它会重写提交，因此边界要清楚：只整理自己控制的提交，不改写其他人正在依赖的公共历史。
假设当前在 feature/search 分支，主分支是 main：
git fetch origin
git rebase origin/main
如果出现冲突，先查看状态：
git status
手动修改冲突文件并确认内容正确，然后继续：
git add path/to/file
git rebase --continue
如果发现方向不对，可以随时回到 rebase 之前：
git rebase --abort
在提交较碎时，我会使用交互式 rebase，把“修错字”“补测试”之类的提交合并进对应功能提交：
git rebase -i origin/main
编辑器中保留第一个提交为 pick，把后续相关提交改为 fixup。完成后，历史通常会变成几个目的明确、可以独立审查的提交。
如果这个功能分支已经推送过，rebase 后需要更新远端。使用：
git push --force-with-lease
不要随手使用裸 --force。--force-with-lease 会检查远端是否出现了自己尚未看到的新提交，能避免覆盖同事刚推送的工作。
我的习惯是：开始 rebase 前保证工作区干净；解决冲突后运行测试；推送前再看一遍 git log --oneline --graph。这三个小动作可以省掉大部分返工。