1
amoblin 2013-03-07 22:02:56 +08:00
好文章!打算有机会实践一下Github Flow。
|
2
shanks 2013-03-08 00:22:59 +08:00
up主的网站UI挺不错的样子,求问怎么实现的?
|
3
clowwindy 2013-03-08 00:39:40 +08:00
加一点比较好,一旦 master 接受一个 PR,其它 PR 要重新 rebase 之后才能被接受,保证 merge PR 是纯 fast forward 的。
|
6
hooopo OP @clowwindy master分支是直的没有任何意义。master分支应该能体现各个功能的并行开发状态,这样容易追踪bug和直观看出哪些commit属于哪个功能。还有一个优点是可以方便的revert/reset一组相关commit。
所以 merge到master/develop分支一定要加--no-ff参数。 rebase或squash一般在本地分支比较好,让本来应该是直的线索是直的。 |
9
joshokn 2013-03-08 10:38:37 +08:00
尝试过gitflow一段时间,感觉将merge这种事情交给工具做真不靠谱。尤其是多branch同时开工的情况下。如果你的环境很简单,确实可以省些力气
|
10
clowwindy 2013-03-08 18:25:47 +08:00 via iPhone
@hooopo pr rebase 之后 diff 只包含这个功能,不像 merge 那样 diff 没法看
|
11
hooopo OP @clowwindy 不存在你说的merge diff无法看的问题啊 一个PR包含的更改就是从master fork出分支状态到merge进master状态,看diff就是看fork点和merge点的变更。
如果每个分支上的开发者都需要关心其他分支的变更,并且rebase和解决冲突,这样就把并行开发变成了线性开发了。 |
12
WarWithinMe 2013-03-11 09:57:59 +08:00
想问一下,为了确保master总是能deploy,测试人员总是需要将master合并到分支dev中,然后进行测试吗?
如果这个测试期间有其他分支合并到master的话,那么当前的dev分支怎么办?再合并然后重新进行测试? |