Gogs: Protected branch

[truongsinh]

Reference https://about.gitlab.com/2014/09/29/gitlab-flow/
Reference https://code.google.com/p/gerrit/

Gogs should have a feature of protected branch. Let say master is a protected branch, then:

• Nobody can push directly to master
• Everybody* can checkout/fork from master
• Everybody* submit a merge request / code review request for his/her new branch (features/fixes)
• Everybody* can comment/discuss the diff, preferable line-by-line
• Only those with "Reviewer" or "Supervisor" or "Senior" privilege can vote up/down on a merge request / code review
• A merge request can only be eligible to be merged to master when having at least [a number] 2 of up votes. This parameter should be defined in a config file, environment variable, or runtime argument, so that nobody, even master or supreme admin can bypass code review process by setting it to 1 and self-review their code.

*Everybody is any user with sufficient authorization to read a project master and write to their own name space.

[zilionis]

We use gerrit at work. Code review it must have for the quality of code :)

[unknwon]

This feature needs a complete solution, need some time to think, and of course, code it. :smile:

[dominikschulz]

First gogs would need some ACL mechanism, then its a matter of checking the ACLs everywhere.

See https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/permissions/permissions.md

[unknwon]

@gittex thanks your info!

[srgvg]

+1 here
Branch permissions are a typical corporate feature that will do a lot of good for gogs.

[truongsinh]

ping

[unknwon]

Hi @truongsinh , don't know what to say, hmm...

This feature is great and I personally want to have it, too. But it's still in the waiting list. :joy:

[ohko]

+1

[renewsorensen]

:+1:

[drsect0r]

+1

[roidelapluie]

:+1:

[wenerme]

+1

[roidelapluie]

I have seen the card https://trello.com/c/oJWlgzvE I hope that it will be possible to have that setting per branch.

[DarthNihilus1]

+100000000000000000000

[i00]

I don't like the idea of votes, just want branch permissions... but also want to take it a step further...

