V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
ericgui
V2EX  ›  程序员

git:怎样合并两个人对同一个 commit 做的不同新的 commmit?

  •  
  •   ericgui · 2017-07-24 13:38:13 +08:00 · 7586 次点击
    这是一个创建于 2658 天前的主题,其中的信息可能已经有所发展或是发生改变。
    我和合伙人,对一个昨晚的 commit,在没有相互交流的情况下,分别做了一些更改,也都提交了 commit

    就是说 ,commit a,现在成了 commit b 和 b',这俩 commit 肯定有冲突,而且不只一个文件有冲突。
    代码放在 github 上,现在 github 上是 commit a,我俩本地仓库是 b 和 b'

    请教怎么改?

    据说用 git rebase ? 文档没看明白,特来求助!

    小项目,就只有一个 master branch。
    31 条回复    2017-07-25 08:14:19 +08:00
    xcatliu
        1
    xcatliu  
       2017-07-24 13:42:38 +08:00 via iPhone
    更改 commit ? force push 了吗?
    takeoffyoung
        2
    takeoffyoung  
       2017-07-24 13:44:11 +08:00
    不太明白什么叫对 commit 的修改。

    是你们基于同一个分支都做了 commit --amend 么?

    不管什么情况,一个人先在本地把 commit 做成期望的样子,提交一个新的分支。另一个 fetch 这个分支之后,rebase 到自己的分支上。保留两个人的操作。

    [git 教程]( https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/)
    vjnjc
        3
    vjnjc  
       2017-07-24 13:44:48 +08:00
    看起来是 2 个人都没有 push,一般来说是后 push 的人来解决冲突。
    像这种修改了同一处地方的 commit,没法用自动的解决冲突吧。
    k9982874
        4
    k9982874  
       2017-07-24 13:47:40 +08:00
    既然是对同一个问题做出了重复的修改,那就看看用谁的,另一个人的代码回滚掉就行了。
    jzdxeb
        5
    jzdxeb  
       2017-07-24 13:49:03 +08:00
    - git fetch --all
    - git rebase origin/master
    > 解决冲突 然后 git rebase --continue
    - git push

    希望有帮助
    ericgui
        6
    ericgui  
    OP
       2017-07-24 13:53:36 +08:00
    @vjnjc
    @k9982874 你俩说的方法和我想的一样,只是我有点不甘心,有点没经验,我以为会有更高大上的办法解决问题。那我 就回滚到前一个 commit 吧。然后再 pull 他 push 到 github 上的 commit 吧。
    ericgui
        7
    ericgui  
    OP
       2017-07-24 13:54:22 +08:00
    @takeoffyoung 我俩 基于同一个版本 a,分别 commit 了新版本 b 和 b ‘
    ericgui
        8
    ericgui  
    OP
       2017-07-24 13:54:46 +08:00
    @xcatliu 还没 push
    ericgui
        9
    ericgui  
    OP
       2017-07-24 13:55:30 +08:00
    @jzdxeb 谢谢,我回滚 了,然后再 pull 他的代码,似乎也只能这样了
    takeoffyoung
        10
    takeoffyoung  
       2017-07-24 13:59:46 +08:00
    1. 合并的时候手动解决冲突
    2. 一个人回滚,基于另一个人的提交再来一次。
    jzdxeb
        11
    jzdxeb  
       2017-07-24 14:00:35 +08:00
    少用 pull 多 fetch merge/rebase 会很少出错 。
    个人理解。
    pull 他的代码再打你的 patch 也可以。
    pull 之前 git format-patch -num 备份自己的修改
    pull 完了再 git am 自己的修改

    只不过这种方式感觉更麻烦些
    besto
        12
    besto  
       2017-07-24 14:03:48 +08:00
    1. 这个时候谁先 merge 都可以了,谁节约时间
    2. 手动 merge 一次是必须的(除非完全没冲突),无论谁先 merge,另一个人的做的,无外乎 rebase/cherry-pick/am
    030
        13
    030  
       2017-07-24 14:21:52 +08:00 via Android
    rebase 这种毒瘤操作别误人
    让先 commit 的人 merge 到 master,然后后面的 pull 下来 merge 再添加一次 commit 后 push
    jzdxeb
        14
    jzdxeb  
       2017-07-24 14:35:30 +08:00
    @030 为什么说是毒瘤?
    cxbig
        15
    cxbig  
       2017-07-24 14:39:53 +08:00
    楼主恐怕还是用 SVN 的思维在理解 Git
    按我的理解是 LZ 和伙伴同时在同一个 branch 的 commit A 下,各自在本地提交了 commit B,两个 B 内容不一致。

    建议如下:
    双方都在各自的 Commit B 新建一个不同名的新分支,原分支都 Reset 到 Commit A ;然后 push 到远程;互相查看代码,看用谁的合适,把他的 merge 到原分支。另一人的新分支或丢弃或摘出有用的继续 commit 到合并的原分支。
    lancerliu
        16
    lancerliu  
       2017-07-24 14:43:12 +08:00
    只是很简单的冲突问题啊,不需要 rebase 这种多余的操作的。
    前者 push 后,后者先 commit,然后发生 push 的时候有冲突,然后后者 pull 下来,解决冲突(可能要手动解决),然后在 merge 后在 push,最后 merge 到 master
    msg7086
        17
    msg7086  
       2017-07-24 15:46:05 +08:00   ❤️ 1
    @030 单 commit 冲突滥用 merge in + merge back 在 change log 上污染主线才是毒瘤。
    msg7086
        18
    msg7086  
       2017-07-24 16:08:26 +08:00   ❤️ 3


    我可以接受 1 或者 2,但是绝对不能接受 3。
    两个提交合并已经造成无用 Merge 了(而且冲突的合并会隐藏在 Merge 中而不是 Commit 中),更不说一个团队一起干活了。这种场景下不 Rebase 根本不能看。
    QAPTEAWH
        19
    QAPTEAWH  
       2017-07-24 16:15:22 +08:00
    git 初学者先忽略 rebase,用 merge。这个情况 rebase 是更好的办法,但你现阶段不用了解。

    “我以为会有更高大上的办法解决问题。”:从管理 commits 的角度,当然是有的,不需要回滚。但是如果更改有冲突还是要靠人工合并的。

    两个人分别 push,后者会 push 失败,然后跟着 git 的提示一步一步走就行了。
    tywtyw2002
        20
    tywtyw2002  
       2017-07-24 16:35:11 +08:00
    用 rebase 随意合并 commit 的。

    squash = use commit, but meld into previous commit
    liuzhen
        21
    liuzhen  
       2017-07-24 16:39:16 +08:00
    merge
    DaPanda
        22
    DaPanda  
       2017-07-24 17:01:02 +08:00
    rebase 跟你现在的解决思路不矛盾吧,最后再用 rebase 把两个人的 commit squash 了就好。这个还是很有用的,不然两个 commit 是解决的同一个问题就比较乱。
    mcfog
        23
    mcfog  
       2017-07-24 17:37:34 +08:00   ❤️ 2
    送一张图给说 merge 的,尤其还说 rebase 不好的同学



    另外,pull 命令有`--rebase`开关,比手动 fetch&rebase 省力不少
    Reficul
        24
    Reficul  
       2017-07-24 21:14:11 +08:00   ❤️ 1
    @mcfog 这个代码树很漂亮。
    yuankui
        25
    yuankui  
       2017-07-24 22:30:58 +08:00
    这不就是最基本的分支合并吗?

    git merge origin/master
    anubiskong
        26
    anubiskong  
       2017-07-24 22:41:22 +08:00
    这个难道不是最简单的那种。。。rebase 其中一个。。。然后再 rebase 另外一个吗。。。
    ericgui
        27
    ericgui  
    OP
       2017-07-24 23:23:42 +08:00 via iPhone
    @QAPTEAWH 谢谢,你这个思路是个好思路,我下次试试,不试总是没法提高的。其实 git 的提示挺靠谱的,我已经根据 git 的提示,学到了不少东西了。
    hugo775128583
        28
    hugo775128583  
       2017-07-25 00:10:39 +08:00 via Android
    原分支 x 上 reset 到 commit a,checkout 新的 branch y,add commit changes。
    checkout 回分支 x,pull origin (拉取同事的修改,更新到 commit b'),cherry-pick 分支 y 上的 commit。
    hugo775128583
        29
    hugo775128583  
       2017-07-25 00:24:48 +08:00 via Android
    #28 想了想不太确定现在冲突的情况,上述操作也可能要解决不少冲突。
    Wolther47
        30
    Wolther47  
       2017-07-25 07:34:28 +08:00 via iPhone
    @030 题主这种情况就应该用 rebase
    wweir
        31
    wweir  
       2017-07-25 08:14:19 +08:00 via Android
    merge 有一个 fast forword 的开关,可以达到类似 rebase 的效果。

    rebase 有 rebase 的好处,merge 有 merge 的好处,rebase 分支线看着爽,merge 好追踪。具体选哪个无所谓,前后保持一致就行
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1066 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 30ms · UTC 19:37 · PVG 03:37 · LAX 12:37 · JFK 15:37
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.