问题描述
如题。现在公司使用的是gitlab，大概使用流程入下：1.老大创建一个主仓库mainrepo2.每个成员fork一份mainrepo3.在自己fork出来的代码里做开发4.开发完成后发出一个合并请求，等待老大合并代码5.如果主仓库有新更新，先fetch,然后合并到自己的仓库里
我感觉这样做好麻烦啊，而且git的分支优势体现的不是很明显。大家觉得这种工作模式怎么样？
问题解答
回答1：两种方式:
大家使用同一个仓库进行合作开发,分支开发功能,开发完毕,建立merge request,进行code review,最终合并到develop分支
也可以大家 fork mainrepo, 开发完毕后,建立pull request到mainrepo由管理代码的人进行合并
使用第二种方式的好处:
保护 mainrepo, 所有的合并操作必须使用pull request, 不能简单的进行merge
mainrepo的分支更加的简洁,不会包含多余的分支
个人维护自己私有仓库内的分支,不会出现创建分支时重名的情况
个人强调贡献代码,向mainrepo贡献更多的代码
回答2：嗯，这样确实没发挥出分支的优势。不应该只有一个mainrepo分支。 应该按需求分出develop，feature,hotfix分支等。这样在相应的分支上开发。
回答3：这样做当然是可以的，你们老大这么做大约也有他的原因。不过这种方式管理就很集中，不太符合 git 分布式的思路，所以使用 git 并不太匹配。
回答4：我理解的步骤
老大创建库
master 指定 老大才能merge
创建 dev库，作为测试环境库，也只有老大或者指定管理才能merge。
各个开发创建自己的分支，然后push到远程厂库，然后老大或者管理，到dev merge，push上来的分支。
