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

[liuchengfeng1]

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

目前我们是这样：

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

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

[fkname]

一个 master 分支，一个 dev 分支，开发都在 dev ，自己 fork 一个仓库提 mr 合 dev ，有 committer 和特性责任人检视，自验完打 tag 出包转测试，每个人提交代码要保证自验和正常启动，每次提交不能超过 500 行。发布时从 dev 合 master 。
线上补丁从 master 拉分支出来修改后双合 master 和 dev 。

[csys]

参考 Releaseflow https://suraciii.github.io/posts/release-flow/

重点：
* 一个主干
* 快速集成
* 自动化测试
* 不要合来合去的

[csys]

多说一句，gitflow 已经成为了现代软件的一种灾难

[wupher]

简单的项目 gitflow

更快速或者高效的团队可以考虑 github-flow 或者 gitlab-flow 。

有奇葩要求的，也可以自己团队商量一套实践。

但是、但是，总会有 2B 的领导或者不写代码的“技术牛人”，跳出来要求“统一”“规范”，最后搞出个缝合怪。

[southsala]

你这个等所有人在一个分支上开发

你可以在 release 上多分出几个分支，一个 feat 或者一个组分配一个 release 的子分支，结合 gitflow 看看

[p1gd0g]

还是能力问题，git 本身够简单了。有的同事死活搞不懂，已合并就覆盖别人。习惯太差

[shijingshijing]

对于中小公司，真心一劝，像 svn 那样中心化来用 git 是最好的，在满足自身业务版本控制需求前提下，流程越简单越好，血泪教训。

[godwinma]

我觉得多人一起开发的时候冲突不可避免，谁后提交，谁解冲突。哈哈。

[panda1001]

我好奇这种做完立即提交，算不算 svn 的方式使用 git ，比直接 svn 好在哪儿了呢
@xuld

[xuld]

@panda1001 手下：报告长官，后方发现有敌人来袭。
你：从后方过来算不算偷袭呢？偷袭是不是不道德？偷袭会遗臭万年的。

[lasuar]

有“经常冲突” 这个问题说明 代码组织结构 有优化空间。

[panda1001]

@xuld 我不是说这样不可以，只是说在项目版本控制的选型上，如果考虑 op 情况和你提供的建议，还选型 git 是想到了哪些优点

[stonesirsir]

建议用 rebase ，不要用 merge ，后期会明了很多

[jiangzm]

@horizon #50 带不带日期没啥区别，带日期难道就不是发布分支了吗。发布分支在发布阶段还是有可能有 bugfix 。
不是我不理解你那个图一看就明白，确实有问题。应该是你没明白我的意思或者你确实不太懂分支管理流程（对叫流程不叫模型）。

还有不规范不代表一定会有问题，一个分支也可以玩，既然用了 gitflow 流程不妨就对齐标准。1 楼的图是很经典的虽然每个公司会有点差异但核心原则要保持一致的。

[horizon]

@jiangzm #73
我那个写的不是 gitlab flow ？
不争论了，确实我比较菜吧。