Перейменування гілки під час запиту на витягування

101

На Github ви можете робити запити на витягування, щоб додати функціональність проекту. Внесок повинен складатися з гілки, яка, якщо запит буде прийнятий, буде об’єднана у головну гілку (або аналогічну) проекту.

Тепер я подав запит на вилучення Github, і мої внески є у відділенні, яке називається patch-1. Я можу змінити назву гілки локально за допомогою

git branch -m patch-1 newname

і в принципі я також можу перейменувати його на своєму розгалуженому репо на Github, дотримуючись інструкцій, наведених у цій відповіді . Це робиться на практиці, видаляючи стару гілку, patch-1у моєму випадку, і відсуваючи її з іншою назвою newname.

Чи можна перейменовувати гілку patch-1в моєму розгалуженому сховищі на Github, коли це становить запит на витягування? Або це спричиняє проблеми з управлінням запитом на витягування?

Чи є спосіб перейменувати гілку у розгалуженому сховищі на Github, коли ця гілка є запитом на витягування?

git github pull-request

— Мікеле
джерело

117

"Перейменування" віддаленої гілки в git, як вказує посилання, яке ви вказали, насправді означає просто видалення гілки з подальшим натисканням нової з тим самим хешем коміту, але з новою назвою. Якщо у вас є відкритий запит на витяг для гілки patch-1, при видаленні цієї гілки запит на витягування буде закритий.

Отже, ні, ви не можете перейменувати гілку із відкритим запитом на витягування без видалення гілки та видалення запиту на витягування. Однак ніщо не заважає вам це робити, натискаючи нову гілку з новою назвою та створюючи новий запит на витягування.

— арбілі
джерело

186

однією з причин цього не є втрата дискусії щодо існуючого PR.

— Джонні Еверсон,

6

Я не розумію, чому таке жорстке обмеження перейменування гілки джерела на PR. Таке ж надокучливе поведінка існує і в bitbucket. Іншим підходом було б редагування PR та зміна гілки джерела на іншу гілку. Можна сказати, "якщо ви зміните гілку джерела, то це все одно новий PR". Технічно, так, але також ніщо не заважає розробнику налаштовувати вгору з абсолютно іншої гілки, а потім робити a git push -f. PR оновлений цілим новим кодом і все ще є тим самим PR.

— L. Holanda

31

Коротка відповідь:

Немає

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

Відкрийте новий PR з новою (перейменованою) гілкою
Закрийте старий PR, посилаючись на новий (наприклад, Закрито на користь #new_pr_id)
Змініть опис нового PR (наприклад, замінює #old_pr_id)
(необов’язково) Коментуйте відповідне обговорення старого PR

Примітка:

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

— Слободан Іліч
джерело

9

Дані гілки, як правило, видаляються після об'єднання, я думаю, що краще "терпіти" ім'я ненадовго, аніж додавати накладні витрати на новий PR, який посилається на старий PR з метою відстеження історичного обговорення.

— Нео,