Как заставить git повторно использовать существующий коммит sha1 из не покинутой ветки? - PullRequest
1 голос
/ 26 февраля 2020

Предположим, что у нас есть (Z - коммит слияния):

...--o--A--C            <-- master
        |\
        | --B           <-- branch
         \   \   
          ----Z         <-- develop

После git checkout branch; git rebase master и некоторых коммитов

             B¹-D       <-- branch            
            /         
...--o--A--C            <-- master
        |\
        | --B           
         \   \   
          ----Z         <-- develop

Затем необходимо обновить разработку: git checkout develop; git rebase master --rebase-merges

             B¹-D       <-- branch            
            /         
...--o--A--C            <-- master
        |\ |\
        || | --B²
        ||  \   \
        ||   ----Z²     <-- develop
        | \
        |  -B
         \   \   
          ----Z         [abandoned]

Если я объединю «ветку» с «разработкой», история будет содержать как B¹, так и B². Можно ли попросить git обнаружить, что фиксация, равная B², уже существует в не покинутой ветви "ветка", и повторно использовать ее?

1 Ответ

0 голосов
/ 26 февраля 2020

Во-первых, обязательно добавьте любую опцию, например --rebase-merges перед веткой, на которую вы перебазируете.

git rebase --rebase-merges master 

Затем рассмотрите перебазирование develop на branch вместо master: branch уже включает B1, и B2 повторяться не будет.
В интерактивной rebase (опция -i) вы будет иметь возможность отбросить D (коммит с branch, который вам не нужен в разработке): это может сработать, если есть только один из двух коммитов, указанных c в branch и не в develop. Если история более сложна, это будет громоздко.
Конечный результат будет B1-Z' для вашего нового ребазированного develop, с повторным использованием B1 в соответствии с запросом.

Ключевая идея, как Торек объясняет :

То есть:

Обратите внимание, что любые коммиты в HEAD, которые вводят те же текстовые изменения, что и коммит в HEAD..<upstream>, опущены (т.е. патч, уже принятый в восходящем направлении с другим сообщением фиксации или отметкой времени, будет пропущен.)

Поэтому B не будет повторяться как B2, а B1 будет сохранено / повторно, даже если их родительские коммиты (B и B1) и временные метки различаются.

...