防止用户对开发/主控进行提交 [英] Prevent users to commit on develop/master

问题描述

我们有一个bitbucket服务器，我们已经介绍了使用Pull Requests来保护两个分支：Master和Develop。

这个效果很好，人们再也不能推动这些分支在我们的bitbucket服务器上。

但问题是，有时当我们用开发版来测试某些行为时，我们忘记修改分支来做修改，我们在本地做了一些我们无法推送到服务器的提交。

我的问题是：是否有办法阻止用户使用共享规则提交这两个分支或什么的？

一些重要的要求：

1. 它应该被共享团队


2. 它应该在我们的Windows环境中工作


3. 这不应该阻止我们的pull请求合并到develop / master

非常感谢您

不是如何限制对git上的master分支的访问，因为这个其他问题是服务器拒绝已提交的提交。它并不妨碍开发人员通过开发而不是他们的分支来承担错误，并且使他们没有时间将其更改移动到另一个分支。如果提交不可行，它会帮助我们迅速看到这个错误。

解决方案

您可以做一件事，但它需要用户的积极参与。它们必须安装预先提交的钩子。

预提交钩子可以非常简单：

 ＃！ / bin / sh 
＃pre-commit：如果当前分支是master或者开发
的情况下失败$（git rev-parse --abbrev-ref HEAD）in 
 master | develop）回声首先创建一个新的分支1& 2; 1号出口;; 
 esac 
 exit 0 
  

您将包含此文件（请务必<

  $ git clone< url> 
 $ cd< new-clone> 
 $ cp<路径到文件> .git / hooks / pre-commit 
  

克隆时。但是，如果他们忘记执行 cp 步骤，他们将不会有钩子。 （你可以为它们提供一个脚本来完成克隆和安装钩子，或者一个更通用的脚本来安装它们应该在克隆后运行的钩子，甚至可以用钩子来设置一个模板目录，或者让它们做这是他们自己的系统 - 然后使用 git clone --template =< template-dir> 。）

< hr>

观点提示：整个想法最终是徒劳的，因为那些知道自己在做什么的人可以很容易地解决你在这里做的任何事情（例如， git commit --no-验证）;对于那些知道自己在做什么的人来说，毫无意义，因为无论如何，分支名称本质上毫无意义。 ¹ 对于那些完全不知情的人，你不能自动提供 >。因此，您所能做的只是向愿意采取行动的用户提供提示，但不理解他们正在采取的行动。

---

¹ 考虑到在我的分支名为 master 的分支上进行了多次提交之后，我可以运行：

  git branch -m主要特性/ xyz 
  

<将我的 master 重命名为我的特性/ xyz ，然后：

  git checkout master 
  

创建一个新的 master ，其上游是 origin / master ;新的 master 指向与 origin / master 相同的提交。然后：

  git结帐功能/ xyz 
  

让我回到我的特性/ xyz 上。我的特性/ xyz 现在可能将其上游设置为 origin / master ，但也许这正是我想要的。

$ b 我的存储库中的分支名称​​ 只是 ephemera 在这里：我会随意创建，重命名和/或摧毁它们。什么是提交。对于服务器端分支，情况并非如此：分支名称​​ there 在克隆该存储库时会复制到其他用户的远程跟踪名称中，而其他用户可能对分支名称和分支名称远程追踪名称的工作，所以这些名称​​做很重要。但是一旦你知道Git中的名字是如何工作的，它们只是为了方便，并且很容易改变。

We have a bitbucket server, we have introduced the usage of Pull Requests to protect two branches: Master and Develop.

This works well and people cannot push anymore to those branch on our bitbucket server.

But the issue is that sometimes when we took the develop version to test some behavior, we forget to change the branch for doing our modification, and we do some commit locally that we cannot push to the server.

My question is: Is there a way to prevent users from committing on those two branche with a shared rules or something?

Some important requirement:

1. It should be shared accross the team
2. It should work in our windows environment
3. This should not prevent our pull request to be merged into the develop/master

Thank you very much

Not a duplicate of How to restrict access to master branch on git since this other question is for the server to reject the commit, which is already in place. It doesn't prevent the dev to commit by error on develop instead of their branch and make them loose time to move their changes to another branch. If the commit was not possible, it would help us see this error quickly.

解决方案

There is one thing you can do, but it requires active participation from your users. They must install a pre-commit hook.

The pre-commit hook can be very simple:

#! /bin/sh
# pre-commit: fail if current branch is master or develop
case "$(git rev-parse --abbrev-ref HEAD)" in
master|develop) echo "make a new branch first" 1>&2; exit 1;;
esac
exit 0

You would include this file (be sure to chmod +x it or otherwise make it executable) in your repository, and they would use the "magic incantation" of:

$ git clone <url>
$ cd <new-clone>
$ cp <path-to-file> .git/hooks/pre-commit

when cloning. However, if they forget to do the cp step, they will not have a hook. (You can give them a script that does the clone-and-install-hooks, or a more general script that installs hooks for them that they should run after cloning. You can even set up a template directory with hooks—or have them do this themselves, on their systems—and then use git clone --template=<template-dir>.)

---

Opinion alert: The whole idea is ultimately futile, because those who know what they are doing can easily get around anything you do here (e.g., git commit --no-verify); and for those who know what they are doing, there's no point, as branch names are essentially meaningless anyway.¹ For those who are totally clueless, you can't provide this automatically. So all you can do is provide hints to users who are willing to take action, but don't understand the action they are taking.

---

¹Consider that after making several commits on my branch named master, I can run:

git branch -m master feature/xyz

to rename my master to my feature/xyz, then:

git checkout master

to create a new master whose upstream is origin/master; the new master points to the same commit as origin/master. Then:

git checkout feature/xyz

puts me back on my feature/xyz. My feature/xyz now probably has its upstream set to origin/master, but maybe that is what I want anyway.

The branch names in my repository are all just ephemera here: I create, rename, and/or destroy them at will and whim. What matter are the commits. That's not the case for your server-side branch: the branch names there get copied into other users' remote-tracking names when they clone that repository, and those other users are probably naïve about how branch names and remote-tracking names work, so those names do matter. But once you know how names work in Git, they're just for convenience, and easily changed.

这篇关于防止用户对开发/主控进行提交的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！