Как поддерживать GitHub в актуальном состоянии без слияния или использования CLI?

Question

Обычный поток GitHub для участия в репо - это создание ветки восходящего потока, клонирование локальной копии, в которую вы вносите изменения, затем откат назад до своего форка и затем создание PR, чтобы ваши изменения были объединены с восходящим.

Но если после этого апстрим изменится, как вы обновите свой форк, не создавая коммит слияния (а также без использования git CLI)?

Я уже знаю, как сделать это таким образом, чтобы создать коммит слияния или который зависит от интерфейса командной строки git. Этот вопрос касается только использования веб-сайта GitHub.com или приложения GitHub Desktop (без интерфейса командной строки).

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

Повторюсь: любые ответы, которые используют CLI или создают коммит слияния (например, таким образом ), не будут отвечать на этот вопрос, так как я явно ищу решение без CLI.

Answer 1

без фиксации слияния или использования CLI?

Непосредственно только с веб-интерфейсом GitHub, поскольку это потребует перебазирования вашей PR-ветки поверх upstream/master

Итак, вкратце: нет.
Но в меньшей степени ... может быть, если вы действительно хотите попробовать.

Перебазирование через веб-интерфейс GitHub действительно возможно, с сентября 2016 года , ...

• если вы являетесь владельцем исходного репо и хотите интегрировать PR-ветку
• если ни один из воспроизведенных коммитов не привел к конфликту

(Это отличается от GitHub Desktop , который с 5 июня 2019 г. поддерживает перебазирование. Но это интерфейс для Git CLI, как и другие инструменты. Например, GitKraken и интерактивный ребаз )

Таким образом, запутанный обходной путь будет:

• для извлечения, затем нажмите upstream/master на ветку master вашего собственного форка (операция CLI, но об этом ниже)
• измените базовую ветвь вашего текущего PR на master (таким образом, PR в том же репозитории: ваш собственный форк), при условии, что вы не нажали на master.
  Значение: master в вашем форке представляет обновленный upstream/master, с upstream - исходный репозиторий, который вы разветвили.
• Поскольку вы являетесь владельцем этого репозитория (своего форка), GitHub может показать вам, можете ли вы перебазировать указанную ветку в базовую ветку PR (master), но только если конфликта нет.
• наконец, снова измените базовую ветку на <originalRepo>/master (которая является целевой целью вашего PR)

Самый первый шаг обычно выполняется через командную строку, но ... может быть, есть хитрость, чтобы сделать это (обновить основной мастер в вашей ветке) через веб-интерфейс: см. " Быстрый совет: синхронизируйте вилку с оригинал через веб-интерфейс GitHub"от Бруно Скворц

Короче говоря, это включает в себя:

• создание новой ветви из вашего текущего master (что будет на upstream/master в то время, когда вы разветвите исходный репозиторий)

• Создание PR с этой новой веткой и <originalRepo/master>
• делает базовый переключатель до создания PR

Это шаг, который искусственно заставляет upstream/master обновиться

Вы можете создать и объединить его с помощью кнопки «Запрос на объединение слияния» (и «Подтверждение слияния» впоследствии): слияние будет тривиальным: без слияния.

Конечный результат: ваша собственная ветка master (в вашем форке) обновлена ​​с помощью upstream/master (ветка master исходного репозитория)!

Затем вы можете возобновить шаги, которые я описал выше, и изменить базу вашего текущего PR на собственную (теперь обновленную) master ветку, и посмотреть, сможете ли вы сделать это заново!

Answer 2

Это возможно с GitHub Desktop начиная с версии 1.0.7 , учитывая следующее:

• Если текущая ветвь не имеет никаких коммитов впереди по течению (исходное репо форка), новые коммиты могут быть получены без создания нового коммита слияния

  В GitHub Desktop:

  1. Клонируйте свой репозиторий из File > Clone Repository

  2. Fetch origin, который также автоматически выбирает восходящий поток

  3. Перейдите к Branches, нажав там, где написано Current Branch

  4. Нажмите Choose a branch to merge into <branch> внизу

  5. Найдите upstream/<branch>, затем нажмите Merge upstream/<branch> into <branch>

  6. Push to origin, et voilà!

• В противном случае, если текущая ветвь имеет коммиты перед форком, то, конечно, нужно создать коммит слияния или перебазировать и принудительно нажать. Для перебазирования, которое может быть более предпочтительным, сделайте следующее:

  1. В GItHub Desktop перейдите в меню Branch, затем Rebase Current Branch

  2. Найдите upstream/<branch>, затем нажмите Start Rebase

  3. Решить любые конфликты, возникшие в результате перебазировки

  4. Принудительный толчок к началу координат. Вы получите предупреждение за это по понятным причинам.

Чтобы избежать принудительного нажатия на вашу работу, когда ваша текущая ветвь находится впереди и позади своего предшествующего партнера, либо создайте новый коммит слияния, либо:

• Создать новую ветку на основе всех ваших изменений

• При необходимости вернуть исходную ветку в исходное состояние (прежде чем она отклонится от исходного репо)

• Выполните шаги из первого сценария и объедините ваши изменения с вашей веткой.

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

---

Демонстрационный GIF для первого сценария: https://imgur.com/a/8wci2yf

Некоторые проблемы GitHub, связанные с этим:

• Добавить апстрим к разветвленным репозиториям

• мульти-удаленная поддержка на рабочем столе

Answer 3

Обновление Примечание: подход, не основанный на CLI, который может помочь: Есть ли способ заставить GitHub Desktop перебазировать ветвь по отношению к мастеру?

Единственный ключздесь делается перебазирование, поэтому приведенный выше ответ должен помочь.

---

CLI way (что проще и использует git, поэтому он должен быть более полным по умолчанию)

Есть некоторые приемы, которые вы должны использовать, чтобы избежать этого.

• Не работайте над веткой master в вашей ветке.

$ git clone <your fork>
$ git checkout -b feature_branch

Вы можете работать с feature_branch, а затем подать запрос на извлечение.

• После того, как ваши изменения объединены в ведущем устройстве верхнего уровня, вы можете извлекать его из исходного устройства в исходное.Поскольку мастер в верхнем потоке будет располагать ваши коммиты аккуратно поверх него, коммит слияния не будет.

$ git checkout master
$ git pull upstream master
$ git push origin master

• В случае, если сопровождающий отклонился от мастера, который у вас есть в вилке, то есть он больше не является линейным, вам нужно потянутьсвежая копия этого.Это не должно быть проблемой, так как ваши изменения уже находятся в восходящем потоке.

• Если ведущий в восходящем потоке продвинулся, когда вы работали над своим PR, то вы можете сделать ребаз на себе feature_branch.

$ git checkout master
$ git pull upstream master
$ git push origin master
$ git checkout feature_branch
$ git rebase master

Подробные сведения см. В этом документе: Рабочий процесс запроса вилки и вытягивания

Answer 4

Чтобы правильно ответить на этот вопрос, важно понимать, чего вы собираетесь достичь.Я полагаю, вы хотите 1) сохранить историю ясной или 2) упростить diffs, не допуская прерывания ваших коммитов.

Если мое понимание верно, тогда используйте rebase .