Git 拒绝用户创建标签
这是一个关于 git repo 管理的问题...
是否可以将 git repo 配置为仅允许某些用户创建 TAG？ 对于分支也有类似的问题：是否可以配置能够修改特定分支的用户列表？
所有这些配置的想法是：有许多开发人员的 git 存储库，我们希望有一些稳定的分支和标签列表。只有高级开发人员才能修改这些分支并创建标签。 所有其他开发人员仍然可以创建分支等。但是如果开发人员想要将他的更改推广到稳定分支之一，他必须联系高级人员要求他进行合并...
谢谢
Here is a question about git repo management...
Is it possible to configure git repo to allow TAG creation only for some users?
And similar question for branch: is it possible to configure list of user, who are able to modify particular branch?
The idea for all this config is: there is git repo with MANY developers, and we want to have a few stable branches and list of tags. And only senior developers will be able to modify those branches and create tags.
All other developers still can create branches and so on. But if developer wants to promote his changes to one of stable branches, he must to contact senior person to ask him to make merge...
thank you
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
Gerrit（主要是代码审查系统）几乎完全按照您的描述解决了这个问题。
您定义组，然后设置存储库权限，确定谁可以在分支中推送审核、谁可以将更改直接推送到分支、谁可以推送标签（各种类型），甚至谁可以查看/推送到您的绝密分支。
我们的 gerrit 实例向全世界开放，尽管我们确实限制了谁可以推送什么以及在哪里（并且有一些某些项目的合作者可以比其他项目做得更多）。
Gerrit (mainly a code review system) solves this problem almost exactly as you're describing it.
You define groups, and then set repository permissions on who can push for review in a branch, who can push changes directly to a branch, who can push tags (of various types) and even who can see/push to your top-secret branch.
Our gerrit instance is open to the world, although we do limit who can push what and where (and have some collaborators on some projects who can do more than others).
您可以使用 .git/refs/heads 和 .git/refs/tags 上的标准文件访问规则来限制访问。例如，如果您将 .git/refs/tags 模式设置为 775，则只有拥有 .git/refs/tags 的组的成员才能创建标签。同样，您可以限制对 .git/refs/heads/foo 的读取权限，以便只有具有读取权限的人才能签出分支 foo，并且只有具有 .git/refs/heads 写入权限的人才能创建新分支分支机构。然而，这是一种不可靠的技术，最好使用具有适当访问权限的不同存储库。
You can limit access using standard file access rules on .git/refs/heads and .git/refs/tags. For example, if you make .git/refs/tags mode 775, then only members of the group that owns .git/refs/tags will be able to make tags. Similarly, you can restrict read permission to .git/refs/heads/foo so that only those with read access will be able to checkout branch foo, and only those with write access to .git/refs/heads will be able to create new branches. This is an unreliable technique, however, and you'd be much better off using distinct repositories with appropriate accesses.
对于分支和带注释的标签（即可以推送/拉取的版本化标签），gitolite< /strong> 可以提供这种访问控制。
请参阅“匹配 ref 和 refex”（gitolite 3.x）
这种该工具允许保护“中央”存储库：如果您有正确的凭据，您可以克隆它们并使用本地副本执行您想要的操作，但是一旦您想要推迟，gitolite 将控制与该存储库相关的权限远程仓库。
因此默认情况下，您无法推送标签，除非有明确的
refs/tag/规则允许您的用户或用户组使用它。For branches and annotated tags (i.e. versioned tags that can be pushed/pulled), gitolite can provide that kind of access control.
See "matching a ref and a refex" (gitolite 3.x)
This kind of tool allows for the protection of "central" repositories: if you have the right credentials, you can clone them and do what you want with your local copy, but as soon as you want to push back, gitolite will control the permissions associated with that remote repo.
So by default, you cannot push tags, unless there is an explicit
refs/tag/rule allowing it for your user or group of user.通过阅读文档和个人经验，我了解到 Git 并不是为了以这种方式使用而设计的。您所描述的内容可以通过多存储库场景轻松处理，其中较少的开发人员推送到开发存储库，而高级开发人员从中提取更改、合并、测试等...然后部署到生产存储库，其中任何开发者可以拉。
It is my understanding through reading the documentation and personal experience that Git is not designed to be used in that way. What you're describing can easily be handled by a multiple repository scenario in which lesser developers push to a development repository and the senior developers pull changes from that, merge, test, etc... and then deploy to a production repo from which any developer can pull.