Github: добавление фиксации существующего запроса на pull

Я открыл запрос на перенос rails repo на github с помощью кнопки Форк и отредактировать этот файл.

Теперь, Получив отзывы о моем PR, я хотел добавить еще несколько коммитов. поэтому вот что я закончил, сделав

$ git clone [email protected]:gaurish/rails.git #my forked repo
$ git rebase -i 785a2e5 #commit hash of my commit using which PR was opened
$ git checkout patch-3 #branch name I had to send my commits under to be shown in that PR
$ git commit -am "Changes done as per feedback"
$ git push origin patch-3

Это отлично работает, но выглядит довольно сложным процессом. Может, я ошибаюсь здесь?

мой вопрос: Правильно ли я делаю это? если нет, то каков правильный способ сделать это?

Ответ 1

Поскольку вы используете инструменты GitHub и просто меняете один файл, вы также можете перейти к файлу на GitHub, выбрать нужную ветку из верхнего левого угла в раскрывающемся списке "tree:" (patch-3 в вашем случае), и теперь выберите "Редактировать этот файл". Теперь ваши изменения будут привязаны к этой ветке и появятся в вашем запросе на тягу

Ответ 2

Я только недавно писал в блоге по этой теме:

Как мы обновляем эту ветку функций? Слияние новых восходящих коммитов очень просто, но вы хотите избежать создания слияния, поскольку это не стоит ценить, когда его подталкивают вверх по течению: вы затем эффективно перестраиваете восходящие изменения, а те, которые занимают верхние позиции, получат новый хеш (поскольку они получить нового родителя). Это особенно важно, так как эти объединенные коммиты будут отражены в вашем запросе на Github pull, когда вы нажимаете эти обновления на свою личную ветку функций github (даже если вы это сделаете после того, как вы выпустили запрос на pull).

Вот почему нам нужно переустанавливать вместо слияния:

git co devel #devel is ansible HEAD aka "master" branch
git pull --rebase upstream devel
git co user-non-unique
git rebase devel

Как опция rebase, так и команда rebase на git будут содержать ваше дерево в чистоте и избежать комминирования. Но имейте в виду, что те, кого вы сначала совершили (с которыми вы опубликовали свой первый запрос на перенос), которые были переустановлены, и которые теперь имеют новый хеш-код, который отличается от исходных хэшей, которые все еще находятся в удаленной ветке реплики github.

Теперь выталкивание этих обновлений в вашу личную ветку функций Github не произойдет здесь, так как обе ветки отличаются: дерево локальных ветвей и дерево удаленной ветки "не синхронизированы" из-за этих разных хэшей коммита. git сообщит вам сначала git pull --rebase, затем нажмите еще раз, но это не будет простым быстрым нажатием, так как ваша история переписана. Не делайте этого!

Проблема в том, что вы снова получите свои первые измененные коммиты, поскольку они были изначально, и они будут объединены поверх вашей локальной ветки. Из-за отсутствия синхронизации это притяжение не применяется чисто. Вы получите историю b0rken, где ваши коммиты появляются два раза. Когда вы нажмете все это на свою ветку функций github, эти изменения отразятся на исходном запросе на pull, который будет очень и очень уродливым.

AFAIK, на самом деле нет абсолютно чистого решения. Лучшее решение, которое я нашел, - это принудительно перенаправить вашу локальную ветвь в ветку github (фактически заставляя обновление без быстрого перехода):

Согласно git -push (1):

Update the origin repository’s remote branch with local branch, allowing non-fast-forward updates. This can leave unreferenced commits dangling in the origin repository.

Так что не тяните, просто нажимайте так:

git push svg +user-non-unique

или

git push svg user-non-unique --force

Это фактически просто перезапишет вашу удаленную ветвь, все в вашей локальной ветке. Коммиты, которые находятся в удаленном потоке (и вызвали сбой), останутся там, но будут обманывать фиксацию, которая в конечном итоге будет удалена с помощью git -gc (1). Ничего страшного.

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

Ответ 3

Вы также можете создать новый запрос на перенос, который привязан к master вместо конкретной версии abc1234.

Таким образом, любой новый commit/push в ваш репозиторий будет добавлен в запрос на перенос.