这是一个创建于 2666 天前的主题，其中的信息可能已经有所发展或是发生改变。
我和合伙人，对一个昨晚的 commit，在没有相互交流的情况下，分别做了一些更改，也都提交了 commit
就是说 ，commit a，现在成了 commit b 和 b'，这俩 commit 肯定有冲突，而且不只一个文件有冲突。
代码放在 github 上，现在 github 上是 commit a，我俩本地仓库是 b 和 b'
请教怎么改？
据说用 git rebase ？ 文档没看明白，特来求助！
小项目，就只有一个 master branch。
就是说 ，commit a，现在成了 commit b 和 b'，这俩 commit 肯定有冲突，而且不只一个文件有冲突。
代码放在 github 上，现在 github 上是 commit a，我俩本地仓库是 b 和 b'
请教怎么改？
据说用 git rebase ？ 文档没看明白，特来求助！
小项目，就只有一个 master branch。
 |
1
xcatliu 2017-07-24 13:42:38 +08:00 via iPhone
更改 commit ？ force push 了吗？
|
 |
2
takeoffyoung 2017-07-24 13:44:11 +08:00
不太明白什么叫对 commit 的修改。
是你们基于同一个分支都做了 commit --amend 么？ 不管什么情况，一个人先在本地把 commit 做成期望的样子，提交一个新的分支。另一个 fetch 这个分支之后，rebase 到自己的分支上。保留两个人的操作。 [git 教程]( https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/) |
 |
3
vjnjc 2017-07-24 13:44:48 +08:00
看起来是 2 个人都没有 push，一般来说是后 push 的人来解决冲突。
像这种修改了同一处地方的 commit，没法用自动的解决冲突吧。 |
 |
4
k9982874 2017-07-24 13:47:40 +08:00
既然是对同一个问题做出了重复的修改，那就看看用谁的，另一个人的代码回滚掉就行了。
|
 |
5
jzdxeb 2017-07-24 13:49:03 +08:00
- git fetch --all
- git rebase origin/master > 解决冲突 然后 git rebase --continue - git push 希望有帮助 |
 |
6
ericgui OP |
|
7
ericgui OP @takeoffyoung 我俩 基于同一个版本 a，分别 commit 了新版本 b 和 b ‘
|
|
10
takeoffyoung 2017-07-24 13:59:46 +08:00
1. 合并的时候手动解决冲突
2. 一个人回滚，基于另一个人的提交再来一次。 |
|
11
jzdxeb 2017-07-24 14:00:35 +08:00
少用 pull 多 fetch merge/rebase 会很少出错 。
个人理解。 pull 他的代码再打你的 patch 也可以。 pull 之前 git format-patch -num 备份自己的修改 pull 完了再 git am 自己的修改 只不过这种方式感觉更麻烦些 |
 |
12
besto 2017-07-24 14:03:48 +08:00
1. 这个时候谁先 merge 都可以了，谁节约时间
2. 手动 merge 一次是必须的（除非完全没冲突），无论谁先 merge，另一个人的做的，无外乎 rebase/cherry-pick/am |
 |
13
030 2017-07-24 14:21:52 +08:00 via Android
rebase 这种毒瘤操作别误人
让先 commit 的人 merge 到 master，然后后面的 pull 下来 merge 再添加一次 commit 后 push |
 |
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 到合并的原分支。 |
 |
16
lancerliu 2017-07-24 14:43:12 +08:00
只是很简单的冲突问题啊，不需要 rebase 这种多余的操作的。
前者 push 后，后者先 commit，然后发生 push 的时候有冲突，然后后者 pull 下来，解决冲突（可能要手动解决），然后在 merge 后在 push，最后 merge 到 master |
 |
17
msg7086 2017-07-24 15:46:05 +08:00  1
@030 单 commit 冲突滥用 merge in + merge back 在 change log 上污染主线才是毒瘤。
|
|
18
msg7086 2017-07-24 16:08:26 +08:00 3
 我可以接受 1 或者 2，但是绝对不能接受 3。 两个提交合并已经造成无用 Merge 了（而且冲突的合并会隐藏在 Merge 中而不是 Commit 中），更不说一个团队一起干活了。这种场景下不 Rebase 根本不能看。 |
 |
19
QAPTEAWH 2017-07-24 16:15:22 +08:00
git 初学者先忽略 rebase，用 merge。这个情况 rebase 是更好的办法，但你现阶段不用了解。
“我以为会有更高大上的办法解决问题。”：从管理 commits 的角度，当然是有的，不需要回滚。但是如果更改有冲突还是要靠人工合并的。 两个人分别 push，后者会 push 失败，然后跟着 git 的提示一步一步走就行了。 |
 |
20
tywtyw2002 2017-07-24 16:35:11 +08:00
用 rebase 随意合并 commit 的。
squash = use commit, but meld into previous commit |
 |
21
liuzhen 2017-07-24 16:39:16 +08:00
merge
|
 |
22
DaPanda 2017-07-24 17:01:02 +08:00
rebase 跟你现在的解决思路不矛盾吧，最后再用 rebase 把两个人的 commit squash 了就好。这个还是很有用的，不然两个 commit 是解决的同一个问题就比较乱。
|
 |
23
mcfog 2017-07-24 17:37:34 +08:00 2
送一张图给说 merge 的，尤其还说 rebase 不好的同学
 另外，pull 命令有`--rebase`开关，比手动 fetch&rebase 省力不少 |
 |
25
yuankui 2017-07-24 22:30:58 +08:00
这不就是最基本的分支合并吗？
git merge origin/master |
 |
26
anubiskong 2017-07-24 22:41:22 +08:00
这个难道不是最简单的那种。。。rebase 其中一个。。。然后再 rebase 另外一个吗。。。
|
|
27
ericgui OP @QAPTEAWH 谢谢，你这个思路是个好思路，我下次试试，不试总是没法提高的。其实 git 的提示挺靠谱的，我已经根据 git 的提示，学到了不少东西了。
|
 |
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。 |
|
29
hugo775128583 2017-07-25 00:24:48 +08:00 via Android
#28 想了想不太确定现在冲突的情况，上述操作也可能要解决不少冲突。
|
 |
31
wweir 2017-07-25 08:14:19 +08:00 via Android
merge 有一个 fast forword 的开关，可以达到类似 rebase 的效果。
rebase 有 rebase 的好处，merge 有 merge 的好处，rebase 分支线看着爽，merge 好追踪。具体选哪个无所谓，前后保持一致就行 |
Select Language