Как защитить мастер в github?

У меня есть несколько участников в моем проекте github. Я хочу, чтобы только один из них «нажал» на мастер. И этот парень не я (владелец репозитория). Возможно ли это сделать?


person yegor256    schedule 30.04.2012    source источник
comment
Это частный проект? Если это не так, им не обязательно быть соавторами — они могут разветвляться и использовать исключительно запросы на вытягивание (что обеспечивает уровень проверки псевдокода для слияния изменений)   -  person Daenyth    schedule 22.05.2012
comment
Эта функциональность не поддерживается github, но если вы ищете аналогичные решения: Репозитории Assembla поддерживают это: blog.assembla.com/assemblablog/tabid/12618/bid/96330/ Сделай сам — самостоятельный хостинг git: git-scm.com/book/ch7-4.html Сделай сам — самостоятельный хостинг Mercurial : mercurial.selenic.com/wiki/AclExtension   -  person Titas    schedule 21.03.2013
comment
См. также stackoverflow.com/a/5097437/6309.   -  person VonC    schedule 20.09.2013
comment
возможный дубликат способ ограничить доступ к ветке Git?   -  person Ciro Santilli 新疆再教育营六四事件ۍ    schedule 03.06.2014
comment
Сентябрь 2015 г.: похоже, что эта функция появится в GitHub: см. мой ответ ниже   -  person VonC    schedule 03.09.2015
comment
Кажется, сейчас это (более или менее) возможно; github.com/blog/2137-protected-branches-improvements. Push-доступ для конкретной ветки теперь может быть ограничен определенными пользователями. Однако администраторы смогут отправлять сообщения независимо от этого параметра.   -  person Sander    schedule 30.04.2016


Ответы (4)


Тогда, когда этот вопрос был опубликован, GitHub не позволял вам указывать права доступа на уровне ветки. Вы можете сделать это только на уровне репозитория. Так что то, что вы просите, было невозможно.

Если вы хотите обойти это ограничение, я лично вижу два варианта:

  • вы могли бы использовать какие-то перехватчики фиксации и т. д., чтобы хотя бы сообщить кому-то, что что-то не так
  • Если вам действительно нужен этот жесткий контроль, вы можете использовать два репозитория, один из которых содержит только вашу «главную» ветку. Затем вам нужно будет убедиться, что только ваш «парень» получает доступ на запись к главному репозиторию.

Я думаю, что легче решить это с какой-то организацией. В моей команде мы никогда ничего не отправляем напрямую в мастер, а вместо этого всегда создаем пулл-реквесты. Это гарантирует, что по крайней мере кто-то посмотрит, прежде чем код будет объединен, и вы также можете определить политику, согласно которой только ваш «парень» может объединять запросы на вытягивание.

Обновить

GitHub объявил о выпуске новой функция, называемая защищенными ветвями. Эта функция уже много лет присутствует в других дистрибутивах git, таких как Atlassian Stash. Это позволит вам защитить некоторые ветки от толчков. Однако он по-прежнему не обеспечивает полной защиты отдельных ветвей на основе ACL. Таким образом, вы можете проверить эту функцию, если вы не хотите полагаться на организационное решение, как описано выше.

person Sebi    schedule 22.05.2012
comment
мы никогда ничего не пишем напрямую в мастер - потому что вы не можете или потому что вы согласились не делать этого? - person yegor256; 22.05.2012
comment
Потому что мы договорились этого не делать. Иногда проще найти мягкое решение, чем техническое. - person Sebi; 22.05.2012
comment
Кстати, я думаю, что это общая проблема в рабочем процессе git/github! Большинство людей, которые вносят свой вклад, сначала пытаются зафиксировать мастер, во всех проектах, которые я видел... - person Sliq; 02.07.2013
comment
Если вы столкнетесь с этими проблемами, вы также можете взглянуть на другие услуги/инструменты хостинга, такие как Atlassian Stash. Они предоставляют разрешения на основе ветвей. - person Sebi; 11.11.2013
comment
Assembla имеет хороший набор функций для создания различных рабочих процессов git и процессов проверки кода. В Assembla вы можете защитить любую ветку и дать права на запись определенным пользователям. Одна приятная функция — Enforce code review; когда кто-то нажимает на мастер, он остается нетронутым, и вместо этого создается новая ветка с изменениями кода, а затем автоматически создается запрос на слияние из новой ветки в мастер, чтобы другой член команды мог просмотреть/одобрить изменения. - person Mauricio Sánchez; 12.06.2014
comment
Мы защищаем от случайных переходов к мастеру с помощью хуков + защита на стороне CI: dimaip.github.io/2015/06/03/protecting-github-branch - person Dmitri Pisarev; 03.06.2015

Примечание: защищенные ветки и обязательные проверки статуса (сентябрь 3, 2015) позволит защитить ветку

  • против принудительного толкания
  • против удаления
  • против объединенных изменений, пока не пройдут необходимые проверки статуса

https://cloud.githubusercontent.com/assets/25792/9596474/27db3ce6-502a-11e5-9b19-5b47a8addc65.png


С марта 2016 года, как прокомментировал < href="https://stackoverflow.com/users/1233062/sander">Sander ниже, у вас есть Ограничения пользователей и групп

Иногда слияние с защищенной веткой лучше поручить менеджеру релиза или группе людей, ответственных за стабильность этой конкретной ветки. Теперь организации могут указать, какие участники и команды могут отправлять сообщения в защищенную ветку.

https://cloud.githubusercontent.com/assets/4719/14140705/ed98abac-f67a-11e5-951e-b48c842fb77f.png

person VonC    schedule 03.09.2015
comment
жаль, вы все еще не можете ограничить доступ к ветке для определенных членов .... Хотелось бы эту функцию для главной ветки. - person Pratik Bothra; 05.09.2015
comment
Я согласен, или, по крайней мере, иметь возможность ограничить слияние администраторов только для защищенных веток. - person deankarn; 08.09.2015
comment
@PratikBothra github.com/blog/2137-protected-branches-improvements кажется вроде сейчас можно. :) - person Sander; 30.04.2016
comment
@Сандер, я согласен. Я отредактировал ответ соответственно. - person VonC; 30.04.2016

Это именно то, для чего разветвление было разработано. У вас будет защищен основной репозиторий, и вы предоставите права на чтение этого репозитория всем участникам. Эти участники разветвят репо и внесут свои изменения в свои личные копии основного репо. Когда они будут готовы ввести код в основной репозиторий, они отправят запрос на включение в основной репозиторий. В этом случае владельцы основного проекта могли выполнить запрос на извлечение.

person kbuilds    schedule 09.02.2015
comment
Проблема с рабочим процессом разветвления / PR заключается в том, что участник, у которого есть права на запись в основном репо, все еще может нажать на него. - person G. Stoynev; 11.06.2015

Теперь мы можем использовать файл «CODEOWNERS», чтобы требовать проверки от владельцев кода, чтобы подтвердить запрос на вытягивание. Мы можем установить различные разрешения в зависимости от их учетной записи GitHub.

см. здесь и здесь

person Malick    schedule 26.02.2018