从 main 分支先拉出了 A 项目分支,没有同步回 main, 后面又拉了 B 分支,需要同步 A 项目代码

试试 cherry-pick 吧

这种只能 cherry-pick 然后手工解决冲突了。如果还想再合并回 main 可以先 merge 或者 rebase main

@XiLingHost @xiaoxuxu 谢谢回复。。忘了补充 因为我们提交合并请求里带有 excel 这种文件。。好像 cherry-pick 不过去

checkout from A, rebase main, pick B

```
git checkout B
git rebase A
```
rebase 把 B 的工作基于 A 的基础之上。

在 A 分支找到需要的提交，把这些提交按顺序 cherry-pick 到 B 分支

@fanyer @wellhome 谢谢哈 我试试 rebase 的命令
@virualv 谢谢 但是 cherry-pick 用不了这个场景

首先，A 分支里面的功能很难通过 cheery-pick 处理。大概率 commit 并不是按照单一功能来提交的，并且后续的 bug 修复也会产生非常多的 commit 。所以 cherry-pick 这条路走不通。同理 rebase ，merge 之类的也很难

我建议是如果 A 里面的功能是对 main 的架构完善和补充，可以整理出来这部分代码合回到 main 中
如果只是特定功能或者业务逻辑处理，并且除了 B 难以再复用，那就直接用现在的方案，拷贝过来对比看
如果是通用业务逻辑，可以基于 main 拉取一个分支 C ，再将 A 中代码沉淀到此分支。B 分支再 rebase C

支持 8 楼的建议，另外我觉得你们的问题是软件架构层次框架没有做好，本该分离的东西耦合在一起，版本控制工具解决不了软件架构的问题。

B 要用 A 的部分代码,那当然是 cherry-pick

要我就把 A 分支整理一遍，至少把 commit 分为前面是通用代码，后面是客制化内容，通用代码部分合入主干，之后 B rebase 主干从这里拉出来。如果通用部分合不了主干，至少也能从这里拉出 B 分支

@unco020511 #10 cherry-pick 是对完整 commit pick ，不能对其中每个 commit 的每个文件的多处修改单独 pick 。

还可以 git diff main > patch 以后，单独给 B 打 patch 。excel 文件那种就只能 git checkout A
-- xx.exml 然后再 git add 了。

总体感觉这项目的 git 管理有段乱