冲突多，看看是不是代码结构不太合理，为什么很多人要同时改动同一个文件？

@horizon 这个图一看就有问题， 至少要有一个对应线上版本的分支不能每个分支都是一直变动的，可以是 master 也可以是其他。
假如 master 是对应线上版本的，那 master 只能接受来自发布分支(release&hotfix)的合并，原则就是没上线的功能不能合到 master 。hotfix 和 release 可能是并行存在的，那 hoftix 发完同时要合并到 master 和 release ，那这样中间再开 hotfix 以及发布和新开 release 分支均不会漏 hotfix 内容。

学 Linus 呗
每个部门自己拉一个 branch
部门内部再从部门的 branch 拉各自的 feature
完成了就 commit 自己的 feature, 部门负责人就负责 review 然后把 feature merge 到部门 branch
CTO 就负责从部门 branch merge 到 master

如果另外还需要 test 或 release 就都从 master 分

@liuchengfeng1 复杂的有 git workflow
简化版 github flow
没有最优解，flow 最终会取决于实际的组织结构

开发从 master 拉 ft ， 然后测试环境 test ，最后上线用 release

我们领导喜欢不同分支间用 beyond compare 合并代码。

1. 拆。项目、服务、模块进行拆分，不同代码库
但个代码库避免过多人维护，一般一个代码库 2-3 人维护；若不满足，则拆分代码库

2. master/dev 分支，dev 为开发分支，每个人开发都是直接在 dev 开发
a ） 1 天至少从 dev pull 一次代码（合并，基本不会冲突），子功能开发完（单元测试通过或编译通过），提交 dev
b ）测试后，dev 合并至 master

个人经验：冲突可以从代码设计上解决，而不是 git 工作流上优化，有一些冲突是无法避免，如果经常遇到同一个文件的冲突，我建议从代码结构上进行拆分优化。

永远从 master 新切分支，dev 是一个测试汇总池子，所有改 bug/迭代的分支 等汇聚 dev ，发布 pro 时按需 mr （合并请求） mster ，编译打包发布，永远不从 dev 合并 master 。

@gorvey 这个肯定要统一 eslint 或者 prettier 的配置文件