“我们那条铁律是——永远不要 rebase 已共享的分支，直接把 master merge 进来。”这是不少企业团队维护长生命周期特性分支时的真实操作。如果你也受够了每次 rebase 带来的历史混乱和合并冲突，一个简单的 Git 别名就能让同步流程丝滑得像喝咖啡。

先看问题。假设你的仓库长这样：主分支 master 已经推进到 D，你的 feature/login 分支只到 F。在开发期间，同事又合入了几个 PR，master 跑到了 I。现在你的分支缺了一大截最新改动。不同步的话，冲突越滚越大，CI 可能莫名其妙挂掉，测试不再可靠，最终的 PR 也会变得难以审查。定期把 master 的最新内容合并进来，就是最简单的保险动作。

手动同步有多烦？你每次都得敲：git fetch，git checkout feature/login，git reset --hard origin/feature/login，git merge --no-ff origin/master，最后再 git push。一周来几十遍，手指真的会抗议。reset 那步还得冒风险，本地没推送的提交会被直接干掉。但如果你本地只是远程分支的一个工作副本，重置反倒能保证和远程完全一致，避免脏状态。

别名一键搞定。运行下面这条命令，全局注册一个叫 sync-branch 的别名：

git config --global alias.sync-branch '!f() {git fetch &&git checkout "$1" &&git diff --quiet &&git diff --cached --quiet &&git reset --hard origin/$1 &&git merge --no-ff origin/${2:-master};}; f'

之后同步 feature/login 只需要：git sync-branch feature/login。如果想从 develop 分支合并，也只要加第二个参数：git sync-branch feature/login develop。别名先 fetch 最新代码，切换到目标分支，检查没有未提交的改动，再重置到远程状态，最后执行合并并保留提交记录。整个流程完全自动，什么思考都不需要。

用 merge 而不是 rebase 的理由就这么直白：保持完整的提交历史，不重写那些可能已经被别人拉取的提交。你的合并提交会出现在历史里，谁做了什么、什么时候合并的一目了然。对需要审计和多人协作的环境来说，这比 rebase 的安全感高出一个量级。

花两分钟把别名配好，下次同步就只敲一行命令，舒服又安全。别再机械地重复 rebase 了，你的分支和手指都会感谢你。