我希望强制其他团队成员不要在主分支上工作，而是在开发分支上工作。我们有一个中央git仓库，我们将自己的工作推送到该仓库。 我想知道是否可能阻止用户向主分支推送更改，但只允许某些用户这样做。
我想要以下的“工作流程”：
- 开发始终只使用开发分支
- 发布管理员负责主分支，只有他被允许从开发分支合并代码并将其推送到中央仓库的主分支。
这种操作是否可行？如何实现？
Git -- 锁定主分支对某些用户的访问权限？
15
- aurora
4
2个回答
6
请参考
man githooks：在共享仓库中，您可以创建一个$(git rev-parse --git-dir)/hooks/pre-receive或$(git rev-parse --git-dir)/hooks/update脚本来验证用户试图推送到哪个引用。Git附带了一个update-paranoid示例钩子，强制执行每个引用的ACL。- ephemient
5
谢谢... githooks 看起来非常强大。我会查看 gitosis 和 githooks 两个工具。 - aurora
有人可以详细解释一下吗？我看了
[update-paranoid](http://git.kernel.org/cgit/git/git.git/tree/contrib/hooks/update-paranoid?id=HEAD)钩子，但我不确定多个用户的ACL应该是什么样子。一个用户是否可以有多个格式为：committer = John Doe <john.doe@example.com>的允许提交者条目，并且这可以用于N个用户，例如：committer = John Doe
committer = User2
committer = User3 - blong@b.long:
update-paranoid 希望 /vcs/acls.git 存储库中有一个 users/${USER}.acl 来匹配每个 SSH 登录用户（而不是 此 存储库）；在每个文件中，可以有任意数量的 committer = 行。但您可能需要修改或重写脚本以适应自己的使用情况。 - ephemient@ephemient，我明白了。所以，在这种情况下，${USER}指的是
git用户（拥有该仓库的用户），对吗？你是说这个钩子不一定适用于通用目的？我正在寻找一个通用的解决方案，它可以简单地允许我列举能够在主分支上提交的用户（例如git flow），而其他分支将保留默认配置。 - blong假设有这样的设置，我推送到
me@remote:/srv/git/repo.git，你推送到 you@remote:/srv/git/repo.git（即使该仓库属于其他人，只要具有正确的权限和umask，这是可能的）。然后，当我推送时，此钩子将检查 me.acl，当你推送时，它将检查 you.acl。如果每个人都以 common@remote 推送，则每个人都可以在其提交中冒充任何其他人。该脚本可能无法直接使用（例如，它具有硬编码路径），但您可以将其用作起点。 - ephemient1
我的低级方法就是让RM成为唯一拥有SSH密钥的人，可以推送到其他人用作主基线的存储库。这样，除了RM以外，没有人能够推送到主分支 - 但每个人都可以工作，因为他们有自己的本地开发分支，开发人员可以相互分享他们喜欢的分支。
下一步是为即将进入主分支的内容制作一个烹饪锅测试器。这个锅通常被称为next或dev。这个想法是，分支对系统的影响越大，在合并到主分支之前需要经过更长时间的烹饪。这使得RM完全控制哪些分支应该毕业，同时给所有人提供了一个预警。
- I GIVE CRAP ANSWERS
1
谢谢。我也考虑过SSH，而且它很容易设置。但是我认为应该有更好的方法……？ - aurora
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接
git是分布式的，所以你不需要控制权限，因为没有“共享”仓库存在。换句话说，项目中的任何团队成员都会在自己的仓库副本上工作，而维护者会将分支合并到一个“主”仓库中（只是一个名称，不要与主分支混淆）。 - Armen Michaeli