你们的团队，不管大小，是怎么用 git 进行协作开发的？

[oppoic]

master 分支维护一个稳定的可以发布的版本，这个版本不允许任何人直接提交，仅有管理员通过合并的方式进来代码，另一个 dev 分支是大家平时开发的分支。那么问题来了：

1 ）让团队里每一个人都有权限 push 代码到 dev 分支？

2 ）还是让大家 fork 一份 dev 分支，然后本地开发。开发完成了再发 pull request，管理员检查没问题后进到 dev 分支，再 master 分支 merge 下 dev 分支的代码？ 第一种方式遇到 svn 选手不停的提交代码可能会代码不必要的麻烦，第二种情况没这个问题，但是略繁琐。

大家一般怎么处理？完美的 git 协作是什么样子的？

[msg7086]

[msg7086]

不管怎么做，对程序员的能力都有要求。
既然是工作了，那就拿出点专业精神来，把工作做好。

[relsoul]

遵循 git flow 流程,
master 分支严格对应线上版本，develop 分支对应开发版本,每次提交都需要 code view, feature/* 则为各自的功能分支,开发完毕后合并 develop 分支,再从 develop 分支打包 release 分支版本，测试结束后发布上线

[Jeremial]

master 只有管理员可以合并 pull request
特性分支从 master checkout 新分支进行开发
开发完成后, 将特性分支发 PR 合并进 develop 分支, 在 develop 环境联调
联调完成后, 将特性分支发 PR 合并进 qa 分支, 由 qa 进行测试
测试完成后, 将特性分支发 PR 合并进 master 部署

[msg7086]

补充一下提交流程。
master 或者 stable 是稳定版，是可以部署给客户或者线上的版本。
dev 或者 master （看你们的命名习惯）是主线 /开发版，是每个功能完整提交合并后的分支。
feature 分支则是每个 story 一个，会频繁 rebase 和 interactive rebase，开发时要求频繁提交，完成时要求按照大功能 squash 整理（比如数据库结构修改一个提交，后端 API 数个提交，前端页面数个提交等等），尽量保证每个提交都可以单独回滚。
feature 分支合并前需要做 Code Review。我们并不拘泥于 Merge Request，一般就是同事之间招呼一下，签出提交看几眼，没问题就给过的。如果你们对代码质量要求高，可以用 MR 然后指定 2 名或者以上的同事来做 Review。
合并的话谁都有权做，但是有权不代表就可以随便合并，还是要另一名同事给过了才合并。

代码我们是测试驱动开发的，所以跑通测试的话问题不是很大，如果有意外出现的话，可能会回滚主线提交，或者在主线上再打补丁。

[janxin]

复杂的是 git flow

简单的就是 master/develop

[GTim]

哎，一个分支开发到尾～，如果不是有 git 大牛坐镇，真的不如 SVN

[ducklyl]

大的项目用 gitflow，小的话，直接 master/develop，master 管理员维护，develop 其他都可以 push 上来。管理员 merge 进 master 再检查。

[mywaiting]

说到用 git 进行协作，脱离团队大小、人数多少来谈是没有意义的

一两个人的话，聊天工具沟通一下，然后选择各自开发，直接合并到 master 分支即可，人少，搞太多流程简直内耗，觉得只用 master 分支不好的话，多开个 dev 分支也不错

十来个人的团队的话，这就要规范一下下了，各自有自己的分支，然后 PR 合并到 master，master 推送到测试环境测试通过就自动 deploy

要是再多人的话，那就只有严格按照 git flow 了，按照团队的功能开分支，逐一合并，最后合并到 master 分支，中间穿插 code review，生成代码质量报告，分环境进行测试，合成个人周报月报等等等

还是看人数吧，人少都好办，人多就麻烦

我自己的项目，开坑到现在都只有 master 分支~ [手动狗头~]

[my3157]

了解下 git flow

[ifaii]

git flow + gitlab merge requests

[fire9]

github 和 gitlab 的 Git flow 流程不一样. 建议团队自己做一套适合自己团队的 git flow.