Переименование ветки при запросе на вытягивание


101

На Github вы можете делать запросы на вытягивание для добавления функциональности в проект. Участие должно быть в ветке, которая, если запрос будет принята, будет объединена с главной веткой (или аналогичной) проекта.

Теперь я отправил запрос на перенос на Github, и мои статьи находятся в ветке с именем patch-1. Я могу изменить имя ветки локально,

git branch -m patch-1 newname

и, в принципе, я также могу переименовать его в своем разветвленном репо на Github, следуя инструкциям, приведенным в этом ответе . На практике это делается путем удаления старой ветки, patch-1в моем случае, и повторного использования ее с другим именем newname.

Можно ли переименовать ветку patch-1в моем разветвленном репозитории на Github, если она представляет собой запрос на перенос? Или это вызывает проблемы с управлением запросами на вытягивание?

Есть ли способ переименовать ветку в разветвленном репозитории на Github, если эта ветка является запросом на перенос?


Да, вы можете сделать это с помощью функции GitHub «Изменить базовую ветку». Посмотрите мой обновленный ответ 👇
Слободан Илич

Ответы:


117

«Переименование» удаленной ветки в git, как указано в предоставленной вами ссылке, на самом деле просто удаление ветки с последующим добавлением новой ветки с тем же хешем фиксации, но с новым именем. Если у вас открыт запрос на перенос для ветки patch-1, при удалении этой ветки запрос на перенос будет закрыт.

Итак, вы не можете переименовать ветку с открытым запросом на перенос, не удалив ветку и не удалив запрос на перенос. Однако ничто не мешает вам сделать это, запустить новую ветку с новым именем и создать новый запрос на перенос.


186
одна из причин этого не делать - это проиграть обсуждение существующего PR.
Джонни Эверсон

6
Я не понимаю, почему такое жесткое ограничение на переименование ветки-источника по PR. Такие же надоедливые манеры существуют в битбакете. Другой подход - отредактировать PR и изменить исходную ветку на другую ветку. Можно сказать: «если вы меняете исходную ветку, то все равно это новый пиар». Технически да, но также ничто не мешает разработчику настроить апстрим из совершенно другой ветки, а затем выполнить файл git push -f. PR обновлен полностью новым кодом и остается "тем же самым" PR.
Л. Холанда

31

Обновить:

Короткий ответ:

Да, вы можете сделать это с помощью функции GitHub «Изменить базовую ветку».

Как это сделать:

  1. Создайте новую ветку локально из той, имя которой вы хотите изменить
  2. Отправьте эту новую ветку в удаленное репо (теперь у вас есть две ветки с одинаковым содержимым, но разными именами)
  3. (только если PR был закрыт из-за удаления исходной ветки) - перейдите к закрытому PR, нажмите «восстановить ветку», снова откройте PR
  4. В PR выберите «Изменить», а затем щелкните раскрывающийся список, чтобы «Изменить базовую ветку» (выберите новую ветку, которую вы только что нажали)
  5. Нажмите "Сохранить".
  6. Удалить старую ветку (необязательно)

Оригинальный ответ

Короткий ответ:

Нет

Альтернативный подход:

  1. Открыть новый PR с новой (переименованной) веткой
  2. Закройте старый PR, ссылаясь на новый (например, Closed в пользу #new_pr_id)
  3. Измените описание нового PR (например, Заменяет #old_pr_id)
  4. (необязательно) Сделайте комментарий о соответствующем обсуждении старого PR

Примечание:

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


9
Данные ветки обычно удаляются после слияния, я думаю, что лучше какое-то время «терпеть» неточное имя, чем добавлять накладные расходы на новый PR, который ссылается на старый PR, с целью отслеживания исторических дискуссий.
Neo
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.