Я неправильно понял первоначальный вопрос.
Код не был изменен: специалисты по сопровождению обсуждают и предлагают изменения.
Вам необходимо внести эти изменения кода в своей ветке, а затем зафиксировать их , и pu sh их, что автоматически обновит PR.
Сначала я совершенно неправильно понял проблему. Учитывая заголовок, я все равно оставлю этот ответ ниже.
Если бы я разветвил это репо, а затем клонировал его локально, следующее, что я бы сделал, это
git remote add upstream git@github.com:GoogleCloudPlatform/java-docs-samples.git
Это будет создать еще один удаленный , указывающий на родительский репозиторий. upstream - это не специальное имя, но это соглашение, так же как origin - соглашение для вашей вилки.
Теперь, когда изменения интегрированы в исходный репозиторий, я могу быстро перенести их в моя локальная копия и пу sh их в мою вилку:
git pull -r upstream <optional branch name if different from current branch>
Перечислите свои пульты с
git remote -v
Итак, в вашем случае вы можете перетащить прямо из восходящего потока в свою ветку
git checkout ksurendra:helidon-mp-example-appengine-java11
git pull upstream master
или обновите свой локальный master и объедините это:
git checkout master
git pull upstream
git checkout ksurendra:helidon-mp-example-appengine-java11
git rebase master # Or git merge master
Имейте в виду, что git - это распределенная система контроля версий . Это именно то, что означает «распределенный»: нет центральной магистрали - теоретически вы можете использовать sh и подключаться непосредственно к рабочим станциям ваших коллег. Это просто не делается для психологической простоты.
Наиболее распространенная ситуация, когда git действительно используется в этом распределенном способе, - это поддержка форков: несколько (обычно полных) копий репозиториев.