Это немного сложно по нескольким причинам:
git pull означает run git fetch, затем выполните вторую команду Git, чтобы включить все, что было получено. - Git не записывает здесь , какая вторая команда используется. Вторая команда выбирается тем, кто запускал
git pull, поэтому вам нужно убедиться, что тот, кто ее запускал, запомнил, какую команду он выбрал. (Выбор основывается как на параметрах командной строки, так и на Git настройках конфигурации.) - Команда, которую необходимо использовать для получения правильного ответа, зависит как от , что поступило , так и какая вторая команда использовалась .
Практический пример: скрипт развертывания ...
Скрипты развертывания никогда не должны использовать git pull, поэтому это дает вам простой выход из проблемы: просто не используйте git pull в сценарии развертывания. Запустите git fetch, затем введите собственную вторую команду Git. Теперь вы точно знаете , какую секунду команду использовали, потому что ваш скрипт , а не пользователь, выполняющий ваш скрипт, выбрал эту вторую команду.
Теперь давайте предположим, что вторая команда, которую вы выбираете в своем скрипте, git merge. Здесь все еще есть проблема, потому что git merge может выполнить быстрое слияние, но может выполнить реальное слияние. Если происходит реальное слияние, слияние может fail . Если вы скажете , выполните только ускоренное слияние (используя git merge --ff-only), что также может привести к сбою, если требуется реальное слияние.
Не существует единого правильного действия для всех случаи здесь. Вы должны решить, чего хотите добиться, исходя из ваших ситуаций. Но давайте предположим, на данный момент, что git merge --ff-only вместе с проверкой вида «если слияние завершится неудачей, полностью прервать развертывание» достаточно. Тогда ваш скрипт будет содержать следующие строки:
git fetch origin || die ...
starthash=$(git rev-parse HEAD) || die ...
git merge --ff-only || die ...
, где die - это написанная вами функция оболочки, которая прерывает это развертывание. Другими словами, мы будем:
Использовать git fetch origin для обновления нашего локального репозитория Git новыми коммитами из origin, обновления origin/master, origin/develop и т. Д.
Это то, что делает первая строка, git fetch origin || die .... Опять же, вы должны написать функцию die.
Сохранить текущий идентификатор ha sh, чтобы мы знали, какая фиксация была текущей до мы запустили git merge --ff-only.
Выполнить git merge --ff-only, чтобы получить слияние с ускоренной перемоткой вперед или сбой, если слияние с ускоренной перемоткой невозможно (если реальное слияние требуется).
(Примечание: если вы хотите попробовать реальное слияние для этого случая, это усложняет развертывание! Вам нужно будет решить, что делать, если реальное слияние прекращается получить помощь от пользователя.)
Если все вышеперечисленное go хорошо, теперь вы готовы сравнить то, что было в коммите HEAD до * От 1091 * до что входит в HEAD коммит после git merge --ff-only. Вы делаете это с помощью простого git diff или для надежности в сценарии git diff-tree. (Команду git diff-tree в целом немного сложнее использовать, но на нее не влияют конфигурации для каждого пользователя, поэтому целесообразно использовать git diff-tree в любом сценарии, , а не , ориентированном на пользователя. ) Теперь вы можете запустить:
git diff --name-only $starthash HEAD
или:
git diff-tree --name-only $starthash HEAD
В этом случае оба выдают одинаковый вывод за исключением , в котором git diff-tree имеет переименование детектор выключен независимо от конфигурации пользователя git diff. Это будет иметь видимое различие, только если детектор переименования включен и находит переименование, и даже тогда это будет неочевидным, если вы не переключитесь с --name-only на --name-status: вы увидите, что один add-файл и один файл удаления заменяется одной операцией переименования файла из старого имени в новое имя.