Предпочтительный рабочий процесс Github для обновления запроса на извлечение после просмотра кода

Я отправил изменение в проект с открытым исходным кодом на Github и получил комментарии к обзору кода от одного из членов основной команды.

Я хотел бы обновить код с учетом комментариев и повторно отправить его. Каков наилучший рабочий процесс для этого? Из моего ограниченного знания git / github я мог сделать любое из следующего:

1. Обновите код как новый коммит и добавьте как первоначальный, так и обновленный коммит в мой запрос на извлечение.

2. Каким-то образом (??) откатить старый коммит из моего репозитория и создать один новый коммит, содержащий все, а затем вызвать запрос на извлечение для этого?

3. git commitесть функция изменения, но я слышал, что вы не должны использовать ее после того, как вы выдвинули коммит за пределы вашего локального репозитория? В этом случае я произвел изменение на своем локальном ПК и отправил в свою ветку github проекта. Можно ли использовать «изменить»?

4. Что-то другое?

Кажется, что вариант 2/3 был бы хорош, поскольку проект с открытым исходным кодом имел бы только один коммит в своей истории, который бы реализовал все, но я не уверен, как это сделать.

Примечание: я не знаю, влияет ли это на ответ или нет, но я не вносил изменения в отдельную ветку, я просто сделал коммит поверх master

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

№ 2 и № 3 не нужны. Если люди хотят видеть только место, где была объединена ваша ветка (а не дополнительные коммиты), они могут использовать git log --first-parentтолько для просмотра фиксации слияния в журнале.

Чтобы обновить пул-запрос

Чтобы обновить пул-запрос (пункт № 1), единственное, что вам нужно сделать, это извлечь ту же ветку, из которой пул-запрос, и нажать на нее снова:

cd /my/fork
git checkout master
...
git commit -va -m "Correcting for PR comments"
git push

Необязательно - Очистка истории коммитов

Вас могут попросить объединить ваши коммиты вместе, чтобы история репозитория была чистой, или вы сами хотите удалить промежуточные коммиты, которые отвлекают от «сообщения» в вашем запросе на извлечение (пункт № 2). Например, если ваша история коммитов выглядит так:

$ git remote add parent git@github.com:other-user/project.git
$ git fetch parent
$ git log --oneline parent/master..master
e4e32b8 add test case as per PR comments
eccaa56 code standard fixes as per PR comments
fb30112 correct typos and fatal error
58ae094 fixing problem

Хорошей идеей будет объединить все вместе, чтобы они выглядели как один коммит:

$ git rebase -i parent/master 

Это предложит вам выбрать, как переписать историю вашего запроса, в вашем редакторе будет следующее:

pick 58ae094 fixing actual problem
pick fb30112 correct typos
pick eccaa56 code standard fixes
pick e4e32b8 add test case as per PR comments

Для любого коммита, который вы хотите принять в предыдущем коммите, измените выбор на сквош:

pick 58ae094 fixing actual problem
squash fb30112 correct typos
squash eccaa56 code standard fixes
squash e4e32b8 add test case as per PR comments

И закройте свой редактор. Затем Git перезапишет историю и предложит вам предоставить сообщение о коммите для одного комбинированного коммита. Внесите соответствующие изменения, и ваша история коммитов будет краткой:

$ git log --oneline parent/master..master
9de3202 fixing actual problem

Протолкните это к вилке:

$ git push -f
Counting objects: 19, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (11/11), 978 bytes, done.
Total 11 (delta 9), reused 7 (delta 6)
To git@github.com:me/my-fork.git
   f1238d0..9de3202  HEAD -> master

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

Изменение истории в публичных репозиториях - это плохо

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

Однако, исправление истории вашего форка для исправления изменений, которые вы предлагаете интегрировать в репозиторий, - это хорошо. Таким образом, нет никаких оговорок, подавляющих "шум" из ваших запросов на получение.

Записка о ветвях

В приведенном выше примере я показываю, что запрос на извлечение пришел из masterветви вашего форка, в этом нет ничего плохого, но он создает определенные ограничения, такие как, если это ваша стандартная техника, возможность иметь только один PR, открытый для репозитория. , Однако лучше создать ветку для каждого отдельного изменения, которое вы хотите предложить:

$ git branch feature/new-widgets
$ git checkout feature/new-widgets
...
Hack hack hack
...
$ git push
# Now create PR from feature/new-widgets