V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
git
Pro Git
Atlassian Git Tutorial
Pro Git 简体中文翻译
GitX
Sponsored by
LinkedIn
不坐班的神仙工作 · 去任何你想去的地方远程,赚一线城市的工资
2000 个不用出门 Social 的全球远程工作,帮助 V2EX 的小伙伴开启全新的工作方式。
Promoted by LinkedIn
unt
V2EX  ›  git

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

  •  
  •   unt · 74 天前 · 1814 次点击
    这是一个创建于 74 天前的主题,其中的信息可能已经有所发展或是发生改变。
    从 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 条附言  ·  72 天前

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

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

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

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

    对不起我没有表达清楚

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

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

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