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

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

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

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

  • Как-то (??) откат старого фиксации из моего репозитория и создание одного нового коммита, содержащего все, а затем поднять запрос на перенос для этого?

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

  • Что-то еще?

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

Примечание. Я не знаю, влияет ли это на ответ или нет, но я не делал изменений в отдельной ветке, я просто сделал фиксацию поверх мастера

ОТВЕТЫ

Ответ 1

Просто добавьте новую фиксацию в ветку, используемую в запросе на растяжение, и нажмите ветку на GitHub. Запрос на растяжение будет автоматически обновляться с помощью дополнительной фиксации.

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

Ответ 2

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

Чтобы обновить запрос на вытягивание (точка №1), вам нужно только проверить тот же ответ, из которого требуется запрос на извлечение, и нажать на него еще раз:

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

Дополнительно - Очистка истории фиксации

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

$ git remote add parent [email protected]:other-user/project.git
$ 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 [email protected]: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

Ответ 3

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

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

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

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

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

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

claybridges-do-the-things