Chciałbym zmienić bazę do konkretnego zatwierdzenia, a nie do HEAD z innej gałęzi:

A --- B --- C          master
 \
  \-- D                topic

do

A --- B --- C          master
       \
        \-- D          topic

zamiast

A --- B --- C          master
             \
              \-- D    topic

Jak mogę to osiągnąć?

Możesz uniknąć używania parametru --onto, tworząc tymczasową gałąź na zatwierdzonym zatwierdzeniu, a następnie używając rebase w jego prostej postaci:

git branch temp master^
git checkout topic
git rebase temp
git branch -d temp

Możesz nawet podejść bezpośrednio:

git checkout topic
git rebase <commitB>

Użyj opcji „na”:

git rebase --onto master^ D^ D

Komentarz jsz powyżej uratował mi mnóstwo bólu, więc oto oparty na nim przepis krok po kroku, którego używałem do zmiany bazy / przeniesienia dowolnego zatwierdzenia na inne zatwierdzenie:

1. Znajdź poprzedni punkt rozgałęzienia gałęzi, która ma zostać zmieniona (przeniesiona) - nazwij go starym rodzicem. W powyższym przykładzie jest to A
2. Znajdź zatwierdzenie, do którego chcesz przenieść gałąź - nazwij ją nowym rodzicem. Na przykładzie to B.
3. Musisz być na swojej gałęzi (tej, którą się poruszasz):
4. Zastosuj rebase: git rebase --onto <new parent> <old parent>

W powyższym przykładzie jest to tak proste, jak:

   git checkout topic
   git rebase --onto B A

Rozwiązanie tematu

Prawidłowym poleceniem odpowiadającym na wysłane pytanie może być dowolne z poniższych (zakładając, że gałąź topicjest już wyewidencjonowana):

git rebase --onto B master
git rebase --onto master~1 master
git rebase --onto B A
git rebase --onto B C
git rebase --onto B

Jeśli topicnie jest wyrejestrowany, po prostu dodajesz topicdo polecenia (z wyjątkiem ostatniego) w następujący sposób:

git rebase --onto B master topic

Alternatywnie, najpierw sprawdź oddział z:

git checkout topic

Zmień wartość dowolnego ciągu zatwierdzeń na zatwierdzenie docelowe

Podstawowa forma polecenia, którego potrzebujemy, zaczerpnięta z dokumentacji, to:

git rebase --onto <Target> [<Upstream> [<Branch>]]

<Branch>jest opcjonalna i wszystko, co robi, to sprawdzenie określonej gałęzi przed wykonaniem reszty polecenia. Jeśli już wyewidencjonowałeś gałąź, którą chcesz przestawić, nie potrzebujesz tego. Zauważ, że musisz określić <Upstream>, aby określić, w <Branch>przeciwnym razie git pomyśli, że określasz <Upstream>.

<Target>jest zatwierdzeniem, do którego dołączymy nasz ciąg zatwierdzeń. Podając nazwę gałęzi, po prostu określasz zatwierdzenie głowy tej gałęzi. <Target>może być dowolnym zatwierdzeniem, które nie będzie zawarte w ciągu przenoszonych zatwierdzeń. Na przykład:

A --- B --- C --- D         master
      \
       \-- X --- Y --- Z    feature

Aby przenieść całą gałąź funkcji, nie można wybrać X, Y, Zlub featuregdy <Target>od tych, wszystkie są rewizje wewnątrz grupy są przenoszone.

<Upstream>jest wyjątkowy, ponieważ może oznaczać dwie różne rzeczy. Jeśli jest to zatwierdzenie, które jest przodkiem wyewidencjonowanej gałęzi, wówczas służy jako punkt odcięcia. W przykładzie I, pod warunkiem, byłoby to wszystko, co jest nie C, Dalbo master. Wszystkie zatwierdzenia po <Upstream>do głowy wyrejestrowanej gałęzi są tymi, które zostaną przeniesione.

Jednakże, jeśli <Upstream>nie jest przodkiem, to git tworzy kopię zapasową łańcucha od określonego zatwierdzenia, aż znajdzie wspólnego przodka z wyewidencjonowaną gałęzią (i przerywa, jeśli nie może go znaleźć). W naszym przypadku, <Upstream>z B, C, Dczy masterbędzie w ogóle wynik popełnić Bsłużąc jako punkt przecięcia. <Upstream>jest sam w sobie poleceniem opcjonalnym i jeśli nie jest określone, to git sprawdza rodzica wyewidencjonowanej gałęzi, co jest odpowiednikiem wprowadzenia master.

