Слияние только с веткой на BitBucket/GitLab/GitHub?

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

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

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

Ответ 1

Да: он называется forking (как в GitHub fork и его советы, BitBucket fork и вилка GitLab).

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

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

forking


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

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

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

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


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

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

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

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

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

Ответ 2

Помимо вилки и слияния есть другой способ.

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