从 main 分支先拉出了 A 项目分支,没有同步回 main, 后面又拉了 B 分支,需要同步 A 项目代码
E0421 · 2023-07-11 10:30:23 +08:00 · 1817 次点击这是一个创建于 499 天前的主题，其中的信息可能已经有所发展或是发生改变。
目前我们是手动比对,不知道大佬们有没有更方便的工具或者思路
补充以下几点,标题没说清的
1.A 和 B 拉分支的时间是不一样的,所以 main 分支的内容也有所不同
2.A 分支的代码因为是项目客制化代码,所以没有同步回 main 分支,B 项目需要用到部分代码(不是全部代码)
补充以下几点,标题没说清的
1.A 和 B 拉分支的时间是不一样的,所以 main 分支的内容也有所不同
2.A 分支的代码因为是项目客制化代码,所以没有同步回 main 分支,B 项目需要用到部分代码(不是全部代码)
 |
1
XiLingHost 2023-07-11 10:31:47 +08:00
试试 cherry-pick 吧
|
 |
2
xiaoxuxu 2023-07-11 10:35:22 +08:00
这种只能 cherry-pick 然后手工解决冲突了。如果还想再合并回 main 可以先 merge 或者 rebase main
|
 |
3
E0421 OP @XiLingHost @xiaoxuxu 谢谢回复。。忘了补充 因为我们提交合并请求里带有 excel 这种文件。。好像 cherry-pick 不过去
|
 |
4
fanyer 2023-07-11 10:47:51 +08:00
checkout from A, rebase main, pick B
|
 |
5
wellhome 2023-07-11 11:27:04 +08:00
```
git checkout B git rebase A ``` rebase 把 B 的工作基于 A 的基础之上。 |
 |
6
virualv 2023-07-11 12:53:17 +08:00 via iPhone
在 A 分支找到需要的提交，把这些提交按顺序 cherry-pick 到 B 分支
|
|
7
E0421 OP |
 |
8
aqw012 2023-07-11 13:14:27 +08:00
首先，A 分支里面的功能很难通过 cheery-pick 处理。大概率 commit 并不是按照单一功能来提交的，并且后续的 bug 修复也会产生非常多的 commit 。所以 cherry-pick 这条路走不通。同理 rebase ，merge 之类的也很难
我建议是如果 A 里面的功能是对 main 的架构完善和补充，可以整理出来这部分代码合回到 main 中 如果只是特定功能或者业务逻辑处理，并且除了 B 难以再复用，那就直接用现在的方案，拷贝过来对比看 如果是通用业务逻辑，可以基于 main 拉取一个分支 C ，再将 A 中代码沉淀到此分支。B 分支再 rebase C |
 |
9
mingsi 2023-07-11 14:38:02 +08:00 via Android
支持 8 楼的建议，另外我觉得你们的问题是软件架构层次框架没有做好，本该分离的东西耦合在一起，版本控制工具解决不了软件架构的问题。
|
 |
10
unco020511 2023-07-11 14:38:19 +08:00
B 要用 A 的部分代码,那当然是 cherry-pick
|
 |
11
LunarG 2023-07-11 14:49:44 +08:00
要我就把 A 分支整理一遍，至少把 commit 分为前面是通用代码，后面是客制化内容，通用代码部分合入主干，之后 B rebase 主干从这里拉出来。如果通用部分合不了主干，至少也能从这里拉出 B 分支
|
 |
12
harrozze 2023-07-11 15:26:10 +08:00
@unco020511 #10 cherry-pick 是对完整 commit pick ，不能对其中每个 commit 的每个文件的多处修改单独 pick 。
还可以 git diff main > patch 以后，单独给 B 打 patch 。excel 文件那种就只能 git checkout A -- xx.exml 然后再 git add 了。 总体感觉这项目的 git 管理有段乱 |
Select Language