我们目前正在开发一个非开源项目，团队约有50人，平均每天提交20-30次。 由于其中一些人是初级开发人员，我们必须实现一个不允许所有人都提交到我们的主存储库的系统。
到目前为止，我们正在使用具有此结构的SVN：
其中一位高级开发人员“进入”主干并将其与分支机构合并，拒绝所有未经批准的代码（当有很多代码时，这会变得很疯狂未经批准的代码还原）。最后，当主干只有批准的代码时，两者之间就会完全合并。
最近我们开始用Git和GitLab进行一些测试，看看Git批准系统是否值得从SVN迁移，以软化所有这些合并的疯狂。
起初看起来很有希望，但过了一段时间我们得出一个令人失望的结论，即没有魔法公式。我们创建了一个受保护的主分支，只有高级开发人员可以访问推送更改，但随后出现了问题部分......初级开发人员。
也许是因为我们已经习惯了SVN方式，我们找到的唯一解决方案就是创建“初级分支”，但这基本上模仿了我们已经拥有的行为（和头痛）与SVN。
请告诉我，我们缺少某些东西，或者我们是否以错误的方式处理问题。
修改 当我说批准的代码时，我指的是所有类结构的验证，正确的对象实例化......而不是换行，标签（和类似的）是正确的。
答案 0 :(得分：0)
当GitLab使用Gitolite because of VREF时，这种政策很容易设置。
您可以将更新挂钩与gitolite规则相关联，该规则可以为名为“juniors”的一组用户（GitLab中的团队）定义，并强制执行您想要的任何策略。
但是，自GitLab 5.x起，不再使用gitolite，而gitlab-shell则管理权限。
希望Issue 14能得到解决
与此同时，您需要自己实现和部署更新挂钩，以便为初级开发人员推送到特定分支机构实施策略。
如评论所述，另一种方法是：
考虑到GitLab的当前发展状况，仅Git管理软件 尚未准备好提供您所需的一切。
将这些回购（主要版本和初级开发人员版本）与Gerrit等评审系统相结合可能是一种更明智的做法（here is an interesting criticism of that combination）。