Ответ 1
Что делать дальше - это продолжать вносить новые функции или исправлять другие ошибки в своих собственных ветвях (подталкивается только к вашей вилке).
Значение вашей вилки остается, но ветки внутри вашей вилки могут приходить и уходить.
Вы также можете удалить вилку, если вы не планируете вносить дополнительные взносы, но она удалит соответствующую запись в "Хранилищах, в которые вы вносите вклад" .
Легче:
- удалите ветвь
fix(фактически, теперь она удалена для вас) на вашей вилке (и в вашем локальном клонированном репо: см. Удалить ветвь Git как локально, так и удаленно") -
git pull upstream master(еслиmasterбыла веткой, в которой было исправлено ваше исправление: слияние будет быстрым): в этой точке нет необходимости переадресации. - воссоздайте ветвь исправления поверх обновленного локального
master(теперь с последним отupstream master).
Однако никогда не забудьте сделать один шаг перед отправкой любого будущего запроса на перенос:
переформатировать сначала вашу текущую ветку (fix) из ветки адресата восходящего потока
(upstream являющийся исходным репо, которое вы разветкили: см. "В чем разница между происхождением и восходящим потоком в github?)
Прежде чем отправлять что-либо обратно в исходное репо ( "вверх по течению" ), вам необходимо убедиться, что ваша работа основана на верхней части последнего из указанного оригинального репо (или запрос pull не приведет к быстрой перемотке вперед слияние, когда оно было применено обратно на upstream repo).
См. Например, Рабочий процесс для управления запросами на перенос в общих репозиториях в github.
Другими словами, upstream может развиваться (на него нажимаются новые коммиты), пока вы заняты исправлением. Вам нужно переделать исправления поверх этой последней работы сверху, чтобы убедиться, что ваши коммиты по-прежнему совместимы с последней версией upstream.
OP Santosh Kumar спрашивает в комментариях:
Я потянул и слился с
upstream, чтобы освоить, что теперь?
Если вы не внесли никаких новых исправлений со времени вашего недавнего запроса на перенос, см. выше (удалите и заново создайте новую ветвь fix поверх обновленной master).
Если вы сделали больше работы с момента запроса на перенос, я бы не слился с upstream, если я хочу сделать новый запрос на pull: я бы потянул и rebase:
git pull --rebase upstream master
Таким образом, вся моя новая локальная работа переигрывается поверх самой последней транзакции upstream master (полученной в моем локальном репо), предполагая, что master - это целевая ветвь, которая будет интегрировать мой будущий запрос на перенос.
Затем я могу подтолкнуть мою локальную работу к 'origin', которая является моей вилкой на GitHub upstream.
И из моей вилки на GitHub я могу смело сделать запрос на растяжение, зная, что он добавит только новые коммиты в upstream без необходимости разрешения слияния: слияние этих новых коммитов в upstream repo будет означать простое слияние быстрых переходов.
A git pull --rebase без указания ветки, поверх которой вы хотите переустановить свою (в настоящее время выданную) ветвь fix, не будет работать:
Это (
git pull --rebase) говорит:
You asked to pull from the remote '`upstream`', but did not specify a branch.
Должен ли я добавить мастер наконец? И что это будет делать, удалит ли моя ветвь
fix?
Да, вы можете указать ветку, которая будет объектом запроса на pull, например 'master'.
Это не приведет к удалению ветки fix, но воспроизведет ее поверх верхнего master, выбранного в вашем репо.