Teraz, gdy git wybrał zatwierdzenia, które będzie wycinał i przesuwał, stosuje je w kolejności <Target>, pomijając te, które zostały już zastosowane do celu.

Ciekawe przykłady i wyniki

Korzystając z tego punktu wyjścia:

A --- B --- C --- D --- E         master
            \
             \-- X --- Y --- Z    feature

• git rebase --onto D A feature
  Zastosuje zobowiązuje B, C, X, Y, Zaby popełnić Di skończyć omijając Ba Cponieważ już zostały zastosowane.

• git rebase --onto C X feature
  Zastosuje zatwierdzenia Yi Zzatwierdzenie C, skutecznie usuwając zatwierdzenieX

Prostszym rozwiązaniem jest git rebase <SHA1 of B> topic. Działa to niezależnie od tego, gdzie jesteś HEAD.

Możemy potwierdzić to zachowanie z dokumentu git rebase

<upstream>Odgałęzienie upstream do porównania. Może to być dowolne poprawne zatwierdzenie , a nie tylko nazwa istniejącej gałęzi. Domyślnie skonfigurowany nadrzędny dla bieżącej gałęzi.

git rebase <SHA1 of B> <SHA1 of topic>

To również zadziała, ale rebase nie Topicwskaże wtedy nowej gałęzi tak utworzonej i HEADbędzie w stanie odłączonym. Z tego miejsca musisz ręcznie usunąć stare Topici utworzyć nowe odniesienie do gałęzi w nowej gałęzi utworzonej przez rebase.

Użyłem mieszanki opisanych powyżej rozwiązań:

$ git branch temp <specific sha1>
$ git rebase --onto temp master topic
$ git branch -d temp

O wiele łatwiej było mi to przeczytać i zrozumieć. Przyjęte rozwiązanie doprowadziło mnie do konfliktu scalania (zbyt leniwego, by naprawić go ręcznie):

$ git rebase temp
First, rewinding head to replay your work on top of it...
Applying: <git comment>
Using index info to reconstruct a base tree...
M       pom.xml
.git/rebase-apply/patch:10: trailing whitespace.
    <some code>
.git/rebase-apply/patch:17: trailing whitespace.
        <some other code>
warning: 2 lines add whitespace errors.
Falling back to patching base and 3-way merge...
Auto-merging pom.xml
CONFLICT (content): Merge conflict in pom.xml
error: Failed to merge in the changes.
Patch failed at 0001 <git comment>
The copy of the patch that failed is found in: .git/rebase-apply/patch

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".

Ponieważ zmiana bazy jest tak fundamentalna, oto rozwinięcie odpowiedzi Nestora Milyaeva . Łącząc JSZ użytkownika i Simon Południowej komentarze z odpowiedzią Adama Dymitruk za daje tej komendy, który pracuje na topicoddziale, niezależnie od tego, czy gałązki z masteroddziału popełnić Aalbo C:

git checkout topic
git rebase --onto <commit-B> <pre-rebase-A-or-post-rebase-C-or-base-branch-name>

Zauważ, że ostatni argument jest wymagany (w przeciwnym razie przewija twoją gałąź do zatwierdzenia B).

Przykłady:

# if topic branches from master commit A:
git checkout topic
git rebase --onto <commit-B> <commit-A>

# if topic branches from master commit C:
git checkout topic
git rebase --onto <commit-B> <commit-C>

# regardless of whether topic branches from master commit A or C:
git checkout topic
git rebase --onto <commit-B> master

Więc ostatnie polecenie jest tym, którego zwykle używam.

Jest inny sposób, aby to zrobić lub jeśli chcesz wrócić do więcej niż jednego zatwierdzenia.

Oto przykład, aby wrócić do nliczby zatwierdzeń:

git branch topic master~n

Ze względu na to pytanie można to również zrobić:

git branch topic master~1

Polecenie działa idealnie na git version 2.7.4. Nie testowałem tego na żadnej innej wersji.