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
|
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 好追踪。具体选哪个无所谓,前后保持一致就行 |