С защищенной веткой, предоставляемой GitLab, нам не нужна кнопка форка?

Я пытаюсь использовать GIT несколько недель. И Попытка понять некоторый рабочий процесс с Git. Затем я настраиваю сервер Gitlab для управления разрешениями. Посмотрев на сервис GitLab, я заметил, что gitlab поддерживает рабочий процесс fork с помощью встроенной кнопки. но также поддерживают возможность защиты ветки.

Я думаю, что способность «защищенная ветка» может использоваться для замены кнопки форка, я прав или есть какая-то концепция, которую я не понимаю?

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

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

это удобная версия fork-workflow? а можно полностью заменить кнопку вилки?


person Jiapon0712    schedule 03.07.2014    source источник


Ответы (1)


это... не знаю... слишком неавтоматизированно, не похоже на работу в команде.

Это способствует вкладу тех, кто не участвует, то есть именно людей, которые не являются частью команды!

Это позволяет избежать необходимости управлять:

  • сотни членов команды (только избранные могут повлиять на ваш репозиторий)
  • сотни веток (для этих сотен членов команды, которые должны работать, поскольку они, вероятно, будут работать над разными функциями)

Форк вводит рабочий процесс, который означает:

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

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

person VonC    schedule 03.07.2014
comment
Это действительно помогает, спасибо Q за обмен опытом. Таким образом, можно сказать, что если я использую GitLab для локальной компании, работающей с небольшой командой, защищенная ветвь является более легким методом. Но форк показывает свою мощь в распределенной разработке с участником. - person Jiapon0712; 03.07.2014
comment
@Jiapon0712 Jiapon0712 точно: для небольшой команды вы можете считать их всех соавторами и управлять своей веткой в ​​благословенном репо. Но для распределенной разработки форк остается лучшим решением для облегчения совместной работы. - person VonC; 03.07.2014