GitHub: повторное открытие объединенного запроса на перенос

101

Я внес некоторые изменения
Я отправил запрос на перенос
Запрос на вытягивание был принят и объединен.
Мы нашли ошибку
Изменения были снова удалены, а я исправил ошибку.

Теперь я исправил ошибку и хочу повторно отправить запрос на перенос с 1 дополнительной фиксацией. Есть ли способ повторно открыть запрос на перенос или обновить его, или мне нужно создать новый запрос на перенос, снова ввести описание и т. Д.? У Gitorious есть эта функция, и мы недавно перешли на GitHub.

github merge pull-request

— Майкл Паркер
источник

Сегодня я был в подобной ситуации, то есть использовал кнопку «Merge Pull Request», которая по умолчанию объединяет изменения в целевую ветку и закрывает PR. Позже я обнаружил ошибку при тестировании, которую хотел исправить исходный разработчик. Мне нужен был способ повторно открыть этот PR, чтобы можно было добавить больше коммитов к тому же PR, но не смог, так как нет кнопки для повторного открытия PR.

— SBirthare

114

Кажется, ответ таков: вы не можете.

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

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

— Майкл Паркер
источник

8

Я не знаю, когда это было изменено, но вы можете комментировать и повторно открывать закрытые PR.

— LB

16

@LB, похоже, вы не можете повторно открыть PR, которые были закрыты и объединены .

— A Kaptur

1

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

— SsjCosty

7

@SsjCosty Но это не возобновление закрытого и объединенного PR. Вы всегда можете открывать новые запросы на вытягивание, что и требуется для вашего решения.

— Адам Грант

1

«Может быть, хороший запрос функции для будущего GitHub». На самом деле, нет. Если бы PR можно было переопределить после создания, то люди, проверяющие PR в разное время, потенциально сместились бы. Просто создайте еще один PR и «упомяните» предыдущий в тексте. Если вы хотите сослаться на какую-то веху, смотреть не на PR, а на теги.

— Скотт Прайв,

12

Я только что успешно повторно открыл запрос на перенос

Комментирование запроса на вытягивание
Нажав кнопку «Отправить и повторно открыть», которая появилась в форме комментария.

— Тим Ловелл-Смит
источник

1

Мне не удалось воспроизвести это - не могли бы вы объяснить шаги, необходимые для того, чтобы увидеть такое поведение? Я пробовал комментировать закрытый запрос на перенос (не работал), комментировать закрытый запрос на перенос и нажимать на ветку, которую он втягивал (не сработало). Есть что-нибудь еще попробовать? Требуется ли как-то объединить запрос на перенос, а затем как-то разделить его?

— Майкл Паркер

Я не знаю, в чем заключается скрытое требование, имеющее значение. Может быть любое из (представили новое изменение для запроса на вытягивание, я являюсь членом владельцев проекта, другие ...)

— Тим Ловелл-Смит

1

Я пробовал все, что вы упомянули, но все равно не вижу. Я владелец репо. Поиск в Google по запросу «Отправить и повторно открыть GitHub» дает одно нажатие - эту страницу. Любая дополнительная информация была бы чрезвычайно полезной. Ваш запрос на вытягивание был изначально отклонен?

— Майкл Паркер

53

Я могу воспроизвести это с помощью не связанных запросов на вытягивание, но этот поток не об этом.

— Дэн Телло

2

Да, он имеет в виду закрытые вытяжки, а не объединенные вытяжки.

— Loujaybee,

4

Просто создайте новую ветку из существующей ветки, в которой вы сделали дополнительную 1 фиксацию. Оттуда отправьте запрос на перенос.

— Шива Голлапалли
источник

3

Это приведет к новому запросу на перенос без истории оригинала.

— Дэйв

1

Вот что я в итоге сделал. Да, история менее линейна, но для меня это нормально.

— Possen

4

Вы можете использовать действие возврата:

Он создаст еще один запрос на перенос, отменяющий все изменения, сделанные в объединенном PR.

— Уильям Векл
источник

Это не лучшая практика :)

— антонбормотов

3

@antonbormotov, можете ли вы предложить лучший подход?

— Уильям Векл

Предположим, мы объединили pr с коммитами (mA и mB) в стабильную ветку, которую мы хотим вернуть. После слияния «revert» пр история будет иметь вид дерева коммитов: XY-mA-mB-CD-rA-rB-EF. Почему вы хотите видеть в истории все эти коммиты, которые применяют изменения (mA, mB), а затем отменяют их (rA, rB)? Было бы лучше перебазировать и удалить эти «плохие» коммиты mA и mB из стабильной ветки и сохранить историю в чистоте. Конечно, это имеет смысл, если слияние было относительно недавним.

— antonbormotov 07

1

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

— Майкл

У меня был похожий сценарий с небольшими отличиями. У меня был PR, который мне нужно было просмотреть, и я должен был ждать, пока будет объединен еще один PR. Но я этого не увидел и преждевременно слил этот пиар. Я действительно сделал то, что предложил @WilliamWeckl. Но теперь я хочу создать такой же PR с теми же изменениями, которые были созданы изначально. Но когда я создаю PR, основная ветвь не показывает никакой разницы, хотя когда я вижу отдельные файлы, они разные. Есть предположения?

— Vikas