Ветка только для слияния на BitBucket / GitLab / GitHub?

Есть ли способ настроить ветку так, чтобы ее можно было только объединить, а не вставить? Кроме того, есть ли способ, который работает на BitBucket, GitLab или GitHub?

Мы работаем над функциональными ветками, отправляем их в BitBucket / GitLab / GitHub (в зависимости от проекта), а затем объединяем их в интеграционную ветку под названием «разработка». Я хочу, чтобы люди не могли напрямую продвигаться к «развитию».

BitBucket имеет средства ограничения доступа к веткам, но также не позволяет людям выполнять запросы на слияние.


person EngineerBetter_DJ    schedule 01.10.2013    source источник
comment
Технически слияние - это просто фиксация с несколькими родителями, которую вам все равно нужно будет куда-то протолкнуть, если вы хотите ее опубликовать.   -  person poke    schedule 14.10.2013


Ответы (2)


Да: это называется разветвлением (как в вилка GitHub и его советы, Вилка BitBucket и вилка GitLab).

  • У вас есть одно репо, за которое отвечает только интегратор (он / она присоединится к целевой ветке).
    Разработчики не могут продвигаться в это репо.

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

разветвление


Теоретически вы можете использовать только одно исходное репо, но для этого потребуется уровень авторизации, например gitolite, чтобы защитить ветки от push / слияния.
Это недоступно в Github (который не защищает ветки), BitBucket (который защищает ветки, но не от слияния) и GitLab (то же, что и BitBucket).

Поэтому проще работать с несколькими репозиториями апстрима: исходным и одним или несколькими форками.

А у GitHub / BitBucket / GitLab есть приятный интерфейс для пул-реквестов, связывание их с комментариями, облегчение общения и обсуждения вокруг конкретного пул-реквеста.

Форкинг + запрос на вытягивание - это не просто "способ git", это действительно самый удобный способ интегрировать множество вкладов, именно поэтому git был изобретен Линусом Торвальдсом в первую очередь: помогите ему интегрировать много патчей в день для его ядра Linux.


Подход «защищенной ветви», упомянутый Tippa Raj (и о котором я упомянул чуть выше) - это не подход, который я бы рекомендовал, поскольку он искусственно навязывает централизованный подход, при котором вам нужно все контролировать:

  • ветви для защиты
  • ветки, которые вы разрешаете публиковать: с одним репо у разработчиков возникнет соблазн протолкнуть все свои ветки.

GitHub не предоставляет защищенные ветки по этой причине.
(На самом деле, с сентября 2015 года он есть: см. "Как защитить" master "в github?")
BitBucket и GitLab предоставляют эту функцию.

Отдельные репозитории также могут управлять и защищать ветки (даже папки и файлы) с добавлением уровня авторизации например, гитолит.

Но когда дело доходит до облегчения совместной работы над функциональными ветками, ничто не сравнится с запросами на вытягивание.

person VonC    schedule 14.10.2013
comment
Спасибо, это очень подробный ответ. Я боюсь, что несколько апстрим-репозиториев - слишком далекая абстракция для рассматриваемых случаев - может быть, проще победить людей с помощью Naughty Stick, когда толкать туда, куда им не следует! - person EngineerBetter_DJ; 14.10.2013
comment
@Deejay нет, это не слишком уж абстракция, это действительно то, как должна работать распределенная VCS, такая как git. - person VonC; 14.10.2013
comment
@Deejay, и именно так GitHub, BitBicket и GitLab решают это довольно распространенное требование. - person VonC; 14.10.2013
comment
Спасибо - некоторые разработчики проекта очень плохо знакомы с Git, и запросы на слияние являются для них проблемой: отсюда и мое замечание, что в данном случае это слишком далекая абстракция, даже если это «правильный» способ сделать это. - person EngineerBetter_DJ; 14.10.2013
comment
@Deejay, я понимаю. Вот почему я объясняю, какая вилка (stackoverflow.com/a/6286877/6309) и запрос на вытягивание находятся в переполнении стека. . Проблема решена;) - person VonC; 14.10.2013
comment
Однако рабочий процесс разветвления имеет последствия: например, часто в магазинах есть нормализованные среды, в которых код автоматически проверяется разработчиками на виртуальной машине. Если этот проверенный env должен быть форком, его гораздо сложнее настроить, чем простой клон основного репо. - person Adam Parkin; 20.03.2015

Помимо Fork и Merge, есть еще один способ.

Я не уверен насчет Bitbucket и Github, но в Gitlab есть функция, позволяющая защитить ветку. Таким образом, никто, кроме «главного пользователя», не может отправить эту ветку. Таким образом, разработчики могут вставлять в ветки функций, а затем эти ветки могут быть объединены в master ветку «главным пользователем».

person Tippa Raj    schedule 20.10.2013
comment
Bitbucket имеет аналогичный механизм с ограничениями веток: блог. bitbucket.org/2013/09/16/ - person Adam Parkin; 20.03.2015