Chciałbym przenieść kilka ostatnich zatwierdzeń, które zobowiązałem się opanować do nowego oddziału i zabrać wzorca z powrotem, zanim te zatwierdzenia zostaną wykonane. Niestety mój Git-fu nie jest jeszcze wystarczająco silny, jakaś pomoc?

Tj. Jak mogę z tego wyjść

master A - B - C - D - E

do tego?

newbranch     C - D - E
             /
master A - B 

Przeprowadzka do istniejącego oddziału

Jeśli chcesz przenieść swoje commity do istniejącego oddziału , będzie to wyglądać następująco:

git checkout existingbranch
git merge master         # Bring the commits here
git checkout master
git reset --keep HEAD~3  # Move master back by 3 commits.
git checkout existingbranch

Ta --keepopcja zachowuje wszelkie niezatwierdzone zmiany, które możesz mieć w niepowiązanych plikach, lub przerywa, jeśli zmiany te musiałyby zostać zastąpione - podobnie jak to git checkoutrobi. Jeśli zostanie przerwane, git stashzmiany i spróbuj ponownie lub użyj, --hardaby je utracić (nawet z plików, które nie zmieniły się między zatwierdzeniami!)

Przeprowadzka do nowego oddziału

Ta metoda działa, tworząc nową gałąź za pomocą pierwszego polecenia ( git branch newbranch), ale nie przełączając się na nią. Następnie wycofujemy bieżącą gałąź (master) i przełączamy na nową gałąź, aby kontynuować pracę.

git branch newbranch      # Create a new branch, containing all current commits
git reset --keep HEAD~3   # Move master back by 3 commits (Make sure you know how many commits you need to go back)
git checkout newbranch    # Go to the new branch that still has the desired commits
# Warning: after this it's not safe to do a rebase in newbranch without extra care.

Ale upewnij się, ile cofnięć. Alternatywnie, zamiast HEAD~3, możesz po prostu podać hash zatwierdzenia (lub odnośnik podobny origin/master), do którego chcesz wrócić, np .:

git reset --keep a1b2c3d4

OSTRZEŻENIE: W przypadku wersji Git 2.0 i nowszych, jeśli później git rebasenowa gałąź w gałęzi oryginalnej ( master), może być potrzebna wyraźna --no-fork-pointopcja podczas bazy, aby uniknąć utraty zatwierdzeń przeniesionych z gałęzi głównej. Po branch.autosetuprebase alwaysustawieniu jest to bardziej prawdopodobne. Szczegółowe informacje można znaleźć w odpowiedzi Johna Mellora .

Dla tych, którzy zastanawiają się, dlaczego to działa (tak jak na początku byłem):

Chcesz wrócić do C i przenieść D i E do nowej gałęzi. Oto jak to wygląda na początku:

A-B-C-D-E (HEAD)
        ↑
      master

Po git branch newBranch:

    newBranch
        ↓
A-B-C-D-E (HEAD)
        ↑
      master

Po git reset --hard HEAD~2:

    newBranch
        ↓
A-B-C-D-E (HEAD)
    ↑
  master

Ponieważ gałąź jest tylko wskaźnikiem, master wskazał na ostatnie zatwierdzenie. Kiedy tworzysz newBranch , po prostu tworzysz nowy wskaźnik do ostatniego zatwierdzenia. Następnie za pomocą git resetprzesunąłeś główny wskaźnik z powrotem o dwa zatwierdzenia. Ale ponieważ nie przeniosłeś newBranch , nadal wskazuje na zatwierdzenie, które pierwotnie zrobił.

Ogólnie...

Metoda ujawniona przez sykora jest w tym przypadku najlepszą opcją. Ale czasem nie jest najłatwiejszy i nie jest to ogólna metoda. Do ogólnej metody użyj git cherry-pick :

Aby osiągnąć to, czego chce OP, jest to dwuetapowy proces:

Krok 1 - zanotuj, które zatwierdzenia od mistrza chcesz na newbranch

Wykonać

git checkout master
git log

Zwróć uwagę na skróty (powiedzmy 3) zatwierdzeń, które chcesz newbranch. Tutaj użyję:
C zatwierdzenia: 9aa1233
D zatwierdzenia: 453ac3d
E zatwierdzenia:612ecb3

Uwaga: Możesz użyć pierwszych siedmiu znaków lub całego skrótu zatwierdzenia