For eg (my case).
If I have a user called Jack I want to be able to give him permissions to publish new branches that start with Jack/ only (so I know exactly what user published a branch at a glance and don't end up with "junk" branches everywhere).
I want to be the only one who can push to the master (so I can choose what to merge in).

I want to be able to restrict publishes, pushes and pulls (preferably visibility entirely if I don't grant pull permissions).
All of this should hopefully be able to be done with wildcards to suit my purposes..
eg:
Permissions for jack:
Unspecified permissions (cannot be deleted) - Pull only
Jack/* - Full
Permissions for me:
Unspecified permissions (cannot be deleted) - Full
Permissions for Dean:
Unspecified permissions (cannot be deleted) - Full
master - Pull only

Thanks, for the great work :)
+:100:

[tebanep]

+1 :+1:

[sluedecke]

+1, an important feature we would use at work to manage staging of our product

[Twisterat57]

+1, with also the possiblity to make visible as read-only the wiki pages + issues (read + Write) for some teams:
Purpose of having access to wiki pages in read-only is to share internally setup files with non developer teams (ie: device preparators, Commercial team, and why not in the future, a customer). Then gogs would be the "all in one tool" all development team should have! (ok it should be already the case: all developer team should use this amazing tool already XD)

@dominikschulz Shared a link in January 2015: this permission list seems to be complete for the purpose for global server permissions, but they should be overridable on a project level... (ie: branches restrictions). Probably in some cases (like our) owner of the project will manage the merges to the Master Branch (all other contributors should only pull from an existing branche and then create a pull request)

@i00 and @truongsinh have a good aproach on Branche permissions on specific project permissions

[pbi-qfs]

Isn't it possible to implement simple protection (e.g. only allow some users to push to specific branches) via git-hooks on the server?

[unknwon]

@pbi-qfs post-receive hook?

[thibaultmeyer]

Is possible to partial implement this feature without real permission ? only by specify a list of branch to protect and a list of user allowed to push on ?

[unknwon]

@0xbaadf00d no it's not possible, what does "real permission" mean?

[thibaultmeyer]

Something like this: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/permissions/permissions.md

[unknwon]

@0xbaadf00d I think this feature will come with that directly.

[thibaultmeyer]

ok, nice

[mehrad-rafigh]

+1

[denji]

+1, git push --force will destroy this planet!

Git pre-push hook to prevent force pushing master branch

[joelhy]

+1

[bhchew]

+1, nice to see PR between branches are implemented.

Pending this to prevent manual merges between branches outside PR =)

[renewsorensen]

+1

[rudineirk]

+1

[mrkeuz]

+1

[FyinInc]

+1

[mminetto]

+1

[Jofkos]

+1

[hrobertson]

I'm guessing hitting :+1: on the OP is preferred instead of all these +1 comments?

[luckyliupp]

i need this feature

[relipa]

So do I

[erik-seifert]

+1

[Rhys]

I would also appreciate it.

[YamiOdymel]

Still +1

[lionxvibe]

Is someone working on it ?

[congeal]

+1

[ptman]

I think protected branches / branch permissions can be implemented by itself without having to provide much integration with the code review side initially.

[lionxvibe]

@ptman This is not the same need, of course if you are code reviewing your project you have to protect branches but you also need to make comments on the submitted code: both are different feature.

[hrobertson]

@ptman @lnalex As has been said, 'Protected Branches' and 'Line-by-line code comments on the PR' are separate features. Neither _requires_ the other.

If you read the first post of this feature request, it is asking for Protected Branches.
Line-by-line comments are only mentioned as a nice to have:

• Everybody* can comment/discuss the diff, preferable line-by-line

The existing Pull Requests feature enables commenting, but not line-by-line.

I agree that the ability to add line-by-line comments on a pull request would be a useful feature, but that should be raised as a separate feature request.

Additionally, some people have requested a more comprehensive permissions system. Again, that is a separate feature request: https://github.com/gogits/gogs/issues/1743

[freshcn]

+1

[strk]

It would be worth for the approval system to be driven by external/arbitrary plugins, using an approval API.
The lgtm project does this to drive approvals for github protected branches, for example:
https://github.com/lgtmco/lgtm

[strk]

Github system documentation: https://help.github.com/articles/about-protected-branches/

[bradrydzewski]

I recommend reviewing the GitHub protected branches functionality. They have iterated on it quite significantly over the past 8 months and it is really shaping up nicely. Here are some quick highlights:

• any branch can be protected
• protected branches cannot be pushed to directly
  
  
  
  • unless the user account is part of a white list (configurable)
  
  
  • or unless you are a repository administrator
  
  
• protected branches can include required status checks
  
  
  
  • cannot merge until status checks are passing (ie CI checks, Coverage checks, Approvals)
  
  
  • administrator can override and force merge
  
  
• protected branches must be up-to-date with the target branch
  
  
  
  • merge button is disabled if it falls behind
  
  
  • administrator can override
  
  

The important thing here is that status checks unlock the protected branch so you can proceed with merging. This allows for much more custom and complex workflows for approving pull requests than something like simple voting.

I would advise against putting any approval workflows (ie voting) in Gogs directly simply because, speaking from experience, it will only satisfy the needs of a subset of your users with others asking for more customization for more complex workflows. Using required status checks and delegating to 3rd party services is definitely the way to go IMO. It gives you the most flexibility, while still leaving the option to directly integrate approval workflows (ie voting) at a later time.

[unknwon]

👍 for @bradrydzewski 's comment, but not quite understand this one:

protected branches must be up-to-date with the target branch

[strk]

On Mon, Jul 18, 2016 at 03:05:32AM -0700, 无闻 wrote:

protected branches must be up-to-date with the target branch

I guess it means they are rebased to the target branch.
In other words, they can be merged with a fast-forward operation
(no need for a merge commit).

[unknwon]

@strk no merge conflict or...?

[bradrydzewski]

@Unknwon hopefully this helps clarify :)

Please also note that when protected branches prevent you from merging a pull request that has fallen behind the target branch. That is to say, if a pull request is merged, all outstanding pull requests will need to re-sync before they can be merged.

The message in the screenshot "This branch is out-of-date with the base branch" indicates I need to sync my code with the base branch. This happens when I submit PR 1 and then PR 2 is merged, meaning my PR is out of date.

This forces me to update my PR and re-push my code. This in turn re-triggers various status check such as continuous integration, which could yield different results once my code is updated.

[strk]

Independently of merge conflict, a fast-forward merge
is one from a branch which is based on the top of the
target branch.

Seek "fast-forward" here:
https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging

[hrobertson]

@bradrydzewski Would this 'up-to-date' requirement be an optional setting per protected branch?

Some people may want the option to merge PRs that are behind, so long as there are no merge conflicts.

Assuming this was an option: For branches with this switched on, a new PR would have to be created?
For branches with it switched off, pending PRs should have checks (including CI) re-triggered/re-evaluated.

[bradrydzewski]

Would this 'up-to-date' requirement be an optional setting per protected branch?

It is not an option with GitHub. If you are an administrator, however, you have the ability to override protected branches and merge as long as there are no conflicts.

Some people may want the option to merge PRs that are behind, so long as there are no merge conflicts.

I can't really argue one way or another since I don't have access to real world usage metrics or feedback. I can only reference the GitHub implementation which prevents merging out-of-date pull requests and does not make this optional.

[bradrydzewski]

ok, I take that back, github has added the option to toggle this feature. The feature is in beta and they are changing it on a weekly basis, but I am told it will be out of beta soon. So what you see in the screenshots and read in their official docs is probably pretty close to their final implementation

[gilou]

There could also be a "simple" permission setup for branches... Deciding for on organization who can write to what branches... Allowing pull requests to be created as branches, but no write on master for example. A gitolite way of handling things can be a good start... as in: perms on org/user for the repos, perms for branches.. or allowing branch named dev/xxx for devs & so on...

[unknwon]

Note:

1. For detect and disable force push: http://stackoverflow.com/questions/10319110/how-to-detect-a-forced-update
2. Then Gogs needs to use both update and pre-receive hooks, and in order to allow user has custom scripts for these two hooks, we need to implement https://github.com/gogits/gogs/issues/1623 first.

[grotesque]

see my comments here: https://github.com/gogits/gogs/issues/3594
+1

[CharlesLR]

Hi
I develop a little script for protect a specific branch.
In Gogs, you past the content in the Git Hooks pre-receive : https://github.com/CharlesLR/git-hook/blob/master/pre-receive.txt
I hope that will help you, before a new version of Gogs

[denji]

.git/hooks is not a secure solution, it is still possible to rewrite hooks.

[CharlesLR]

I know. It's a temporary troubleshooting solution :)

[grotesque]

@CharlesLR
Hi,
I am not able to view that url (page not found). Can you look into this?

[grotesque]

@denji
Hi,
I don't understand how is it possible to rewrite hooks? This hook will be part of the server's .git folder. How can anybody rewrite them?

[denji]

@grotesque Destroy branch unprotected.

[CharlesLR]

@grotesque
Link is OK now :)

[ElderJames]

需要这个功能！

[afdev82]

Isn't it possible to implement simple protection (e.g. only allow some users to push to specific branches) via git-hooks on the server?

In order to do this we need to know the user that is pushing, I didn't find any doc about this.
How could I access the current user inside the hook?

[hrobertson]

@afdev82 The username is probably available in an environment variable. Write a hook to log the env vars so you know what's available.
Rather than replying here, please create a new issue regarding the need for documentation on the hooks environment.

Please let's keep this issue tidy. :smiley:

[afdev82]

@hrobertson Yes, you are right, but I didn't find any better place to write to get this information (I didn't want to open an issue only for that).
Anyway, thanks for the reply, I will try your suggestion.

[CihanSari]

Would this also include ability to hide source on some branches? I have seen some other issues which would address this need closed and referred to this one. Example scenario:

Software and hardware developers have access to the source code, production engineers / test engineers can open issues / provide feedback for next milestones. We don't want to make the code open for everyone, but issues should be open to at least a big part of the company. Currently we are making the Gogs completely hidden from the production and add a layer (somebody) to receive feedback and create the issues, ask for feedback and comment etc.

[strk]

Software, like information, shall be free

[unknwon]

Initial version of protected branches is now on develop and online on demo site.

Since this thread is fairly long, please file new issues for suggestions and bug reports, thank you!

[fatbigbright]

Thanks for updates for protected branch feature in RC0.10. I wonder if there is a way to allow repository owner freely push code to the protected branch?

[unknwon]

@fatbigbright It doesn't treat owner differently right now and I also think this should not be the default behavior.

But can add always another option to allow owner freely do anything to the branch.

[fatbigbright]

@Unknwon Sorry I am not quite sure about what you said about "add always another option", could you give more hints?

[hrobertson]

He means he will consider adding that as an option. I agree with him that it should not be default behaviour.

[502647092]

+1

[PHolker]

In gogs, you can (soft)protect a branch in the web interface.
Still, any user may continue to push (NOT force-push, though)
or even perform pull-request merges via the web interface.

Remidy comes in the form of git hooks, as both the user name and branch can be accessed.

Beware of the Gogs bug: git-hooks edited via web interface of gogs will be stored in .git/custom_hooks BUT will not work, so you must modify the .got/hooks/pre-receive file instead.

Here is my script to (hard)protect a branch, assuming you do not enable pull requests for it!
What is does: limit pushes to a protected branch to a list of user names.

happy coding ...

https://github.com/PHolker/git-hook/blob/master/pre-receive