Слить запрос на перенос в другую ветку, чем по умолчанию, в Github

Ответ 1

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

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

Вы можете найти hub драгоценный камень полезным при работе с компонентами запроса на растяжение.

Этот камень завершает ручной процесс, который:

• Добавить удаленный для вилки в локальную проверку.
• Извлеките этот пульт.
• git checkout ${target_branch} && git merge ${remote}/${branch}
• git push origin ...

Ответ 2

Начиная с 15.08.2016 г. GitHub позволяет изменять целевую ветвь запроса на растяжение через графический интерфейс пользователя:

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

Ответ 3

Альтернативой использованию драгоценного камня хаба, упомянутого в других ответах, является использовать командную строку для объединения запросов локального pull, что позволяет сделать:

$ git fetch origin
$ git checkout *target_branch*
$ git merge pr/XXX
$ git push origin *target_branch*

Команды выше работают напрямую, если вы сначала добавили следующую строку в ваш файл .git/config:

fetch = +refs/pull/*/head:refs/remotes/symbolic_name_origin_or_upstream/pr/*

Что это значит, вы можете загрузить запросы ВСЕ. Поскольку это может быть нежелательно для огромных репозиториев, GitHub изменил инструкции, чтобы использовать синтаксис git fetch origin pull/ID/head:BRANCHNAME, который позволяет избежать изменения файла конфигурации и загружает только этот запрос с одним нажатием.

Ответ 4

Нет ничего плохого в решении Daniel Pittman, однако я бы рассматривал эти слияния как "не быструю перемотку вперед", т.е. изменяя шаг 3 для:

git checkout ${target_branch} && git merge --no-ff ${remote}/${branch}

Используя --no-ff, история будет легче читать. Он ясно скажет, что $n совершает транзакции из $branch, и это также облегчит вам жизнь, если вам нужно вернуть что-то в этой ветке.

Чтобы ответить на вопрос eoinoc и дать дополнительный совет:

После выполнения слияния ваш git cli предложит вам написать сообщение, как правило, общее сообщение появится, говоря что-то вроде

Слияние ветки удаленного отслеживания "пользователь/их ветвь" в вашу ветвь

Обязательно отредактируйте это сообщение и включите ссылку на номер запроса на вытягивание. То есть: (Предполагая, что номер запроса на вытягивание равен 123)

Слияние ветки удаленного отслеживания "пользователь/их ветвь" в вашу ветвь

refs # 123 что-то решить...

Итак, в следующий раз, когда вы заходите на страницу github issues/pull-requests и проверяете этот конкретный запрос на вытягивание, вы увидите свое сообщение со ссылкой для фиксации, где вы сделали слияние.

Вот скриншот, что я имею в виду.

Ответ 5

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

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

Затем вернитесь в свой собственный репозиторий и примите новый запрос на pull. Вуаля!

Ответ 6

Для этого перейдите на главную страницу репозитория, нажмите ветки и измените ветвь по умолчанию от мастера на что-то еще, в моем случае "dev".

После этого всякий раз, когда кто-то создает запрос на растяжение, кнопка merge автоматически объединяет запрос в "dev", а не master.