Почему git (иногда) клонирует коммит при слиянии?

а затем объединил или перебазировал локальный

Он перебазировался. Когда вы перебазируете, вы создаете дубликаты shas. При слиянии вы создаете единую фиксацию слияния.

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

Вручную передать --rebase для вытягивания

git pull --rebase

Настройте pull для выполнения перебазирования по умолчанию вместо слияния (этот параметр может быть в вашем глобальном, репо или системном файле конфигурации)

git config pull.rebase true

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

branch.<branch>.rebase true 

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

Простой вид

Проблема в том, что вы не понимаете, что такое коммит на самом деле. Хэш коммита — это не хэш вашего патча, это скорее хеш системы в целом. Таким образом, когда вы выполняете слияние, оно функционально применяет все исправления в обеих (или более) ветвях, которые вы объединяете, создаете новое полное дерево кода и создаете его в дереве объектов с хэшем, представляющим текущее состояние. .

Перебазирование похоже: вы функционально перемещаете все патчи в дереве, и результат будет другим. Они отличаются, потому что порядок применения исправлений имеет значение и влияет на хэш. На самом деле вы можете сделать это как простой тест, чтобы показать разницу:

Создайте новый репозиторий с одним файлом:

# echo "a" >> file
# git init
Initialized empty Git repository in /home/hardaker/tmp/h/test/.git/
# (master #): git add file
# (master #): git commit -m "new file"
[master (root-commit) 9617f27] new file
 1 file changed, 1 insertion(+)
 create mode 100644 file

Теперь давайте разветвим его:

# (master): git checkout -b new-branch
Switched to a new branch 'new-branch'

Добавьте новый файл в ветку:

# (new-branch): echo "file2" > file2
# (new-branch): git add file2 
P# (new-branch +): git commit -m "new file2" file2 
[new-branch 04f3fdf] new file2
 1 file changed, 1 insertion(+)
 create mode 100644 file2

Снова проверьте мастер и внесите изменения:

# (new-branch): git checkout master
Switched to branch 'master'
# (master): echo "b" >> file 
# (master *): git commit -m "added b" -a
[master 3b3de88] added b
 1 file changed, 1 insertion(+)

Теперь давайте отобразим журнал в виде дерева и посмотрим, что у нас есть на данный момент:

# (master):  git log --oneline --graph --all --decorate
* 3b3de88 (HEAD, master) added b
| * 04f3fdf (new-branch) new file2
|/  
* 9617f27 new file

Красивый вид на дерево с двумя ветвями. Обратите внимание на идентификатор фиксации новой ветки, потому что он изменится, когда мы перебазируем новую ветку на главную:

# (master): git checkout new-branch 
Switched to branch 'new-branch'
# (new-branch): git rebase master
 file | 1 +
 1 file changed, 1 insertion(+)
First, rewinding head to replay your work on top of it...
Applying: new file2

И глава ветки больше не имеет того же идентификатора коммита, потому что вы изменили способ построения системы.

# (new-branch):  git log --oneline --graph --all --decorate
* d9918d4 (HEAD, new-branch) new file2
* 3b3de88 (master) added b
* 9617f27 new file

Теперь, чтобы повеселиться и узнать, что такое коммит на самом деле и что такое объекты в дереве, прочтите Веб-страница Git Objects. Вы узнаете так много всего за несколько страниц.

git merge никогда не дублирует коммиты, он только создает новые (коммиты слияния)

git rebase дублирует коммиты

git cherry-pick ДОПОЛНЯЕТСЯ ли коммиты

Если вы не используете git rebase и git cherry-pick, вы будете уверены, что в вашей истории нет повторяющихся коммитов. !, единственное, что вам нужно, это как их использовать

Нашел его в настройках Github для Windows: