关于 git 工作流的问题,从某个节点分叉出去的两个分支,如何高效合并? merge ? rebase ? cherry-pick ?

查看 73|回复 4
作者:Albertcord   
当前问题:
项目从分支 develop 分叉一个项目分支 master 去做项目交付,然后后面开始两个分支的开发,时不时 master 修复 bug ,develop 加特性(两者加的文件有交集)
提给 master 的 mr 偶尔也会 cherry-pick 给 develop ,但是偶尔着急的没这么做,现在两个分支大概有四十五个 commit 的差异(老脸一红,打的补丁缺失多,有些是需求变更,项目着急要),尝试了下 develop rebase master ,发现冲突太多了
想问问有经验的大佬们,这种情况怎么做?
好像最简单的是 git merge ,但是对 merge 有疑虑,担心丢失代码和 git 分支相交太多
还有一种想到的,就是从当时分叉出去的节点的 hashxxxx ,计算哪些没同步提到 develop ,再对这些 commit 做逐步地 cherry-pick 然后提 Merge Request 合并
但模拟了下节点的合并,好像这样最后 develop merge 到 master 也会有冲突,因为 master 多出的节点 A',会放在 develop 多出的节点 B'上,而 rebase 其实是把 B'放在 A'上,保持一条线
也就是现在想到的方法有三种:
[ol]
  • git rebase (develop rebase master)
  • git merge (develop merge master)
  • diff 出 master 比 develop 多的 commit ,逐个 cherry-pick 到 develop
    [/ol]
    还有其他高效方法吗?

    develop, master, merge, rebase

  • maocat   
    相关人员坐一起,然后 merge ,再然后挨个变动问,要不要
    chenliangngng   
    分歧少就 rebase ,分歧稍微多一点(超过 3 个)就 merge
    huangcjmail   
    我们有个项目有两个巨长的分支 master 和 dev ,就是用的 cherry-pick 合并的。开始还好,后面渐渐的就有问题了,会发现有个非常古早的代码没有合并进去。而且长时间没有合并的两个分支,在 idea 里查看分支图的时候也特别不方便。不知道是不是我们 cherry-pick 的姿势有问题。
    leemars   
    你现在这个模式大致上就是 trunk 开发 release 分支发布的模式,trunk = develop ,release 分支 = master ,在这个模式下,release 分支是不应该 merge 回 trunk 的。所以应该选择 「 diff 出 master 比 develop 多的 commit ,逐个 cherry-pick 到 develop 」这条路,再精确点说,应该是「逐一检查 master 上的提交,判断是否需要 cherry-pick 到 develop 」。
    您需要登录后才可以回帖 登录 | 立即注册

    返回顶部