Лучше ли запустить запрос на извлечение или выполнить локальный коммит слияния на master?

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

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

Итак, что я должен делать при слиянии ветки объектов в master:
выполнить коммит слияния на master, а затем отправить его в восходящий поток ИЛИ выдвинуть локальную ветвь и запустить запрос на извлечение?

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

— Ашхар Хасан
источник

Что именно вы чувствуете, что не хватает этих ответов?

— RubberDuck

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

— Ашхар Хасан

Я смотрю на это с точки зрения передового опыта или Как поддерживать хорошую историю Git .

— Ашхар Хасан

Когда я объединяю PR, я делаю это, объединяя ветку локально. Это позволяет мне убедиться, что слияние применяется корректно, и повторно запустить тесты перед публикацией результата. Запросы GitHub - это всего лишь формализация этого рабочего процесса, сам Git не имеет концепции PR.

— 12.12.15

Когда PR объединяется, он генерирует коммит слияния на master, поэтому я не думаю, что это имеет какое-либо значение для истории git. Поэтому я не думаю, что есть какая-либо причина использовать то или иное, кроме ваших личных предпочтений между командной строкой и пользовательским интерфейсом Github.

— Ixrec

Ответы:

Механизм git-merge:
использование git merge featurewhile on master объединяет ветвь featureс masterи выдает merge-commit(если ветвь не может быть быстро перенаправлена) в истории git. Для принудительного создания merge-commitсущества используйте --no-ffопцию с merge.

Механизм
запроса на GitHub Issueобъединение слияния : Когда мы запускаем запрос на извлечение на GitHub, он создает место, где люди могут говорить и обсуждать коммиты в PR до слияния. Когда PR объединяется на GitHub, он делает то же самое, что и git merge feature.

Что я должен делать?
Итак, что касается истории, между ними нет никакой разницы.
А что касается вклада, ваши участники не будут иметь ничего особенного для двух ситуаций. Они одинаковые (минус приятный маленький чат).

Лучшие практики:
И я не смог найти лучшие практики, но логика говорит, что PR не очень полезны, если в хранилище только один человек.

@lxrec и @amon помогли мне прийти к такому выводу.

— Ашхар Хасан
источник

Совет: git mergeможет не записать коммит слияния, если он может выполнить «ускоренную перемотку вперед». Для принудительной фиксации слияния вы можете добавить --no-ffопцию.

— Am

Я предпочитаю делать git-merge на локальном, а не на githuib.com, если бы мне пришлось что-то подобное на github.com, я бы предпочел не делать напрямую на ветке master, я бы предпочел ветку non-master, которая может сначала установить режим подготовки, прежде чем сделать его доступным для производства.

— Ciasto piekarz

Как сказал Ашхар , технически и исторически нет никакой разницы. Для проектов с небольшой командой я предпочитаю слияние напрямую, а не дополнительный этап создания PR. Тем не менее, когда функция нуждается в рассмотрении / обратной связи или когда это WIP и над ним будут работать несколько человек, я, как правило, открываю PR и добавляю список задач в описание PR.

Обратите внимание, что git mergeможет использоваться ускоренная перемотка вперед, если нет никаких изменений в master, поэтому вы можете захотеть использовать git merge --no-ff. Я склонен не

Таким образом, в заключение, используйте PR только тогда, когда вам нужно обсуждение. В противном случае просто слить напрямую.

— Луай Алаккад
источник

Стоит также отметить, что обсуждение и обратная связь по запросу извлечения могут исходить от автоматических источников, а также от членов команды. Если у вас настроен CI-сервер, он может давать результаты сборки и тестирования, поэтому вы никогда не объединяете то, что нарушает сборку на master.

— Эрик