Krok 2 - Włóż je do newbranch

git checkout newbranch
git cherry-pick 612ecb3
git cherry-pick 453ac3d
git cherry-pick 9aa1233

LUB (w Git 1.7.2+ użyj zakresów)

git checkout newbranch
git cherry-pick 612ecb3~1..9aa1233

git cherry-pick stosuje te trzy zmiany do newbranch.

Jeszcze inny sposób, aby to zrobić, używając tylko 2 poleceń. Utrzymuje również bieżące drzewo robocze nietknięte.

git checkout -b newbranch # switch to a new branch
git branch -f master HEAD~3 # make master point to some older commit

Stara wersja - zanim się dowiedziałamgit branch -f

git checkout -b newbranch # switch to a new branch
git push . +HEAD~3:master # make master point to some older commit 

Będąc w stanie pushna .to miły podstęp wiedzieć.

Większość poprzednich odpowiedzi jest niebezpiecznie błędna!

Nie rób tego:

git branch -t newbranch
git reset --hard HEAD~3
git checkout newbranch

Gdy następnym razem uruchomisz git rebase(lub git pull --rebase) te 3 zatwierdzenia zostaną po cichu odrzucone newbranch! (patrz wyjaśnienie poniżej)

Zamiast tego zrób to:

git reset --keep HEAD~3
git checkout -t -b newbranch
git cherry-pick ..HEAD@{2}

• Najpierw odrzuca 3 ostatnie zatwierdzenia ( --keepjest jak --hard, ale bezpieczniejsze, bo zawiedzie, zamiast odrzucać niezaangażowane zmiany).
• Potem rozwidla się newbranch.
• Następnie wiśnia wybiera te 3 zmiany z powrotem na newbranch. Skoro jesteśmy już nie odwołuje się oddział, to robi to za pomocą git za reflog : HEAD@{2}jest popełnić, że HEADodnosi się do 2 operacje temu, czyli zanim 1. wyrejestrowany newbranchi 2. używane git resetaby odrzucić 3 zobowiązuje.

Ostrzeżenie: reflog jest domyślnie włączony, ale jeśli go ręcznie wyłączyłeś (np. Używając „gołego” repozytorium git), nie będziesz mógł odzyskać 3 zatwierdzeń po uruchomieniu git reset --keep HEAD~3.

Alternatywą, która nie polega na logowaniu jest:

# newbranch will omit the 3 most recent commits.
git checkout -b newbranch HEAD~3
git branch --set-upstream-to=oldbranch
# Cherry-picks the extra commits from oldbranch.
git cherry-pick ..oldbranch
# Discards the 3 most recent commits from oldbranch.
git branch --force oldbranch oldbranch~3

(jeśli wolisz, możesz pisać @{-1}- gałąź wcześniej wypisana - zamiast oldbranch).

Wyjaśnienie techniczne

Po co git rebaseodrzucać 3 zatwierdzenia po pierwszym przykładzie? To dlatego, że git rebasebez argumentów włącza --fork-pointdomyślnie opcję, która używa lokalnego reflogu, aby spróbować być odpornym na wymuszanie wypychania gałęzi upstream.

Załóżmy, że rozgałęziłeś początek / wzorzec, gdy zawierał zatwierdzenia M1, M2, M3, a następnie sam dokonałeś trzech zatwierdzeń:

M1--M2--M3  <-- origin/master
         \
          T1--T2--T3  <-- topic

ale potem ktoś przepisuje historię, zmuszając źródło / master do usunięcia M2:

M1--M3'  <-- origin/master
 \
  M2--M3--T1--T2--T3  <-- topic

Korzystając z lokalnego dziennika, git rebasemożesz zobaczyć, że rozwidliłeś się z wcześniejszej inkarnacji gałęzi origin / master, a zatem, że zatwierdzenia M2 i M3 tak naprawdę nie są częścią twojej gałęzi tematów. Stąd rozsądnie zakłada się, że skoro M2 zostało usunięte z gałęzi upstream, nie będzie już potrzebne w gałęzi tematu, gdy gałąź tematu zostanie ponownie wydana:

M1--M3'  <-- origin/master
     \
      T1'--T2'--T3'  <-- topic (rebased)

Takie zachowanie ma sens i ogólnie jest właściwą rzeczą do zrobienia podczas bazowania.

Dlatego przyczyną niepowodzenia następujących poleceń:

