Обеспечить актуальность запросов на получение обновлений на GitHub - PullRequest
Новая
       12

Обеспечить актуальность запросов на получение обновлений на GitHub

0 голосов
/ 19 апреля 2019

У нашей команды есть основная ветвь на GitHub и несколько других ветвей функций, которые в конечном итоге необходимо объединить с главной.

Что нужно сделать, чтобы убедиться, что ветвь функции обновлена, перед PullЗапрос создан на GitHub?Есть ли какая-то блокировка, которую мы можем реализовать в основной ветке, чтобы обеспечить выполнение актуальных функциональных ветвей перед созданием запросов на извлечение?

Ответы [ 2 ]

0 голосов
/ 19 апреля 2019

Защита веток в GitHub может потребовать обновления веток до того, как они объединятся , но не до того, как они будут созданы.Это имеет смысл.Рассмотрим: 

*---*---*---*  [master]
            |\
            | *---*---*  [feature-1]
             \
              *---*  [feature-2]

Здесь и feature-1, и feature-2 актуальны по отношению к master.Если ограничение требовало, чтобы запросы на получение обновлений были актуальными при их создании, мы можем создать PR для каждой ветви.

Но что произойдет, когда один из этих PR объединится? 

*---*---*---*-----------*  [master]
            |\         /
            | *---*---*  [feature-1]
             \
              *---*  [feature-2]

Сейчас feature-2 больше не актуален.Что должно случиться с его пиаром?Мы ничего не делаем, так как он был в курсе, когда он был создан?Мы полностью аннулируем пиар и требуем создания нового?Должен ли мы когда-либо открывать только один PR в любой момент времени?

Система GitHub применяется во время слияния .Таким образом, PR могут быть созданы до того, как они будут готовы к объединению (например, черновик PR ), и могут безопасно генерировать содержательное обсуждение, а не спешить.Это также означает, что нам не нужно иметь дело с предыдущим вопросом.

0 голосов
/ 19 апреля 2019

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

Конечно, на практике большинство разработчиков узнают из опыта, что слияние / ребазинг с master обычно является хорошей привычкой. Но эти вещи уже применяются GitHub, по крайней мере по умолчанию.

...