GIT 支持基于分支的用户授权 - 最佳实践还是工具？
对于基于产品的GIT存储库，其中有用于维护、测试以及未来开发的分支，我如何控制用户对这些分支的访问。通过访问，我的意思是即使其他人可以从中读取内容，他们也不应该能够无意中将更改推送到存储库。
例如，
A - B - C - D - E - F -> master
| | |
V1 V2' exp
|
V2
“B”是用于带有标签 V1 的分支的提交 - 意味着产品的发布版本。只有支持/维护工程师才能访问此内容。
C 用于最近冻结的预发布产品 V2'，并且应该只允许关键的 bug 修复，因此只有某些开发人员和测试团队应该有权访问它。当 V2 从该分支发布时，只有支持人员才能访问它，就像 V1 的情况一样。
E 用于测试未来 V3 的新功能的分支 - 只有开发人员而不是支持人员可以访问它。
“主”更改只能由中央集成团队根据请求（类似于 GitHub）进行合并。
如何用git实现上述功能呢？我记得看到过 gitosis 和其他一些外部工具 - 这些对于 git 的安全操作至关重要吗？或者还有其他最佳实践吗？
谢谢。
For a product based GIT repository, wherein there are branches for maintenance, testing as well as future development, how do I control user access to these branches. By access, I mean that even though others may read from it, they should not be able to inadvertently push changes to the repo.
For example,
A - B - C - D - E - F -> master
| | |
V1 V2' exp
|
V2
"B" is the commit used for Branch with tag V1 - meant for released version of the product. Only support/maintenance engineers should have access to this.
C is used for a recently frozen pre-release product V2' and should only allow critical show-stopper bug fixes, so only certain developers and the Testing team should have access to it. when V2 is released from this branch, only Support should access it as is the case with V1.
E is used for branching off for testing a new feature for future V3 - only developers and not Support should access it.
"master" changes should only be merged on a request basis (similar to say, GitHub) by a central integration team.
How can the above be achieved with git? I recall seeing gitosis and some other external tools - are these essential for secure operation with git or are there any other best practices?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
限制对存储库（或分支甚至目录）的推送访问的另一种经典方法是使用
gitolite（实际上是gitosis的大演变）。您可以在其中（在
gitolite配置文件中）定义所需的任何用户组或存储库组，并关联RW访问权限。注意：2013 年 8 月：
Assembla 提供也有这样的保护（自 2013 年 3 月起）。
GitHub
还没有此功能：GitHub 自 2015 年 9 月起就有该功能：请参阅“如何保护 github 中的“master”？”。
The other classic way to restrict push access to a repo (or a branch or even a directory) is by using
gitolite(which actually is a big evolution ofgitosis).You can define there (in the
gitoliteconfig file) any group of users or group of repos you need and associateRWaccess rights.Note: August 2013:
Assembla provides such a protection as well (since March 2013).
GitHub
doesn't have yet this feature:GitHub has that feature since Sept. 2015: see "How to protect “master” in github?".
放置一个服务器端提交钩子，拒绝提交到您需要只读或基于提交者是谁的任何分支。
对于合并请求工作流程，我们使用本地安装的 Gitorious 并通过其 Web 界面提交合并请求并限制
main-line存储库给您的集成团队，其他人都可以从服务器端克隆工作，然后将合并请求推送回主线存储库。使用 Gitorious，您不需要服务器端挂钩，只需将对
main-line存储库的访问权限限制为只有您希望成为提交者的人员即可。更简单且更易于维护。Put a server side commit hook that denies commits to whatever branches you need read-only or based on who the committer is.
For merging request work flow, we use a local install of Gitorious and submit merge requests through its web interface and restrict the
main-linerepository to your integration team, everyone else would work from server side clones and then push merge requests back to the main-line repository.With Gitorious you don't need the server side hooks, you just need to restrict access to the
main-linerepository to only the people you want to be committer. Much simpler and easier to maintain.