V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

› Pro Git

› Atlassian Git Tutorial

› Pro Git 简体中文翻译

› GitX

这是一个创建于 2300 天前的主题，其中的信息可能已经有所发展或是发生改变。

先上图:

问题

Bob 如何解决 Anna 的提交?

目前想到的解决办法

Bob: git push -f ,Anna: git pull 解决完再推,此后就正常了.
再 rebase 一遍

其它

想问下还有更优雅的解决办法吗?
暂不考虑更多人的协作,目前只需要处理 Bob 和 Anna 即可,没那么多开发人员......
ps.图片来源,讲述了 git rebase 与 git pull 的问题: https://medium.freecodecamp.org/git-rebase-and-the-golden-rule-explained-70715eccc372

24 条回复 • 2018-07-25 08:40:26 +08:00

randyzhao

2018-07-24 17:51:59 +08:00

要么就是让 bob 别 push，先把 feature 回退到仓库的样子。

不过不大清楚你这里预期想让仓库变成啥样。

fov6363

2018-07-24 17:54:18 +08:00

@randyzhao

最好的预期是 A-B-C-D'-E'
其次的预期是 A-B-C-D'-D-E

will0404

2018-07-24 17:56:31 +08:00

粗略看了下原文，这个图是作者用来举反例的。
这里犯了两个错误：
1. Bob 不应该和 Anna 同时工作在 feature branch 上，应该分别 checkout 新的分支开发。
2. Bob 不应该在 feature branch 上执行 rebase master 的操作而且还 push 上去了。
解决办法就是两人都停下来，等 Anna 解决完冲突后同步一下。

mcfog

2018-07-24 18:01:11 +08:00

Bob 在已知 github 的状态的情况下，不应该做这个把 feature 从 D rebase 成 D'的操作（已经 push 到 remote 的 commit 不应该 rebase ），更不需要解决 Anna 的什么东西（因为 Anna 的 E 压根没有 push，Bob 也不可能得知 E 的信息）

rebase 更多解决的是 Anna 线 push E 到 github，Bob 同时（未拉取最新修改）在 D 上 commit 了变更 F 后，发现 push 失败

此时用 rebase 把 ABDF 变成 ABDEF 再 push,使 feature branch 的结果为一直线，避免增加 merge commit

fov6363

2018-07-24 18:02:24 +08:00

@will0404

抱歉,我想问一下,相同版本的功能不应该开发在同一分支吗? 开发在同一分支的好处是一个功能可以让两个人开发,互相可以看互相的代码.

mcfog

2018-07-24 18:03:59 +08:00

顺便，这个过程的实际操作是 git fetch && git rebase （取代 git pull ），现在 git pull 增加了 `--rebase` 开关可以直接用

fov6363

2018-07-24 18:04:51 +08:00

@mcfog
您好,一个场景是 Bob 在 rebase master 的时候,Anna push 了自己代码到远程分支, Bob rebase 完毕后再 push 时会失败..

mcfog

2018-07-24 18:10:52 +08:00

@fov6363 我觉得你没看我的回答

fov6363

2018-07-24 18:14:20 +08:00

@mcfog
我看了...我理解你的观点是开发时候不要这么做.....现在的场景是 Bob 已经这么做了,所以我想是否有更好的解决办法...

randyzhao

2018-07-24 18:17:48 +08:00

Anna：我什么都没干啊，操作也很规范啊。

所以如果我是 Leader，就让 Anna 正常 push 先，让 Bob 自尝苦果，下次他就不会乱来了。

fov6363

2018-07-24 18:22:43 +08:00

@randyzhao
good idea

junwuhui

2018-07-24 18:24:23 +08:00 via Android

论 pr 的重要性

ai277014717

2018-07-24 18:27:52 +08:00

Anna 的代码过期了，Anna 先搞好。再提交。

mcfog

2018-07-24 18:30:51 +08:00 via Android

@fov6363 已经那么干了的话先让他认识到问题，然后 feature 分支直接 reset 回到 origin/feature 即可，如果 D' 之后又开发了东西，rebase 回去

fov6363

2018-07-24 18:31:32 +08:00

@mcfog
收到,感谢指导~

ryd994

2018-07-24 18:38:02 +08:00 via Android

不要在公共分支上 rebase 或者 push -f，小心队友打死你
解决办法就是 push -f，然后让大家 fetch 再 rebase origin/master，最后自裁谢罪

will0404

2018-07-24 18:43:59 +08:00

@fov6363 无论如何都不应该两个人在一个分支上开发。
不知道你说的同一个功能什么意思，比如前后端在开发一个功能，约定好接口形式后就互相在新的分支上开发，先后合并到 feature 分支上，后者在自己的分支上 rebase feature 分支，这样不会有冲突。

fov6363

2018-07-24 18:54:19 +08:00

@will0404
一个常见的功能场景是: 开发用户的登录注册 API,Bob 开发登录 API,Anna 开发注册 API,比如验证密码方法是共用的,Bob 就可以告诉 Anna 这个方法我开发了,你一会拉我代码直接用就行,一个分支开发就会很方便.....如果是两个分支的就会比较麻烦....我的意思是,如果一个功能在同一分支开发,会比较快, 带来的问题就是合并代码的问题...我觉得多人开发同一分支是常见操作....

h404bi

2018-07-24 19:10:15 +08:00 via iPhone

分支设保护禁止 force push，Anna 正常 push，Bob 发现 push 不了，只能再 reset/rebase 回去。Bob 认栽，下次不敢再乱 rebase。

如果 Bob 已经 push -f 了，Anna 只好 rebase 再 push （然后打 Bob 一顿。

randyzhao

2018-07-24 19:31:10 +08:00

@fov6363 #18
多人用一个远程分支其实是省事的操作
你楼上说的是各自有各自的分支，但是合并提交到同一个 feature 分支里。然后 feature 分支正如 @h404bi #19 说的那样，禁止 push -f。
这种操作也能达到你想要的工作流，但是更规范和安全一些。

will0404

2018-07-24 23:24:35 +08:00

@fov6363 你们开发协作这么随意的吗？
任何功能合并到 feature 分支上不用经过 pr?不用 code review?
如果是你说的那么随意，那 master 什么时候合并 feature 分支？什么时候进行 code review ？

drackzy

2018-07-24 23:55:23 +08:00 via iPad

git rebase 之前先 git brance backup_xxx 备份下现有分支，还有后悔药可以吃

bombless

2018-07-25 07:46:08 +08:00 via Android

因为 bob 能看到版本 d，他需要把 e 给 cherry-pick 过来

lrh3321

2018-07-25 08:40:26 +08:00

不要在公共分支上 rebase +1
坑死队友

[git][rebase] git rebase 之后 git pull 如何解决?

问题

目前想到的解决办法

其它