Мій запит на притягнення об’єднано, що робити далі?


112

Нещодавно я брав участь у проекті від GitHub. Я зробив наступне:

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

Вперше я здійснив інший код, тому не знаю, що робити. Тепер авторський запит на об'єднання приєднано до оригінального репо / проекту.

Що мені робити далі? Чи слід видалити гілку? Чи варто злити гілку? Щось іще?


Додаткова інформація:

Оригінальний проект має єдину галузь.

У мене також є набір для того, щоб отримувати останні оновлення від оригінального репо. (Я зробив це так) :

git remote add upstream https://path/to/original/repo.git

І я отримую такі оновлення:

git fetch upstream

12
Гехе, ти не єдиний, хто бореться: Youtube Video :)
Енн

Відповіді:


65

Що робити далі: продовжувати надавати нові функції або виправляти інші помилки у власних спеціалізованих гілках (натиснуті лише на вашу вилку).

Значить, ваша виделка залишається, але гілки у вашій вилці можуть приходити та йти.

Ви також можете видалити вилку, якщо не плануєте робити подальший внесок, але вона видалить відповідний запис у "Сховищах, до яких ви вносите внесок" .

Простіше:

  • видаліть свою fixфілію (насправді вона тепер видалена для вас ) на вилці (і у вашому місцевому клонованому репо: див. " Видалення гілки Git як локально, так і віддалено ")
  • git pull upstream master(якщо це masterбула гілка, в яку було вбудовано ваше виправлення: злиття буде швидким вперед): у цьому моменті не потрібна нова база.
  • відтворити гілку виправлення поверх оновленої локальної програми master(зараз із останньою версією від upstream master).

Однак ніколи не забувайте жодного кроку, перш ніж надсилати будь-який майбутній запит на витяг:

перезавантажте спочатку свою поточну гілку ( fix) з гілки призначення вище

( upstreamбудучи оригінальним репо, яке ви роздвояли: див. " Яка різниця між походженням і вище за течією в github ")

Перш ніж надсилати що-небудь назад до оригінального репо-версії ("вище за течією"), вам потрібно переконатися, що ваша робота базується на останньому з вказаного оригінального репо-репортажу (або запит на витяг не призведе до швидкого злиття вперед, коли застосовано назад на upstreamрепо).
Дивіться, наприклад, " Робочий процес для керування запитами на виклик для спільних репостів у github ".

Іншими словами, ви upstreamможете еволюціонувати (створювати нові комісії), поки ви зайняті виправленням матеріалів. Вам потрібно повторно виправити свої виправлення поверх цієї останньої роботи з вищого потоку, щоб переконатися, що ваші комісії все ще сумісні з останньою версією upstream.


OP Сантош Кумар запитує в коментарях :

Я потягнув і злився з upstreamмайстром, що тепер?

Якщо ви не вносили жодних нових виправлень з часу свого останнього запиту на витяг, див. Вище (видаліть та відтворіть нову гілку fixвгорі оновленої master).

Якщо ви зробили якусь додаткову роботу з моменту запиту на виклик, я б не зливався, upstreamякщо я хочу зробити новий запит на витягнення: я б перетягнув і перезавантажив :

git pull --rebase upstream master

Таким чином, вся моя нова локальна робота відтворюється на вершині останніх upstream masterкомітетів (зібрана в моєму місцевому репо-репортажі), припускаючи, що masterце цільова гілка, яка буде інтегрувати мій майбутній запит на виклик.

Тоді я можу підштовхнути свою локальну роботу до ' origin', що є моєю вилкою на GitHub of upstream.
І з моєї розвідки на GitHub я можу спокійно зробити запит на витяг, знаючи, що він додасть лише нові комісії, upstreamне потребуючи жодної резолюції злиття: об'єднання цих нових комітетів у upstreamрепо буде означати просте швидке злиття вперед.


git pull --rebaseБез вказівки сука , на вершині якої ви хочете перебазуватися вашим ( в даний час перевірило) fixфілія не буде працювати:

Це ( git pull --rebase) говорить:

You asked to pull from the remote '`upstream`', but did not specify a branch. 

Чи потрібно нарешті додати майстер? І що це буде робити? Чи видалить мою fixгілку?

Так, ви можете вказати гілку, яка буде ціллю запиту на витяг, наприклад ' master'.
Це не видалить вашу fixгілку, але відтворить її вгорі над потоком, masterотриманим у вашому репо.


Чи можете ви пояснити базу даних із верхньої частини?
Сантош Кумар

@SantoshKumar ви повинні перебазуватися локальні коммітов на верхній частині первісного репо (тут посилаються , як вище) перед натисканням на вилку і зробити свій запит тягнути: см stackoverflow.com/questions/9257533 / ...
VonC

Так, я знаю, що я задаю основне питання. Я потягнув і злився з верхнього течії до майстра, тепер що?
Сантош Кумар

@SantoshKumar це гарне питання. Я відредагував відповідь, щоб її вирішити. Шукайте "ОП Сантош Кумар просить у коментарях: ..."
VonC

Це говорить: You asked to pull from the remote 'upstream', but did not specify a branch.Чи слід додати masterнарешті? І що це буде робити? Чи видалить мою гілку виправлення ?
Сантош Кумар

18

По-перше, вітання за ваш перший внесок у проект про Github.

Звичайний робочий процес Github - це створити нову гілку для кожної вирішеної проблеми. Таким чином, сервіс основного сховища може вирішити, яке з ваших рішень об'єднати, а яке - відхилити. Після того як гілка об'єднана вище, ця гілка більше не знадобиться і її зазвичай можна видалити.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.