做开发时经常遇到这种情况：你拉了个 feature 分支埋头写代码，一两周后准备合入 main 时，发现冲突一大堆，光解决 merge 冲突就花掉半天。其实不用这么被动——给分支加个定期同步机制，就能把问题拆小、化在平时。
最常用的三步同步法
每天上班第一件事，或者每完成一个小功能点后，顺手执行这三行命令：
git checkout main
git pull origin main
git checkout feature/login-page
git rebase main注意：用 rebase 而不是 merge，能让你的提交历史更干净。rebase 相当于把你在 feature 分支上的改动“挪”到最新的 main 顶端重放一遍，而不是生成一个合并提交。
想省事？写个一键脚本
把上面流程存成 sync.sh（macOS/Linux）或 sync.bat（Windows），以后双击或一行命令就搞定：
#!/bin/bash
# sync.sh
git checkout main && \
git pull origin main && \
git checkout - && \
git rebase main其中 git checkout - 是快速切回上一个分支的快捷写法，不用每次都输分支名。
再进一步：用 cron 或 Task Scheduler 自动跑
如果你习惯早上 9 点开工，可以设置每天 8:50 自动同步一次。Linux/macOS 下编辑 crontab：
50 8 * * * cd /path/to/your/project && /bin/bash sync.sh > /dev/null 2>&1Windows 用户可在「任务计划程序」里新建基本任务，触发器选「每天」，操作选「启动程序」，指向你的 sync.bat 即可。
别忘了同步前先 stash 未提交的修改
如果当前有没 commit 的改动，rebase 会直接失败。保险起见，同步前加一句：
git stash push -m \"auto-sync-$(date +%H%M)\" && \
git checkout main && \
git pull origin main && \
git checkout - && \
git rebase main && \
git stash pop这样临时改动不会丢，同步完自动恢复。stash 消息带时间戳，方便后续排查。
小提醒：别在团队共享分支上 force push
自己本地的 feature 分支放心 rebase 和 force push（git push --force-with-lease）；但一旦推送到远程并有人基于它开发，就改用 merge，避免打乱别人的工作流。