rubezh-TWnlenfritplesuk

GitLab: Protected branches

В последних версиях GitLab появились средства защиты порядка в проекте. Давайте разберемся как они могут помочь в нашем деле.

Для домашних проектов использую систему управления версиями Git с сервером в виде GitLabЯ долгое время не обновлял GitLab, а после обновления на 8.12.4 столкнулся с проблемой отправки изменений в ветку Master. Причем в ветку Develop все прекрасно уходило - я уж думал откатываться на предыдущую версию. Клиент тем временем выдавал следующую ошибку:

remote: GitLab: You are not allowed to push code to this project. To https://gitlab.wcg.net/bla-bla-bla.git !
[remote rejected] master -> master (pre-receive hook declined) error: failed to push some refs to 'https://gitlab.wcg.net/bla-bla-bla.git'

Но я не стал пороть горячку и полез в документацию по GitLab, где  обнаружил, что все это из-за нововведенной защиты на изменения защищенных веток, а Master по-умолчанию является защищенной. Для чего это нужно? В личных проектах, где ведет проект программист-одиночка это лишнее. А вот в большом коллективе часто возникает ситуация, когда кто-то отправил в Master-ветку непроверенный код и весь проект перестал работать. Такое часто случается, когда на проект берут новичков и они в надежде отличиться - активно пушат изменения. Начинаются разборки полетов - выяснения кто это сделал и как это решить... Тратится время и порой даже не одного разработчика. Теперь же операции слияния и отправки в критичные ветки можно назначить определенным ролям в проекте и они будут отвечать за порядок.

Посмотрим как этот механизм управляется.

Назначение повелителя проекта

По умолчанию в ветку Master может пушить и сливать только пользователь с ролью Master. Предполагается, что он сначала проверяет код в ветке предназначенной для слияния и если все ОК, то делает Merge в Master. Если же над проектом ведется работа в одиночку, либо Вы хотите назначить Мастером кого-то, то нужно проделать следующие настройки:

1. Откроем настройки проекта и выберем меню Members:

gitlab members

2. В форме редактирования пользователей выбираем пользователя (People), указываем необходимую роль (Project Access) и, если необходимо - дату окончания действия доступа (Access expiration date):

gitlab members add

3. Нажимаем Add users to project.

Таким образом можно определить кто в проектной команде будет следить за чистотой кода в проекте и добавлять в ветку Master изменения, которые не нарушат работу проекта.

Чиним беспорядки

Порою хаос - это единственный возможный способ что-либо сделать. Можно решить проблему с записью в защищенные ветки дав доступ к ним всем девелоперам.

1. Откроем настройки проекта и выберем меню Protected Branches:

gitlab prot branches

2. В форме редактирования защищенных веток добавляем разрешение на доступ к ветке Master ролям Developers + Master:

gitlab prot branches allow

3. Нажимаем Unprotect.

Теперь все разработчики смогут творить хаос в мастер-ветке!

На самом деле это очень стоящее нововведение.

1 1 1 1 1 1 1 1 1 1 Рейтинг 100%

Метки: GitLab, Git

Печать E-mail

Добавить комментарий


Защитный код
Обновить