Миграция из SVN в GIT из-за механизма утверждения

Question

В настоящее время мы работаем над проектом с открытым исходным кодом с командой из примерно 50 человек, в среднем с 20-30 сутками. Поскольку некоторые из этих людей являются младшими разработчиками, нам нужно было внедрить систему, которая не позволяла всем им совершать транзакции в нашем основном репозитории.

До сих пор мы использовали SVN с этой структурой:

• ствола - Содержатся весь код разработчиков
• филиала - Содержатся всего подтвержденного код

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

Недавно мы начали делать тесты с Git и GitLab, чтобы проверить, стоит ли система утверждения Git перейти от SVN, чтобы смягчить все это слияние безумия.

Сначала это выглядело многообещающим, но через некоторое время мы пришли к неутешительному выводу, что не было магической формулы. Мы создали защищенную мастер-ветку, в которой только старшие разработчики имели бы доступ к push-изменениям, но затем появилась проблематичная часть ... младших разработчиков.

Может быть, потому что мы так привыкли к тому, как SVN, единственное решение, которое мы нашли в том, чтобы создать «младший филиал», но это будет в основном имитировать поведение (и головные боли), у нас уже есть с SVN.

Скажите, пожалуйста, что-то, чего нам не хватает, или если мы справляемся с проблемой не так.

EDIT Когда я говорю одобрил код, я имею в виду проверки для всех классов структуры, нужные объекты конкретизации ... и нет, если разрывы строк, вкладки (и т.п.) являются правильными.

Answer 1

Этот вид политики был прост в настройке, когда GitLab использовал Gitolite, because of VREF.

Вы можете связать крючок обновления с правилом gitolite, который может быть определен для группы пользователей (команда в GitLab) под названием «юниоры» и применять любую политику, которую вы хотите.

Но так как GitLab 5.x, gitolite больше не используется, а gitlab-shell управляет разрешениями.
Надеюсь, Issue 14 будет рассмотрен.
В то же время вам нужно будет внедрить и развернуть крючок обновления самостоятельно, чтобы применить политику для младших разработчиков, нажав на конкретную ветку.

Как прокомментировал, другой подход заключается в следующем:

• не сказал, добавить младших разработчиков проекта
• вилы (клон на сервере) проекта: эта функция разрабатывается сейчас для GitLab V5 (issue 3382)
• Сделайте запрос на вытягивание (называемый «запрос на слияние»).

Учитывая нынешнее состояние развития для GitLab, что программное обеспечение для управления Git в одиночку пока не готов предоставить все, что вам нужно.

Сочетание этих репозиториев (основного и одного для младших разработчиков) с системой обзора, например Gerrit, может быть более разумным подходом (here is an interesting criticism of that combination).