Как проверить реальный git diff перед слиянием с удаленной веткой?

Ответ 1

В документации :

git diff [--options] <commit>...<commit> [--] [<path>…]

Эта форма предназначена для просмотра изменений на ветвь, содержащая и до второй <commit>, начиная с общей предка обоих <commit>. "git diff A... B" эквивалентно "git diff $(git -merge-base A B) B". Вы можете опустить любой из <commit>, который имеет тот же эффект, что и использование HEAD.

Вы пробовали это?

Ответ 2

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

Если вы настроили свой репозиторий git через обычный "клон" и имеете refspecs по умолчанию, что означает, что ваш пульт называется "origin", и вы вытягиваете/извлекаете из "master" ветки, иногда вам может понадобиться посмотрите, что в удаленном репозитории, прежде чем вытащить его.

Так как "git pull" выполняет автоматическое слияние (если нет конфликтов), может быть приятно увидеть, что "входящее" следующее. Если вы не знакомы с тем, как работает git и каким образом управляются refspecs, это может быть немного неинтуитивным.

Предположим, что кто-то внес изменения в удаленный репозиторий (для иллюстрации, добавив строку в удаленный репозиторий, совершив изменение и нажав его), и вы введете:

$ git diff origin/master

Вероятно, вы не увидите никаких изменений; однако если вы выполните следующее:

$ git fetch; git diff ..origin/master 

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

Хорошо, зачем мы это делаем? origin/master - это refspec (см. страницы руководства). Короче говоря, это то, к чему мы обращаемся, чтобы сравнивать, тянуть или извлекать и нажимать. Все следующие функционально эквивалентны:

origin/master
remotes/origin/master
refs/remotes/origin/master

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

.git/refs
.git/refs/heads
.git/refs/heads/master
.git/refs/remotes
.git/refs/remotes/origin
.git/refs/remotes/origin/HEAD
.git/refs/remotes/origin/master
.git/refs/tags

Посмотрите .git/refs/remotes/origin/HEAD; в случае по умолчанию он укажет на ветку, которую вы используете, чтобы вытащить и нажать. В моем случае, поскольку я нахожусь на главном, содержимое этого текстового файла выглядит следующим образом:

ref: refs/remotes/origin/master

Это говорит мне, что HEAD моего пульта идентифицируется refspec 'refs/remotes/origin/master' (который, случается, имеет упомянутые выше псевдонимы).

Это не говорит нам о многом; какое состояние удаленного репозитория? Посмотрите на состояние удаленного мастера:

$ cat .git/refs/heads/master     
6d0fb0adfdfa5af861931bb06d34100b349f1d63

Хорошо, это SHA1 хэш; вероятно, фиксация. Как он помещается в этот файл? Ну, всякий раз, когда вы делаете pull или fetch, этот файл обновляется с последним фиксацией с удаленного устройства, которое было вытащено или извлечено. Это объясняет, почему мы должны git fetch до выполнения diff. Помните, git fetch просто обновляет локальную копию удаленной ветки, но не объединяет ее с вашей рабочей копией. Это абсолютно безопасно. A git fetch; git merge эквивалентно a git pull.

Как только вы сделаете выборку, git сможет увидеть самую последнюю фиксацию на пульте дистанционного управления хранилище на момент выборки.

Вы можете использовать различные комбинации спецификаторов для git, чтобы увидеть ваши различия по вашему желанию (следующие примеры используют локальную рабочую копию как неявную первую фиксацию):

$ git diff remote/origin   
This shows the incoming remote additions as deletions; any additions in your local 
repository are shown as additions.

$ git diff ...remote/origin
Shows incoming remote additions as additions; the triple-dot excludes changes
committed to your local repository.

$ git diff ..remote/origin
Shows incoming remote additions as additions; the double-dot includes changes
committed to your local repository as deletions (since they are not yet pushed).

Информация о ".." vs "..." см. git help diff, а также отличную документацию в git -scm revision selection: commit range Вкратце, для приведенных выше примеров синтаксис с двумя точками показывает, что все коммиты достижимы с начала/мастера, но не с вашей рабочей копии. Аналогично, синтаксис с тремя точками показывает все коммиты, доступные из любой фиксации (неявная рабочая копия, удаленная/начальная), но не из обоих.

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

Ответ 3

Что вы хотите сделать, как предложил Евгений Бодунов:

git diff ...remote/branch

Это будет отличаться от изменений в удаленной/ветки и игнорировать изменения из текущего HEAD.