Lendo ogit rebase egit merge-base documentação do homem:

Depois de trabalhar no ramo de tópico criado com o git checkout -b topic origin / master, o histórico de origem / master de rastreamento remoto pode ter sido rebobinado e reconstruído, resultando em um histórico dessa forma:

                        o---B1
                       /
       ---o---o---B2--o---o---o---B (origin/master)
               \
                B3
                 \
                  Derived (topic)

onde origem / mestre costumava apontar para confirmações B3, B2, B1 e agora aponta para B, e a ramificação de tópicos foi iniciada sobre ela quando a origem / mestre estava em B3. Esse modo usa o reflog de origem / mestre para encontrar B3 como o ponto de bifurcação, para que o tópico possa ser reformulado sobre a origem / mestre atualizado por:

$ fork_point=$(git merge-base --fork-point origin/master topic)
$ git rebase --onto origin/master $fork_point topic

$fork_point será (se bem entendi) o objeto de confirmaçãoB3e, assim, ele cometeB3..topic será rebased paraorigin/master ramo.

Q1 Por que é útil omitir oB3 cometer, entregar? Os commits dotopic ramo são construídos em cima doB3 omitir isso significaria que suas modificações estariam ausentes na história doorigin/master ramo. Rebasing theB3 cometer, entregare atopic ramo levaria a uma história mais limpa, não é?

Q2 Alguém pode vincular / descrever brevemente casos de uso prático do--fork-point opção no fluxo de trabalho git?