团队内部使用gitlab的fork&pull request模式的不解

Question

如题。
现在公司使用的是gitlab，大概使用流程入下：
1.老大创建一个主仓库mainrepo
2.每个成员fork一份mainrepo
3.在自己fork出来的代码里做开发
4.开发完成后发出一个合并请求，等待老大合并代码
5.如果主仓库有新更新，先fetch,然后合并到自己的仓库里

我感觉这样做好麻烦啊，而且git的分支优势体现的不是很明显。
大家觉得这种工作模式怎么样？

Answer 1

两种方式:

1. 大家使用同一个仓库进行合作开发,分支开发功能,开发完毕,建立merge request,进行code review,最终合并到develop分支

2. 也可以大家 fork mainrepo, 开发完毕后,建立pull request到mainrepo
   由管理代码的人进行合并

使用第二种方式的好处:

• 保护 mainrepo, 所有的合并操作必须使用pull request, 不能简单的进行merge

• mainrepo的分支更加的简洁,不会包含多余的分支

• 个人维护自己私有仓库内的分支,不会出现创建分支时重名的情况

• 个人强调贡献代码,向mainrepo贡献更多的代码

Answer 2

这样做当然是可以的，你们老大这么做大约也有他的原因。
不过这种方式管理就很集中，不太符合 git 分布式的思路，所以使用 git 并不太匹配。

Answer 3

嗯，这样确实没发挥出分支的优势。
不应该只有一个mainrepo分支。 应该按需求分出develop，feature,hotfix分支等。这样在相应的分支上开发。

Answer 4

我理解的步骤

• 老大创建库

• master 指定 老大才能merge

• 创建 dev库，作为测试环境库，也只有老大或者指定管理才能merge。

• 各个开发创建自己的分支，然后push到远程厂库，然后老大或者管理，到dev merge，push上来的分支。

Answer 5

可以考虑使用gerrit的方式进行code review