Суть проблемы лежит внутри GitHub. (Я сейчас подробно расскажу.) Ответ на ваш вопрос: и нет, и да :
Есть ли способ продвинуться вверх по течению без дополнительной фиксации вверх по течению. Просто объединить запрос на включение, чтобы ветки upstream / master и origin / master были четными?
Здесь участвуют четыре группы людей:
Те, которые программируют сам GitHub. Они управляют тем, что отображается в веб-браузере, т. Е. Той зеленой кнопкой, которую вы видите на странице с надписью «Объединить этот запрос извлечения», с небольшой стрелкой вниз по краю, которая, если щелкнуть по ней, позволяет выбрать один из трех типов: сливаться.
Три типа слияния не включают в себя действие, которое вы хотели бы. Поэтому, если они изменили , добавив четвертый тип слияния, или изменили один из существующих трех, или что-то в том же духе, это могло бы дать всем в группе 3 возможность делать то, что вы хотите.
Те, у кого есть административный доступ к хранилищу в восходящем направлении. Они могут git push прямиком в верхний репозиторий. Это означает, что они могут использовать командную строку Git (вообще не GitHub) для выполнения желаемого действия, а затем запустить git push, чтобы обновить хранилище на GitHub.
Те, у кого есть доступ для записи, но , а не административный доступ, к вышестоящему репозиторию через предоставленный GitHub интерфейс. Они не могут делать то, что вы хотите - по крайней мере, до тех пор, пока люди из группы 1 не добавят это в качестве опции.
Те, у кого нет прав на запись (предположительно, включая вас): они не могут этого сделать.
Теперь, что касается этих кликающих кнопок GitHub - или, скорее, кнопки единственного числа, с тремя режимами: три предлагаемых режима обозначены следующим образом:
Объединить.
Вы можете подумать, что это сработает, но это не так, потому что он работает в эквиваленте git checkout <em>branch</em> && git merge --no-ff -m <em>message</em> <em>hash</em>. branch достаточно очевиден, а часть message равна Merge pull request #<em>number</em> from <em>repository</em>. Часть hash сложнее: это идентификатор хеша, найденный в refs/pull/<em>number</em>/head. Это идентификатор коммита конкретного коммита , который вы отправили, посредством вашего нажатия "кликающих и запрашивающих" кликающих кнопок.
Если бы GitHub использовал эквивалент git checkout <em>branch</em> && git merge --ff-only <em>hash</em> с теми же branch и hash, вы бы получили то, что хотели. Конечно, не будет коммита, содержащего текст Merge pull request .... Но это было бы хорошо. (Это новый режим, который я хотел бы добавить. Они могли бы назвать его Объединить без дополнительной фиксации или Быстрая перемотка вперед , возможно.)
Перебазировать и объединить .
Это добавляет коммиты pull-request - их может быть больше одного - которые в данный момент не находятся в ветви, к ветви. Он работает в эквиваленте git checkout <em>branch</em> && git rebase --force-rebase <em>hash</em> (возможно, с --merge или --strategy merge). Конечным результатом является то, что коммиты из запроса извлечения копируются , не объединяются, в новые коммиты с новыми и разными хэш-идентификаторами. Запрос на слияние завершен без добавления коммита слияния, поэтому сообщение Merged pull request ... отсутствует.
Вы можете подумать, что в случае, когда копируемый коммит или коммит уже находятся в правильном положении, т. Е. Только за кончиком ветви перед нажатием кнопки, GitHub не будет копировать коммиты, а вместо этого просто использовали бы их как есть, как это произошло бы, если бы они выполняли эквивалент git rebase без --force-rebase или --no-ff. Но это не так. Есть ли какая-то хорошая (внутренняя причина для GitHub) причина этого, я не знаю.
Сквош и слияние.
Это дOES эквивалент git checkout <em>branch</em> && git merge --no-commit --squash <em>hash</em> && git commit -m <em>message</em>.(--no-commit здесь избыточен: --squash подразумевает --no-commit. Это ненужная особенность реализации Git командной строки git merge --squash, поскольку, если вы действительно хотите --no-commit, вы могли быпросто укажите его.)
Поскольку это делает новый коммит, который никак не связан с коммитами, эффект которых вносится, это явно совершенно не подходит для достижения того, что вы хотите.
Сводка
Те, у кого есть доступ на запись в вышестоящий репозиторий, могут перенести ваш запрос на извлечение в репозиторий Git на компьютере, которым они управляют, объединить его вручную и нажатьвернитесь к исходному хранилищу на GitHub.Это то, на что Тобиас К. ссылается в комментарии .Это дало бы то, что вы хотите.
Если бы GitHub добавил режим слияния, который я хотел бы добавить, пользователи, которые в настоящее время объединяют ваш запрос на извлечение с кнопкой слияния Web-UI, смогут сделать это водин шаг, без привлечения собственных компьютеров и команд командной строки Git.Но без этого дополнительного режима они не могут.
То, что они на самом деле сейчас используют, это режим Rebase and merge .Из-за этого мы можем сказать:
Так что теперь на github он показывает " Эта ветвь (origin / master) на 1 коммит вперед, 1 на коммит upstream / master. "
Если бы они использовали режим Merge , вы бы увидели себя одним коммитом позади, а не одним коммитом впереди.Это было бы более дружественным для вас, но в некоторых отношениях менее приятным для себя (и, возможно, других пользователей их хранилища).Когда они используют Перебазировать и объединить , они копируют все ваши коммиты, поэтому, если вы были k коммитами раньше, вы внезапно будете k впереди и k позади: k , который вы впереди, ваш коммит, с вашими хэш-идентификаторами и k , за которыми вы находитесь, являются их копиями ваших коммитов с их хэш-идентификаторами.
Восстановление из вашего апстрима * Перебазировать и объединить
Обратите внимание, что вы можете восстановиться после этого, выполнив на своем компьютере следующее:
git fetch upstream
git checkout $branch
git rebase upstream/$branch
git push --force-with-lease origin $branch
(где $branch представляет имя вашей ветви).fetch получает свои копии ваших коммитов.checkout позиционирует вас для перебазирования, которое выполняет rebase. 1 git push отправляет новые коммиты на ваш форк (если их еще нет), а затем просит GitHub изменить вашИдея форка о $branch указывать на последний такой скопированный коммит, успешно (как если бы --force), даже если этот отбрасывает некоторые коммиты, но терпит неудачу (--force-with-lease), если коммиты отбрасываютсяне совсем то, что ожидалось.
1 Вы можете сделать это за один шаг, так как git rebase позволяет проверить ветку перед началом ребазинга, но я думаю, что это понятнеесюда.Чтобы сделать это за один шаг, используйте git rebase origin/$branch $branch.