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

[miketeam]

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

[zhangsen1992]

每次 变更完立马 commit merge 别人再 pull 否则攒一堆冲突

[contmonad]

用一些新出的更好的工具。关键词：patch-based VSC, semantic merge

[lwldcr]

每天先 pull --rebase, 再开始干活

另外 代码如果拆分的好的话 单个文件只有 2、3 个人需要修改它 这样出现冲突也好解决一些

[ittianyu]

后端：微服务(一人负责几个项目)
移动端：分模块(一人负责几个模块)
前端：有请下面的大神来回答

[firefox12]

很好办的 gerrit 每个人 gerrit 提交 ci 过了再提交，有冲突了 自己打回去重新做。rebase 了 编不过了 你来负责。总之先进去的一定是有优势的，后进去的 需要解决冲突，这个永远不能避免

[ai277014717]

根据模块分工，然后单元测试。先提交先走人。

[miketeam]

就是用 beyond compare

[tairan2006]

git flow，定期合并

[ai277014717]

每次小版本结束就 merge 到 master 上然后开一个新的 develop-1.1xx 分支，大家在上面开发。

[miketeam]

也正是用 gerrit ……

[scriptB0y]

能往主分支合并代码的不应该只有 develop 分支和紧急的 hotfix 分支吗？不然区分主分支和 develop 还有什么意义？

[miketeam]

@scriptB0y
情况是：主管让我们在 develop 分支开发验证好没问题，然后自己去理清代码上传到 master 分支…

[banksiae]

应该是分支没开对，各种分支合并的操作流程出问题了

[precisi0nux]

借助工具吧，比如 jet brains 有些有冲突的代码可以智能合并，完了自己再检查一下就好了，能省不少事。

[pkookp8]

复杂的代码先合，简单的代码后合
没事就把别的分支的代码合到自己分之上

[Alex6]

楼上说的都挺好的，比如任务拆分，禁止直接推送 develop，master 等。
建议你们小团队可以搞这样一个习俗，不管什么分支代码，只要在该项目内，比如是拉出的 feature 开发分支，那么保持提交点是一条直线，谁要是玩花了，请客喝水吃零食！
至于 feature 分支合到 develop 上冲突很多，那显然是模块任务划分不清，或者是需求不明，很多人在同时在改同一个地方。那是组织需求的问题了，这是属于是做不做。而代码的维护和管理是怎么做。

[0Kelvin]

我只要改完一块东西必然提交，怕自己这工作的破电脑忽然哪天就跪了。

[nekoyaki]

要么是你们自己工作流程的问题，要么是把 git 当 svn 用了……

[sampeng]

1.模块化不够好。改一处要动其他地方
2.每日提交合并。你需要一根假 master 分支，对，就是测试分支。这个分支和 master 分支是时刻同步的，最少基线是同步。每日提交合并到这根分支上来。如果有测试，测试应该在这根分支上做测试。难道你们在各自的子分支上测试？会累死的。。ok，测试完毕。可以上线了。一个 merge 就完事了。根本不可能有冲突。要冲突也在每日提交的时候解决了。每日提交的时候，开发分支需要 rebase 合并好了的结果。然后接着干。

[sampeng]

当然，我实际的使用场景来看。。小于 5 个人压根没这么麻烦。。模块化做好后，没人 commit 也不会冲突。一根线就够了。。其他都是自己折腾自己