应使用 git cherry-pick 精准同步指定提交，它重放变更并保留原始提交信息；切到 a 分支后，用 git log 查哈希，再执行 git cherry-pick 哈希列表；操作前需先 fetch 并更新本地 a 分支以避免冲突。
想只同步 b 分支的几个提交到 a 分支，用 git merge b 会全量合并，错
直接 git merge b 是把 b 分支从其与 a 的共同祖先开始的所有新提交一股脑塞进 a，容易带入未完成功能或干扰性修改。这不是“同步部分代码”，而是“合并整个分支历史”。真正需要的是精准搬运——只挑出那几个你确认过、测试过、必须上的提交。
git cherry-pick 是唯一靠谱的选择
它不关心分支关系，只认提交哈希值，把指定提交的变更内容“重放”到当前分支上，保留原作者、原提交信息（除非加 -x 或手动编辑），是最干净的部分同步方式。
- 先切到目标分支：
git checkout a - 查 b 分支的提交列表：
git log b --oneline -n 20（-n 20防止刷屏） - 复制你要的提交哈希（比如
f8d2c1a和a5c672d） - 执行搬运：
git cherry-pick f8d2c1a a5c672d（支持多个哈希空格分隔） - 有冲突就解决，然后
git add . && git cherry-pick --continue
别用 git checkout b -- path/to/file 同步文件
这个命令只是把 b 分支里某个文件的**当前快照**覆盖到 a 分支的工作区，随后 git commit 会产生一个全新提交：作者是你、时间是现在、message 是你写的——原提交历史彻底丢失。线上排查时根本看不出这个逻辑是谁在哪天加的，也追不到原始 diff。
- 它适合临时取个配置文件、补个缺失资源，但不是“同步代码”
- 如果真要保留历史，必须走
cherry-pick，哪怕只是一个文件的修改 - 注意：
cherry-pick选中的提交如果依赖 b 分支其他未被选取的提交，可能编译失败或行为异常——得自己验证
同步前务必确认 a 分支已拉取最新远程状态
很多人在 a 分支本地改了几行就急着 cherry-pick，结果合并后发现和远程 master/develop 已经脱节，后续 push 被拒，或者引发隐性冲突。安全做法是：
-
git fetch origin（拉取所有远程分支最新引用） -
git rebase origin/a或git merge origin/a（让本地 a 跟上远程） - 再执行
cherry-pick，否则你 pick 的是旧基线上的提交，可能和远程已有变更重叠或矛盾
cherry-pick 本身不解决依赖关系，也不自动校验是否已在目标分支存在——这些都得人来判断，最容易漏掉的就是“这个提交其实上周已经被别人合过了”。
