Бажаний робочий процес Github для оновлення запиту на витяг після перегляду коду

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

Я хотів би оновити код з урахуванням коментарів до огляду та повторно надіслати його. Який найкращий робочий процес для цього? З моїх обмежених знань git / github, я міг би зробити щось із наступного:

1. Оновіть код як новий фіксатор, і додайте початковий та оновлений фіксатор до мого запиту на витяг.

2. Якось (??) відкачує старий фіксатор із мого сховища та створює єдину нову комісію, що містить усе, а потім піднімає запит на витяг для цього?

3. git commitмає функцію внесення змін, але я чув, що ви не повинні використовувати її після того, як ви пересунули комісію за межами вашого локального сховища? У цьому випадку я внесла зміни на свій локальний ПК та переїхала до своєї гілки github проекту. Чи буде це нормально, щоб використовувати "змінити"?

4. Щось ще?

Здається, що варіант 2/3 був би непоганим, оскільки проект з відкритим кодом мав би лише один комітет у своїй історії, який би реалізував усе, але я не впевнений, як це зробити.

Примітка. Я не знаю, впливає це на відповідь чи ні, але я не вносив зміни в окрему гілку, я просто робив зобов’язання поверх майстра

Просто додайте нову комісію до гілки, яка використовується в запиті на витягнення, і натисніть її на 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