Github has added branch access settings (protected branches)

Github is a great aggregator of repositories and a tool for teamwork. Unfortunately, many server-side configuration options (such as commit hooks) remain inaccessible. But the situation is gradually changing for the better.



What many have been waiting for for quite some time has happened. Namely: a feature was recently announced , called protected branches , which allows you to configure the rules for working with branches within the repository. Yes, now you can disable force push in master!



Under the cut screenshots and excerpts from the blog developers.



The protected branches feature allows repository administrators to forbid force push operations to specified branches.

')

If the option is active for your repositories, we can configure it on the tab in the repository settings:







In addition to the ability to block force push, you can set a list of mandatory checks (status checks). This functionality works thanks to the Status API , so you can check for any integrable action, such as running the collector, running tests, running a static analyzer, etc.



If at least one of the mandatory checks fails, the “Merge” button will not be active:







For statuses to be believed, the branch must be up to date. This ensures that nothing will break after the merger. A new button “Update branch” allows with one click to inject the last state of the base branch (for example, master) into the current one, and then perform checks:







More information on the topic is available on the help page .



From my side I would add that the ban on force push, from my point of view, is the most sensible thing that has appeared on the githaba lately. Now you can not worry that the junior will ruin the master branch with a sloppy push. Of course, this problem was solved in other ways. It was possible to prohibit force push in corporate repositories, but only for the main branch, or the entire repository as a whole.



Before the advent of protected branches, individual developers were recommended to put hooks on the push operation in order to prevent blasphemy locally. It is clear that it still did not give 100% guarantee.



In other teams, a model is adopted in which each employee must fork out the repository and issue a pool of requests from it. Accordingly, direct access to the repository is given only to favorites. However, this is not always convenient.



Let's hope that the githab will delight us in the future.



PS: The option was announced on September 3. At the moment, it works in my public repository (by the way, we have released a regular release ).