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

Question

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

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

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

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

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

4. Что-то еще?

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

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

Answer 1

Чтобы обновить запрос на извлечение

Чтобы обновить запрос на извлечение (пункт # 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

Answer 2

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

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

Answer 3

Мое мнение о наилучшей практике: как только вы готовы упаковать запрос на получение, у него должна быть собственная уникальная ветка тем, специально для этой цели, в самом начале.Вы начинаете с того, что отправляете эту ветку в свой репозиторий github, например,

git push origin name-of-pull-request-branch

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

Некоторые предпочитают, чтобы вы называли такие ветви своим именем пользователя в github.Таким образом, они могут свободно проверить это локально, чтобы попробовать его, с такими преимуществами, как

• меньше страха перед столкновением имени ветви
• легче запомнить, что это такое

Я обычно называю свои ветви запроса на получение что-то вроде

claybridges-do-the-things