git branch -t newbranch
git reset --hard HEAD~3
git checkout newbranch

to dlatego, że pozostawiają rejestr w złym stanie. Git widzi, newbranchże rozwidlił gałąź odgałęzienia w wersji, która zawiera 3 zatwierdzenia, a następnie reset --hardprzepisuje historię pobierania w górę, aby usunąć zatwierdzenia, a więc następnym razem, gdy git rebasego uruchomisz , odrzuca je jak każde inne zatwierdzenie, które zostało usunięte z pobierania.

Ale w tym konkretnym przypadku chcemy, aby te 3 zatwierdzenia były traktowane jako część gałęzi tematu. Aby to osiągnąć, musimy oddzielić się od poprzedniej wersji, która nie obejmuje 3 zatwierdzeń. To właśnie robią moje sugerowane rozwiązania, dlatego oba pozostawiają rejestr w prawidłowym stanie.

Aby uzyskać więcej informacji, zobacz definicję --fork-pointw dokumentacji git rebase i git merge-base .

Znacznie prostsze rozwiązanie za pomocą git stash

Oto o wiele prostsze rozwiązanie dla zatwierdzeń do niewłaściwej gałęzi. Począwszy od gałęzi, masterktóra ma trzy błędne zatwierdzenia:

git reset HEAD~3
git stash
git checkout newbranch
git stash pop

Kiedy tego użyć?

• Jeśli Twoim głównym celem jest wycofanie master
• Chcesz zachować zmiany plików
• Nie przejmujesz się wiadomościami w błędnych zatwierdzeniach
• Jeszcze nie naciskałeś
• Chcesz, aby było to łatwe do zapamiętania
• Nie chcesz komplikacji, takich jak tymczasowe / nowe gałęzie, wyszukiwanie i kopiowanie skrótów zatwierdzeń oraz inne problemy

Co to robi, według numeru linii

1. Cofa ostatnie trzy zatwierdzenia (i ich wiadomości) do master , ale pozostawia wszystkie działające pliki nietknięte
2. Ukrywa wszystkie działające zmiany plików, czyniąc master drzewo robocze jest dokładnie równe stanowi HEAD ~ 3
3. Przełącza do istniejącego oddziału newbranch
4. Stosuje ukryte zmiany w katalogu roboczym i usuwa skrytkę

Możesz teraz używać git addi git commitjak zwykle. Wszystkie nowe zmiany zostaną dodane donewbranch .

Czego to nie robi

• Nie pozostawia przypadkowych tymczasowych gałęzi zagracających twoje drzewo
• Nie chroni błędnych komunikatów zatwierdzeń, dlatego musisz dodać nowy komunikat zatwierdzenia do tego nowego zatwierdzenia
• Aktualizacja! Użyj strzałki w górę, aby przewijać bufor poleceń, aby ponownie zastosować wcześniejsze zatwierdzenie z komunikatem zatwierdzenia (dzięki @ARK)

Cele

OP stwierdził, że celem było „przywrócenie mistrza przed dokonaniem tych zobowiązań” bez utraty zmian, a to rozwiązanie to robi.

Robię to przynajmniej raz w tygodniu, kiedy przypadkowo dokonuję nowych zobowiązań masterzamiast develop. Zwykle mam tylko jedno zatwierdzenie wycofania, w którym to przypadku korzystamgit reset HEAD^ w linii 1 jest prostszym sposobem na wycofanie tylko jednego zatwierdzenia.

Nie rób tego, jeśli wprowadziłeś zmiany mistrza w górę

Ktoś inny mógł wyciągnąć te zmiany. Jeśli przepisujesz tylko swojego lokalnego mistrza, nie ma to wpływu, gdy zostanie on wypchnięty, ale przekazanie przepisanej historii współpracownikom może powodować problemy.

Nie „przenosi” ich w sensie technicznym, ale ma ten sam efekt:

A--B--C  (branch-foo)
 \    ^-- I wanted them here!
  \
   D--E--F--G  (branch-bar)
      ^--^--^-- Opps wrong branch!

While on branch-bar:
$ git reset --hard D # remember the SHAs for E, F, G (or E and G for a range)

A--B--C  (branch-foo)
 \
  \
   D-(E--F--G) detached
   ^-- (branch-bar)

Switch to branch-foo
$ git cherry-pick E..G

