git pull вероятно создает коммит.Если вы делаете локальный коммит, а затем запускаете git pull после того, как кто-то еще передает коммит в репозиторий, Git загружает коммит другого разработчика и затем объединяет его с вашей локальной веткой.
Как избежать этих коммитов слиянияв будущем
Вы можете использовать git pull --rebase, чтобы предотвратить это в будущем, но перебазировка имеет свои риски, и Я рекомендую избегать pull в целом .
Вместо этого я рекомендую вам следовать этой схеме использования:
# download the latest commits
git remote update -p
# update the local branch
git merge --ff-only @{u}
# if the above fails with a complaint that the local branch has
# diverged:
git rebase -p @{u}
Объяснение
git remote update -p загружает все коммиты в удаленных репозиториях и обновляет удаленныйотслеживание веток (например, origin/master).Он НЕ касается вашей рабочей директории, индекса или локальных ветвей.
Аргумент -p удаляет удаленные ветви ветки.Таким образом, если ветка foo удалена в репозитории origin, git remote update -p автоматически удалит ваш origin/foo ref.
git merge --ff-only @{u}, сообщающий Git объединить вышестоящий потокветвь (аргумент @{u}) в вашу локальную ветвь, но только если ваша локальная ветвь может быть «быстро перенаправлена» в вышестоящую ветвь (другими словами, если она не расходилась).
git rebase -p @{u} эффективно перемещает коммиты, которые вы сделали, но еще не нажали на верхнюю ветвь, что устраняет необходимость создавать глупые коммиты слияния, которых вы пытаетесь избежать.Это улучшает линейность истории разработки, облегчая просмотр.
Опция -p указывает Git сохранять слияния.Это препятствует тому, чтобы Git линеаризовал коммиты, которые были перебазированы.Это важно, если, например, вы объединили ветвь функции в master.Без -p каждый коммит в ветви объекта будет дублироваться на master как часть линеаризации, выполняемой git rebase.Это усложнит просмотр истории разработки, а не упростит ее.
Остерегайтесь : git rebase может не выполнить то, что вы ожидаете, поэтому просмотрите результаты, прежде чем нажимать.Например:
git log --graph --oneline --decorate --date-order --color --boundary @{u}..
Я предпочитаю этот подход, а не git pull --rebase по следующим причинам:
- Позволяет видеть входящиеапстрим фиксирует перед тем, как вы измените свою историю, чтобы включить их.
- Позволяет передать опцию
-p (--preserve-merges) в git rebase на случай, если вам необходимо отменить намеренное слияние (например,объединение уже выдвинутой ветви функций в master).
Сокращение: git up вместо git pull
Чтобы упростить выполнение вышеизложенного, ярекомендуем создать псевдоним up:
git config --global alias.up '!git remote update -p; git merge --ff-only @{u}'
Теперь для обновления ветки нужно всего лишь запустить:
git up
вместо git pull.Если вы получили сообщение об ошибке, потому что ваша локальная ветвь отклонилась от вышестоящей ветки, это ваша реплика для перебазирования.
Почему бы не git pull --rebase?
Запуск git pull --rebase эквивалентен запуску git fetch затем git rebase.Это попытается выполнить быструю пересылку к новым восходящим коммитам, но если это невозможно, то это переместит ваши локальные коммиты на новые восходящие коммиты.Обычно это нормально, но будьте осторожны:
- Перебазирование - это сложная тема, и вы должны понимать последствия до перебазирования.
git pull --rebase не дает вам возможности исследоватькоммиты до их включения.В зависимости от того, что изменилось в восходящем потоке, вполне возможно, что rebase является неправильной операцией - rebase --onto, merge, reset или push -f может быть более подходящим, чем простой rebase. - (В настоящее время) невозможно передать
--preserve-merges в операцию перебазирования, поэтому любое преднамеренное объединение ветви объекта будет линеаризовано, воспроизводя (и, следовательно, дублируя) все фиксации ветви компонента.
«Исправление» существующего коммита слияния, созданного git pull
Если вы еще не выдвинули коммит слияния, созданный git pull, вы можете отменить коммит слияния. Предполагая, что вы не сделали никаких преднамеренных слияний (например, слияние уже добавленной функциональной ветви в вашу текущую ветвь), следующее должно сделать это:
git rebase @{u}
Приведенная выше команда говорит Git выбрать все коммиты без слияния, достижимые из HEAD (текущий коммит), минус все коммиты, достижимые из @{u} (что является сокращением для «восходящей ветви», т.е. origin/master, если HEAD равно master), воспроизведите (cherry-pick) их поверх ветви восходящего потока, а затем переместите текущую ссылку на ветку, чтобы указать на результат воспроизведения коммитов. Это эффективно перемещает коммиты без слияния в самый последний вышестоящий коммит, что исключает слияние, созданное git pull.
Если у вас есть преднамеренный коммит слияния, вы не хотите запускать git rebase @{u}, потому что он будет воспроизводить все из другой ветки. Разобраться с этим делом значительно сложнее, поэтому хорошо использовать git up и вообще избегать git pull. Вам, вероятно, придется использовать reset, чтобы отменить слияние, созданное pull, а затем выполнить git rebase -p @{u}. Аргумент -p для git rebase не сработал для меня надежно, поэтому вам может понадобиться использовать reset для отмены преднамеренного объединения, обновить локальную ветвь до @{u}, а затем повторить преднамеренное объединение ( что было бы больно, если бы было много конфликтов с волосатыми слияниями).