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

[miketeam]

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

[likuku]

定时定期，别拖，别积攒。

再多要点人帮你合并

[missdeer]

我们直接 double commit

[StevenTong]

无解吧

[btcking]

公式机制被破坏了，哈哈哈。。

[miketeam]

8000 多行代码，真是日狗了

[nciyuan]

一行一行？
直接看文件，一样的直接略，开发分支优先

[miketeam]

怕覆盖了别人的，5 个人的代码改来改去，受不了了

[XinLake]

不重叠，不遗漏，逐个穷尽，完全独立。
不同的人做不同模块的代码这种情况就少了，你这估计是有多人做同一个事情就变成这样了

[miketeam]

compare 对比，一个个挑，把我自己的先挑出来。

[miketeam]

一部分人开发新模块，然后又有人局部重构

[thundernet8]

以后要让你的队友 开发习惯性 rebase 主分支

[youdiqs]

我们是 git 一个主分支 4 个开发分支
目前没啥大问题，万一有啥问题反正可以回滚。

要是对 git 合并不太信任，或者无法测试是否合并正确 or 难以判断冲突的代码
那就要至少按天来 频繁的合并 才不会导致后期大量堆积代码验证合并。

也可以用 代码比较工具 来进行对代码一行行的对比合并（太难…耗时间）

[chinvo]

团队协作没做好

new branch、pull request 之类的方案要高效率用的基础是团队分工

避免同时针对同一个 feature/bug 作改动

每做到一个阶段就提交一次

[miketeam]

这样合并完了明天又是自虐般的自测试验证了。真的好绝望

[Hieast]

git flow，各自处理各自的 feature 合并到 develop 分支

[miketeam]

你是不知道我们这里 controller 有多重…我现在有空就一点一点的搬。头发都熬白了几根。真真的勇士敢于直面惨淡的垃圾场～

[zjsxwc]

是你们分支太少的缘故吧，不可能只有两个分支，一个主分支 master，一个开发分支 dev，这样合并当然会有很多冲突了。


git 正常使用应该是每个 feature 都从 master 开一个小分支，于是我们工作时会有 n 多小分支，这样既保证了每个小分支可以很容易的（冲突少、逻辑清晰、能快速找到当事人）被合并到 master，又能和 redmine 等项目管理配合起来管理项目，然后定期删除老的 feature 分支就好了。

[miketeam]

你们猜到我这里是几手的代码

[miketeam]

还真是 2 个分支呢

[YyYyYyy]

@miketeam 为什么局部重构会和新模块开发有冲突需要合并？那说明这局部的重构就不是解耦的。
再退一步讲，为什么不用适配器模式把重构部分的对外接口包起来？
建议明天把搞局部重构的那人拉出去枪毙（不要说是我说的 ε===ᕕ(ᐛ)ᕗ