A--B--C--E'--F'--G' (branch-foo)
 \   E--F--G detached (This can be ignored)
  \ /
   D--H--I (branch-bar)

Now you won't need to worry about the detached branch because it is basically
like they are in the trash can waiting for the day it gets garbage collected.
Eventually some time in the far future it will look like:

A--B--C--E'--F'--G'--L--M--N--... (branch-foo)
 \
  \
   D--H--I--J--K--.... (branch-bar)

Aby to zrobić bez przepisywania historii (tj. Jeśli już wypchnąłeś zatwierdzenia):

git checkout master
git revert <commitID(s)>
git checkout -b new-branch
git cherry-pick <commitID(s)>

Obie gałęzie można następnie pchać bez użycia siły!

Miałem właśnie taką sytuację:

Branch one: A B C D E F     J   L M  
                       \ (Merge)
Branch two:             G I   K     N

Wykonałem:

git branch newbranch 
git reset --hard HEAD~8 
git checkout newbranch

Spodziewałem się, że zatwierdzę, będę Głową, ale zatwierdzę L, czy to teraz ...

Aby mieć pewność, że wylądujesz we właściwym miejscu w historii, łatwiej jest pracować z hashem zatwierdzenia

git branch newbranch 
git reset --hard #########
git checkout newbranch

Jak mogę z tego wyjść?

A - B - C - D - E 
                |
                master

do tego?

A - B - C - D - E 
    |           |
    master      newbranch

Z dwoma poleceniami

• git branch -m master newbranch

dający

A - B - C - D - E 
                |
                newbranch

i

• Git Branch Master B

dający

A - B - C - D - E
    |           |
    master      newbranch

Jeśli chcesz tylko przenieść wszystkie nieprzypisane zmiany do nowej gałęzi , musisz po prostu:

1. tworzyć się nowy oddział z bieżącej:git branch new-branch-name

2. pchnij swój nowy oddział :git push origin new-branch-name

3. przywrócić swoje stare (aktualne) oddział do ostatniej pchania / stan stabilnygit reset --hard origin/old-branch-name

Niektóre osoby mają też inne upstreams, niż originpowinny, powinny stosować odpowiednieupstream

1) Utwórz nową gałąź, która przeniesie wszystkie twoje zmiany do nowej_gałęzi.

git checkout -b new_branch

2) Następnie wróć do starej gałęzi.

git checkout master

3) Czy git rebase

git rebase -i <short-hash-of-B-commit>

4) Następnie otwarty edytor zawiera 3 ostatnie informacje o zatwierdzeniu.

...
pick <C's hash> C
pick <D's hash> D
pick <E's hash> E
...

5) Zmień pickna dropwszystkie te 3 zmiany. Następnie zapisz i zamknij edytor.

...
drop <C's hash> C
drop <D's hash> D
drop <E's hash> E
...

6) Teraz ostatnie 3 zatwierdzenia są usuwane z bieżącej gałęzi ( master). Teraz wciśnij gałąź mocno, ze +znakiem przed nazwą gałęzi.

git push origin +master

Możesz to zrobić, to tylko 3 prosty krok, którego użyłem.

1) Utwórz nowy oddział, w którym chcesz zatwierdzić ostatnią aktualizację.

git branch <branch name>

2) Znajdź identyfikator ostatniego zatwierdzenia dla zatwierdzenia w nowym oddziale.

git log

3) Skopiuj notatkę identyfikatora zatwierdzenia, że ​​lista najnowszych zatwierdzeń ma miejsce na górze. więc możesz znaleźć swoje zatwierdzenie. znajdziesz to również za pośrednictwem wiadomości.

git cherry-pick d34bcef232f6c...

możesz także podać numer identyfikacyjny zatwierdzenia.

git cherry-pick d34bcef...86d2aec

Teraz twoja praca skończona. Jeśli wybierzesz prawidłowy identyfikator i poprawną gałąź, odniesiesz sukces. Zanim to zrobisz, bądź ostrożny. w przeciwnym razie może wystąpić inny problem.

Teraz możesz wcisnąć kod

git push

Inny sposób to zrobić:

[1] Zmień nazwę mastergałęzi na newbranch(zakładając, że jesteś w mastergałęzi):

git branch -m newbranch

[2] Utwórz mastergałąź z zatwierdzenia, które chcesz:

git checkout -b master <seven_char_commit_id>

np. git checkout -b master a34bc22