大神，有每有更好的办法和代码啊，大半夜还在合 啊

[miketeam]

我们主线一个分支，开发一个分支，太多人一起上代码，然后开发分支差主分支好多。现在我大晚上的还将开发分支代码合到主分支，一行行对。你们有我这边折腾吗？求解啊

[miketeam]

想法是好的，我现在改那些代码只能借着修改 bug 去改。主动修改那些代码需要和一堆人讲明情况，拉个 ppt 说明这样改的原因…

[nicevar]

就两个分支....楼主你不累死也是奇迹，人上得多，效率低下
这不是合代码的问题，是你们任务分配组织能力有点差啊，尽量把任务分细了，一个分支对应一个任务或者 bug，限制时间，比如每个任务必须三天内完成，如果评估完不成就再细分，这样代码冲突会降到最低
发布版本的时候迭代做好点，可以一周一小版本，一月一大版本之类的

[miketeam]

我现在最怕的是把别人的代码覆盖了…正在对比，不出意外我马上可以下班了。还有人在奋斗。。

[miketeam]

7 点开始的，中间合了几次，正要上又被抢先了……然后又要拉取代码在看！

[yomiko123]

祝你好运吧

[ryd994]

所以分 pull 党和 rebase 党

[nl101531]

应该不同的人不要做同一块业务...或者分层逻辑下,不同的人写不同的层.中间用接口沟通

[miketeam]

这个不是 rebase 的问题。主分支跑太快了……

[miketeam]

此刻路上已经没有多少人了……内心拔凉拔凉滴

[miketeam]

狠狠滴骂一句：狗屎架构师

[lihongjie0209]

每个人做自己的模块不就好了吗?

[miketeam]

抢出版本，dieline 快来了……

[imNull]

master 加锁，只有 owner 有 Merge 权限。
开发时，每个人一个自己的分支，自己定期合 master，最后提 code review，如果冲突打回重改，最后 owner 合并。

这样子应该没什么问题了，有问题可以再交流

[eccstartup]

deadline

git pull --rebase

[miketeam]

以为代码不多的。原本计划 8 点下班，喝喝茶，写写 go 在睡觉。现在撒都不想直接睡了，太困了……

[akring]

@miketeam 我看的都要哭了，简直人间悲剧

[66450146]

CI 自动从开发分支上 merge 主分支，如果出错的话要求分支作者 rebase / merge 就是了

我们的做法是，没办法 merge without conflict 的改好才做 code review，测试没通过的修好才做 code review，review 不过的重新改

[PureWhite]

@miketeam 楼主，给出一个比较好的实践吧：
1. 禁止直接 push 到 dev 或者 master 分支，必须使用 pull request 才行（ github 会保证合并无冲突，有冲突自己 resolve ），而且必须要 review 通过才行，任何人都没有权限直接合。
2. 所有 pr 要求代码量改动在 100 行之内，方便 review，一般 30 行左右最佳。
3. 把所有的任务无限拆小，越小越好，不停地分解到一个几十行代码的级别。
4. 集成 ci 测试，测试不过不 review 不能 merge，github 是可以设置的，和 circleci 集成很好。
5. **如果不遵守以上的，你干嘛还用 git 啊，大家直接改 ftp 的文件不得了，不按照流程走一切工具和方法论都无用。**

[swulling]

配置 push 只允许 fast forward，如果出现冲突，由提交代码的人自行解决，不解决无法合入

简单讲，谁的代码先入库，其他人就得解决冲突。

[last]

祝你好运哈哈，我期末作业就四人的代码都弄得头疼