github pull requests 机制讨论

V2EX = way to explore

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

现在注册

已注册用户请登录

› Pro Git

› Atlassian Git Tutorial

› Pro Git 简体中文翻译

› GitX

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

pull requests本质是clone当前repo，然后在自己repo分支上面做开发，提供给clone的repo做merge，目前在github上面三种机制怎么处理的：
1 fast forward 很显然，能够直接merge。
2 not fast forward but auto merge 能智能merge，修改的文件不冲突，会不会相当于git pull然后merge？
3 not fast forward and can not merge 不能智能merge，存在confict，是不是会提示 merge 不成功？

如果在目标repo开发中，和merge的分支进一步不一致，是不是会导致更加不能merge呢？也就是说pull requests应该尽可能快的做吗？

merge

repo

pull

11 条回复 • 1970-01-01 08:00:00 +08:00

BOYPT

2013-04-22 17:35:27 +08:00

不是。

如果出现fork和origin不一致的情况，fork应该先merge origin，再pull request，尽可能少给origin的merge添麻烦。

binux

2013-04-22 17:42:00 +08:00

我猜和本地merge branch行为一致

cloudzhou

2013-04-22 17:42:52 +08:00

@BOYPT 也就是说强制要求fork和origin一致，以便能 fast forward ？
如果一种情况，fork和origin在提交pull requests的时候是一致的（没有什么人修改），所以pull requests也是能成功的，但是在之后又有人在 origin 上面提交，也就是 not fast forward 了，那么在merge pull requests的时候就不允许了？

以上总结：在pull requests的提交方，merge方，是不是都需要fast forward才能通过，也就是fork和origin要求一致？

cloudzhou

2013-04-22 17:45:21 +08:00

@binux 原理肯定是一样的，我不理解的是 fast forward 的不同状态导致合并出现各种情况。比如：是否有智能merge呢？还是要求clone的repo必须git pull以保持和origin repo一致？

cloudzhou

2013-04-22 17:48:22 +08:00

@BOYPT 强制要求fork和origin一致， fast forward 肯定是最简单的。因为没有冲突处理出现。

binux

2013-04-22 17:49:27 +08:00

@cloudzhou 我记得是，只要没有冲突就可以merge

cloudzhou

2013-04-22 17:59:00 +08:00

@binux 如果一次修改了a文件，然后原来的repo变更的其实是添加了b文件，能智能给你merge吗？另外同一个文件不同地方的修改也是能智能merge的，我不知道 pull requests 能支持到什么地步？还是说必须 fork和origin一致， fast forward？

binux

2013-04-22 18:06:48 +08:00

@cloudzhou 我记得是可以的，话说试试不就知道了，自己的两个分支也可以pull request的

cloudzhou

2013-04-22 18:14:05 +08:00

@binux thanks，我只是想看看能不能找到非常了解pull requests机制的人，看来也应该就是这样子的。

BOYPT

2013-04-22 18:37:57 +08:00

@cloudzhou 我就看不明白你的问题在什么地方。

fork第一次的时候是拿了一次origin的代码，你之后commit，origin其他人也commit，到你确定完成的时候，先pull一次人家的代码，meirge成功后形成一次新的commit，以这个节点为pull request人家就可以最少功夫去merge了。

但实际上大点的项目经常有一大堆pull request，项目的人不一定有时间去检查这些request，会拖一段时间，这样他们合并的时候可能会出现conflict的情况，那就需要人手操作了。

实际上的pull request并不存在允许不允许的问题，只要你的仓库的HEAD和origin的HEAD不一样就可以pull request。减少冲突是处于礼貌。

cloudzhou

2013-04-22 19:08:54 +08:00

@BOYPT hi，谢谢你的回答。

我们的理解是一样的，问题是对github怎么处理冲突和在你提交pull requests的时候会不会检查冲突以及提示你先解决冲突，另外是否会尝试给你智能merge。

在开发的流程中是要保持你说的这种模式。

针对我上面提到的例子，我已经做了实验了：
1 fast forward 明显可以提交 pull requests，也能 merge
2 not fast forward but auto merge 提交 pull requests，github 会给你 auto merge
3 not fast forward and can not merge 提交 pull requests，然后在 merge 的时候提示自行解决冲突

所以目前问题都明白了