各位大佬你们团队开发 git 是如何管理的？

[liuchengfeng1]

最好是 10 个人以上的技术团队，你们面对 版本协作开发、版本上线顺序前后不一致、开发途中穿插需求或是解决 bug 、如何减少代码冲突等等，是怎么处理的呢？有什么比较好的 git 管理方法

目前我们是这样：

从 prod 单独拉一个 release 分支，然后 4 、5 个人在这个分支上开发，按功能区分模块，完成后让某个人合到 dev 、test

但是有个问题，开发的人一多，这样特别容易造成代码冲突

[jiangzm]

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

[NessajCN]

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

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

[feiyan35488]

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

[horizon]

@jiangzm #41
release 或者 hotfix 对应线上的
master 作为 upstream branch 保持最新

[allecnm]

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

[Exxfire]

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

[jiangzm]

@horizon #44 图里面 release 是作为发布分支，master 看着像开发/测试分支。
发布分支在发布阶段还可能是变动的怎么可能对应的是线上呢？
master 保持最新是开发功能的最新吗？那就是常规 dev/test 分支功能了，这个没问题很多团队在 master 上开发。
名字其实无所谓，只要有特定的分支做测试/特定的分支做发布/特定的分支对应线上版本 就够了。

这个图里面 feature 从 master 开出来，然后又合并到 master ，理论上就是作为 dev/test 分支功能作为集成测试分支。如果是作为开发/测试分支用，那 feature 分支就不能从 master 开出来了， 一定是一个对应线上版本的分支。

[xsen]

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

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

[xsen]

@xsen 另，个人一般要求团队成员 1-2 天必须提交一次代码

[horizon]

@jiangzm #47
release 所以带日期的呀，又不是只有一个 release 分支
日期对应发布时间的哈
你再理解一下，这套模型支撑过 20 多个人一起开发，没问题的哈。

[0xD800]

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

[sungx1202]

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

[linzhe141]

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

[liuchao719]

@0xD800 说的太对，耦合太重了，或者文件太大导致一个人搞不定。

[qxdo1234]

没有比较好的方案，实际上 git 只是个工具，还是要靠人治，制定 git 工作流，其他的分支 要多从源分支反合并，才能减少冲突，而且也无法确保一定就不出错，git 工具是不会出问题的，只要有人参与做的事情，出问题都是人的问题，

[ChangJingli]

建议了解下主干分支+特性开关管理模型，最近两个大项目实践下来感觉还不错。

https://mp.weixin.qq.com/s/m4N8ugQEM-StNRHV2XJ8KA

[hqpsoft]

每天自动把主干分支反向 merge 到各个 feature 分支, 有冲突尽早解决.

[mark2025]

如果是多版本发布策略，用 1 楼图片那种，如果是单版本滚动发布就用 gitlab flow

[yb2313]

每个小时合并一次主开发分支, 这样就很轻松了

[maninfog]

TBD + Feature Toggle