V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
git
Pro Git
Atlassian Git Tutorial
Pro Git 简体中文翻译
GitX
unt
V2EX  ›  git

请教 1 个 git 合并的常见问题

  •  
  •   unt · 2022-07-18 17:28:15 +08:00 · 2276 次点击
    这是一个创建于 619 天前的主题,其中的信息可能已经有所发展或是发生改变。
    从 dev 分出来的两个 feature 分支 A 和 B 。A 开发了一些底层一点的功能,B 开发过程中用得到。B 这时候如何处理呢。
    1. checkout dev
    merge a
    merge b
    2. checkout dev
    merge a
    rebase dev
    3. cherry-pick a
    第 1 条附言  ·  2022-07-19 23:54:27 +08:00

    第二个问题: 我对同事git重命名没有管好,他批量修改了很多文件名(只修改了大小写,导致没有监测到),现在本地和远程仓库一团糟,请问有办法把远程仓库和本地仓库同步吗

    22 条回复    2022-09-26 17:44:10 +08:00
    UN2758
        1
    UN2758  
       2022-07-18 17:44:46 +08:00
    我选择把底层依赖的代码 commit 做个 cherrypick
    silentsky
        2
    silentsky  
       2022-07-18 17:48:19 +08:00
    都行,如果仅仅想合并 a 分支中的一个 commit 就用 cherry-pick
    wu67
        3
    wu67  
       2022-07-18 17:48:35 +08:00
    我习惯公用部分直推 dev, 然后其他分支,主动合并 dev 的内容过来. 最后功能开发完, 合并回 dev, 谁晚合并的谁负责解决冲突.
    masker
        4
    masker  
       2022-07-18 17:50:47 +08:00 via Android
    我都是 rebase
    rrfeng
        5
    rrfeng  
       2022-07-18 17:51:39 +08:00
    先 merge A
    然后 B rebase dev

    前提是 A 可靠。
    yuandj
        6
    yuandj  
       2022-07-18 17:55:28 +08:00
    我一般使用 rebase ,这样做可以把代码冲突在 rebase 的过程中解决,从而 merge 到主分支时,就不会报冲突错误了。使用 rebase 可以把提交记录保持线性,路线比较清晰而且美观。
    morty0
        7
    morty0  
       2022-07-18 17:58:32 +08:00
    @UN2758 +1
    Vegetable
        8
    Vegetable  
       2022-07-18 17:59:44 +08:00   ❤️ 1
    让 A 赶紧把底层的功能合并掉,不要攒一大堆不提交,影响别人效率。义正言辞的
    wu00
        9
    wu00  
       2022-07-18 18:12:56 +08:00
    拆成 A 、B 、C 、D...
    A 只开发底层功能,完成后合并到 dev ; B 、C 、D...并行进行业务开发(依赖处搁置)。
    B 、C 、D... 将 dev 分支中的底层依赖 pull rebase 回来,缝合-测试-提交-合并
    unt
        10
    unt  
    OP
       2022-07-18 18:18:27 +08:00
    @yuandj #6 现实情况好像是有些公司禁止 rebase,有些公司提倡 rebase
    yuandj
        11
    yuandj  
       2022-07-18 18:29:25 +08:00   ❤️ 1
    @unt #10
    使用 rebase 有个原则:永远不要对已经提交到远程的分支进行 rebase ,否则已经拉过此分支的同事都会抓狂。
    所以平时开发只对你本地的临时开发分支进行 rebase ,对别人来说是毫无影响,并且是无感的。他们只能感觉到你的提交永远是一条线,很干净
    unco020511
        12
    unco020511  
       2022-07-18 18:29:35 +08:00
    我一般是 pick
    darknoll
        13
    darknoll  
       2022-07-18 18:50:53 +08:00
    就 cherry-pick 得了
    unt
        14
    unt  
    OP
       2022-07-18 19:32:39 +08:00
    如果 AB 两个都完成了开发,这时候 dev merge a, dev merge b 把两个 feature 分支都合并入 dev 分支, 然后开始进行下一阶段开发,我现在是把 ab 两个分支删掉,然后重新从 dev chekout 出新分支 featureA2 ,featureB2 ,这样操作对吗,有更好的操作方式吗
    xboxv
        15
    xboxv  
       2022-07-18 22:20:32 +08:00 via Android
    我觉得你依赖他的那个 commit ,或者哪个 commit 中的某个 file 的修改,然后 cherrypick 过来就可以了。
    所以我想不通这个方案会有什么缺点吗?
    DrakeXiang
        16
    DrakeXiang  
       2022-07-18 22:44:58 +08:00
    你们都这么注意 commit 么,我感觉很少有阅读 commit 的情况,前公司还要求都用 rebase ,但是碰到过两次不知道什么情况丢失修改的情况,现公司就直接 merge ,所以这种的话如果 A 的开发基本完成了,那么我就直接在 B 上 merge A ,后面哪边先合 dev ,后合的就处理冲突之类的
    unt
        17
    unt  
    OP
       2022-07-18 23:14:03 +08:00 via iPhone
    @DrakeXiang 那不行吧,两个特性分支互相 merge
    nothingistrue
        18
    nothingistrue  
       2022-07-19 09:48:45 +08:00   ❤️ 1
    首先,a 和 b 都是临时特性分支,他们在合并的时候无需区别对待。所以下面的步骤只列出 a ,b 的操作步骤是一摸一样的,a b 的顺序也没有要求。

    非线性历史,传统合并方式:
    checkout dev
    merge a
    如果有冲突,以新提交的方式解决冲突;但是如果 dev 分支是受保护分支,就要在额外的临时分支中解决冲突,然后再合并临时分支。

    准线性历史,变基合并方式:
    1 、checkout a
    2 、rebase dev
    3 、如果有冲突,在 a 上解决冲突
    4 、checkout dev
    5 、merge a
    6 、此时如果有冲突,反转第 5 步(通过 reset --hard 方式),然后回到第 1 步继续

    此外还有完全线性历史的压缩合并方式,但是这个基本不会用到。

    以上合并方式,虽然步骤很多,但是如果在界面操作 Pull Request 或 Merte Request ,就很简单了。


    不建议 cherry-pick 方式,因为你的 dev 、a 、b 是有共同祖先的的,没必要用 cherry-pick 。
    andyJado
        19
    andyJado  
       2022-09-26 11:59:07 +08:00
    @yuandj

    如果新开一个 branch 然后在新开的这个 branch 上 rebase 呢
    yuandj
        20
    yuandj  
       2022-09-26 14:10:32 +08:00
    @andyJado 新开一个分支,是本地还是远程分支呢?在新分支 rebase 之后,新分支是 merge 到主分支,还是单独创建一个远程分支呢?
    如果是本地分支,并且后续需要 merge 到主分支,结论还是和 6 楼的一样。
    如果新分支会推送到远程,那么和普通新分支没什么区别,只是 rebase 的时候可能需要处理一些冲突而已
    andyJado
        21
    andyJado  
       2022-09-26 15:08:26 +08:00
    @yuandj

    对不起我没有表达清楚

    我当时没想明白的点在于, 如果已有一个的分支推到远程, 但自己还在这个分支上工作, 并 rebase 再 push, 相当于翻出公共历史的旧账堆在顶上, 强行续上自己的线性历史. 让自己永远是 commit line 中最连贯的仔.

    >否则已经拉过此分支的同事都会抓狂

    现在想通了, 觉得这个有点搞笑, rebase 远程分支要处理无数 conflict 吧?
    yuandj
        22
    yuandj  
       2022-09-26 17:44:10 +08:00
    @andyJado 是的,如果对远程分支进行 rebase ,那么已经拉过此分支并且进行了本地 merge 的人,再次 pull 时,都需要处理一遍你在 rebase 时处理过的“合并操作”,每个人的处理方法或者逻辑可能会有所不同,那么当多人再次 push 时,可能会产生很多冲突
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1180 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 18:18 · PVG 02:18 · LAX 11:18 · JFK 14:18
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.