Ответ 1
Этот сценарий не является чем-то необычным.
Ключевым моментом здесь является то, что слияния веток различны: его удаленный репозиторий develop
ветвь, которая объединяется в локальную (рабочую) develop
.
В локальном репозитории разработчика есть две разные ветки:
-
develop
= ветвь, в которой он/она сейчас работает. Новые коммиты идут сюда. -
origin/develop
= Это, по существу, моментальный снимок, который текущий хранилище содержит состояние веткиdevelop
на удаленном сервере. Он обновляется с помощью удаленных изменений, когда выfetch
илиpull
, и с локальными изменениями после успешногоpush
.
Теперь, когда вы делаете git pull
, происходят две вещи. Это связано с тем, что git pull
по существу является псевдонимом для других двух операций git: fetch
и merge
:
-
fetch
- выводит все новые коммиты (если они есть) из удаленного репозитория в ветвь localorigin/develop
. -
merge
- принимает новые коммиты и применяет их к локальной рабочейdevelop branch
. Это может произойти одним из двух способов:- если локальная рабочая ветвь не содержит расходящуюся историю (новое обязательство, что пульт не знает), то он просто продвигает
develop
указателя ветки вперед, сделать что указует на последнюю коммят вorigin/develop
. Это называется быстрым слиянием. - если у разработчика есть свои новые собственные коммиты, которые не присутствуют в удаленном репо и, следовательно, не в ветке
origin/develop
, то выполняется регулярное слияние, что означает, что существует новое коммитирование, содержащее изменения с обеих ветвей, По умолчанию git присваивает такие сообщения таким коммитам:Merge branch 'develop' of https://bitbucket.org/abc/xyz into develop
htps:Merge branch 'develop' of https://bitbucket.org/abc/xyz into develop
.
- если локальная рабочая ветвь не содержит расходящуюся историю (новое обязательство, что пульт не знает), то он просто продвигает
Итак, сценарий довольно распространенный.
Теперь, если это происходит очень часто, и вам не нравится видеть очень сложные графики истории фиксации, содержащие коммиты, подобные тому, о котором мы говорим, попробуйте rebase
использование rebase
вместо merge.
Вы можете сделать это двумя способами (при получении изменений с удаленного сервера):
-
git fetch; git rebase
-
git pull --rebase