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

[ericgui]

我和合伙人，对一个昨晚的 commit，在没有相互交流的情况下，分别做了一些更改，也都提交了 commit

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

请教怎么改？

据说用 git rebase ？ 文档没看明白，特来求助！

小项目，就只有一个 master branch。

[xcatliu]

更改 commit ？ force push 了吗？

[takeoffyoung]

不太明白什么叫对 commit 的修改。

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

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

[git 教程]( https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/)

[vjnjc]

看起来是 2 个人都没有 push，一般来说是后 push 的人来解决冲突。
像这种修改了同一处地方的 commit，没法用自动的解决冲突吧。

[k9982874]

既然是对同一个问题做出了重复的修改，那就看看用谁的，另一个人的代码回滚掉就行了。

[jzdxeb]

- git fetch --all
- git rebase origin/master
> 解决冲突 然后 git rebase --continue
- git push

希望有帮助

[ericgui]

@vjnjc
@k9982874 你俩说的方法和我想的一样，只是我有点不甘心，有点没经验，我以为会有更高大上的办法解决问题。那我 就回滚到前一个 commit 吧。然后再 pull 他 push 到 github 上的 commit 吧。

[ericgui]

@takeoffyoung 我俩 基于同一个版本 a，分别 commit 了新版本 b 和 b ‘

[ericgui]

@xcatliu 还没 push

[ericgui]

@jzdxeb 谢谢，我回滚 了，然后再 pull 他的代码，似乎也只能这样了

[takeoffyoung]

1. 合并的时候手动解决冲突
2. 一个人回滚，基于另一个人的提交再来一次。

[jzdxeb]

少用 pull 多 fetch merge/rebase 会很少出错 。
个人理解。
pull 他的代码再打你的 patch 也可以。
pull 之前 git format-patch -num 备份自己的修改
pull 完了再 git am 自己的修改

只不过这种方式感觉更麻烦些

[besto]

1. 这个时候谁先 merge 都可以了，谁节约时间
2. 手动 merge 一次是必须的（除非完全没冲突），无论谁先 merge，另一个人的做的，无外乎 rebase/cherry-pick/am

[030]

rebase 这种毒瘤操作别误人
让先 commit 的人 merge 到 master，然后后面的 pull 下来 merge 再添加一次 commit 后 push

[jzdxeb]

@030 为什么说是毒瘤？

[cxbig]

楼主恐怕还是用 SVN 的思维在理解 Git
按我的理解是 LZ 和伙伴同时在同一个 branch 的 commit A 下，各自在本地提交了 commit B，两个 B 内容不一致。

建议如下：
双方都在各自的 Commit B 新建一个不同名的新分支，原分支都 Reset 到 Commit A ；然后 push 到远程；互相查看代码，看用谁的合适，把他的 merge 到原分支。另一人的新分支或丢弃或摘出有用的继续 commit 到合并的原分支。

[lancerliu]

只是很简单的冲突问题啊，不需要 rebase 这种多余的操作的。
前者 push 后，后者先 commit，然后发生 push 的时候有冲突，然后后者 pull 下来，解决冲突（可能要手动解决），然后在 merge 后在 push，最后 merge 到 master

[msg7086]

@030 单 commit 冲突滥用 merge in + merge back 在 change log 上污染主线才是毒瘤。

[msg7086]

我可以接受 1 或者 2，但是绝对不能接受 3。
两个提交合并已经造成无用 Merge 了（而且冲突的合并会隐藏在 Merge 中而不是 Commit 中），更不说一个团队一起干活了。这种场景下不 Rebase 根本不能看。

[QAPTEAWH]

git 初学者先忽略 rebase，用 merge。这个情况 rebase 是更好的办法，但你现阶段不用了解。

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

两个人分别 push，后者会 push 失败，然后跟着 git 的提示一步一步走就行了。

[tywtyw2002]

用 rebase 随意合并 commit 的。

squash = use commit, but meld into previous commit

[liuzhen]

merge

[DaPanda]

rebase 跟你现在的解决思路不矛盾吧，最后再用 rebase 把两个人的 commit squash 了就好。这个还是很有用的，不然两个 commit 是解决的同一个问题就比较乱。

[mcfog]

送一张图给说 merge 的，尤其还说 rebase 不好的同学



另外，pull 命令有`--rebase`开关，比手动 fetch&rebase 省力不少

[Reficul]

@mcfog 这个代码树很漂亮。

[yuankui]

这不就是最基本的分支合并吗？

git merge origin/master

[anubiskong]

这个难道不是最简单的那种。。。rebase 其中一个。。。然后再 rebase 另外一个吗。。。

[ericgui]

@QAPTEAWH 谢谢，你这个思路是个好思路，我下次试试，不试总是没法提高的。其实 git 的提示挺靠谱的，我已经根据 git 的提示，学到了不少东西了。

[hugo775128583]

原分支 x 上 reset 到 commit a，checkout 新的 branch y，add commit changes。
checkout 回分支 x，pull origin （拉取同事的修改，更新到 commit b'），cherry-pick 分支 y 上的 commit。

[hugo775128583]

#28 想了想不太确定现在冲突的情况，上述操作也可能要解决不少冲突。

[Wolther47]

@030 题主这种情况就应该用 rebase

[wweir]

merge 有一个 fast forword 的开关，可以达到类似 rebase 的效果。

rebase 有 rebase 的好处，merge 有 merge 的好处，rebase 分支线看着爽，merge 好追踪。具体选哪个无所谓，前后保持一致就行