Jak mogę przekazać określone zatwierdzenie do zdalnego, a nie poprzednich zatwierdzeń?

826

Dokonałem kilku zatwierdzeń dla różnych plików, ale do tej pory chciałbym wypchnąć do mojego zdalnego repozytorium tylko konkretne zatwierdzenie.

Czy to jest możliwe?

git commit push

— Robert23
źródło

6

możliwy duplikat git: wciśnij jeden zatwierdzenie

— użytkownik151019

Zobacz dobrą technikę tutaj: stackoverflow.com/a/1789142/1579667

— Benj

1086

Push up przez danego popełnienia, można napisać:

git push <remotename> <commit SHA>:<remotebranchname>

pod warunkiem, że <remotebranchname>już istnieje na pilocie. (Jeśli nie, możesz użyć go git push <remotename> <commit SHA>:refs/heads/<remotebranchname>do automatycznego utworzenia).

Jeśli chcesz wypchnąć zatwierdzenie bez wypychania poprzednich zatwierdzeń, powinieneś najpierw użyć git rebase -ido ponownego zamówienia zatwierdzeń.

— Geoff Reedy
źródło

66

git push <remotename> <commit SHA>:<remotebranchname>Pracuje. sztuką jest połączenie go z, git rebase -iaby przenieść zatwierdzenie, które chcesz jako pierwsze zatwierdzenie, i określić, że commit-sha

— dminer

29

kolejną dobrą wskazówką jest upewnienie się, że skopiujesz SHA zatwierdzenia, które chcesz wypchnąć po wykonaniu tej zmiany bazy -i, a nie wcześniej, jak właśnie to zrobiłem :)

— estan

33

Pamiętaj, że to się nie powiedzie, jeśli gałąź zdalna jeszcze nie istnieje. Utworzenie gałęzi można wykonać za pomocą git push <remotename> <commit SHA>:refs/heads/<new remote branch name>. Następnie naciśnij przycisk zgodnie z opisem w odpowiedzi.

— Wes Oldenbeuving

31

Na przykład, aby wypchnąć wszystko oprócz ostatniego zatwierdzenia z pewnymi standardowymi nazwami git push origin HEAD~1:master.

— bezgłośny hałas

3

Zauważ też, że jeśli już wypchnąłeś później SHA do tej zdalnej gałęzi, musisz wymusić wypchnięcie tego. Użyj -fflagi.

— Ian Vaughan

79

Innych odpowiedzi brakuje w opisach zmiany kolejności.

git push <remotename> <commit SHA>:<remotebranchname>

wypchnie pojedynczy zatwierdzenie, ale to zatwierdzenie musi być NAJSTARSZE z twojego lokalnego, niezepchniętego, zatwierdzenia, nie należy mylić go z górnym, pierwszym lub tip tip, które są moim zdaniem niejednoznacznymi opisami. Zatwierdzenie musi być zgodne z najstarszym z zatwierdzeń, tj. Najdalszym od ostatniego zatwierdzenia. Jeśli nie jest to najstarsze zatwierdzenie, wówczas wszystkie zatwierdzenia od najstarszej, lokalnej, niepopchniętej SHA do określonej SHA zostaną wypchnięte. Aby zmienić kolejność zatwierdzeń, użyj:

git rebase -i HEAD~xxx

Po zmianie kolejności zatwierdzenia możesz bezpiecznie wepchnąć ją do zdalnego repozytorium.

Podsumowując, użyłem

git rebase -i HEAD~<number of commits to SHA>
git push origin <post-rebase SHA>:master

wcisnąć jeden zatwierdzenie do mojej zdalnej gałęzi master.

Bibliografia:

Zobacz też:

— Samuel
źródło

3

Wydaje się, że niektóre pochodzenie może na to nie pozwolić. Na przykład w GitLab widzę „Nie możesz wymuszać kodu push do chronionej gałęzi w tym projekcie.”. Co jest trochę dziwne, ponieważ nie sądziłem, że coś wymuszam, po prostu robię normalny nacisk. Masz pomysł, jak to zrobić bez „zmuszania”?

— Ed Avis

1

@Ed Shoud nie musi wymuszać push. Wygląda na to, że masz problem z konkretną konfiguracją git. Być może dokonałeś wypłaty za zdalne zatwierdzenie HEAD? Nie wiem, czym jest chroniona gałąź, brzmi jak problem z pozwoleniem.

— Samuel

1

Samuel - to miałoby sens, ale git rebase -i pokazuje tylko lokalne zatwierdzenia, które są późniejsze niż zdalny HEAD, więc nie wiem, jak mogłem to zrobić.

— Ed Avis

1

Samuel - rzeczywiście mogę teraz wykonywać częściowe wypychania, więc nie wiem, co poszło nie tak, ale musiało to być próbowanie wypchnięcia zatwierdzenia nie pochodzącego ze zdalnej HEAD w taki czy inny sposób.

— Ed Avis

1

@Ed Powiedziałeś: „git rebase -i pokazuje tylko lokalne zatwierdzenia, które są późniejsze niż zdalny HEAD”, nie sądzę, że to prawda. Przetestowałem i byłem w stanie dokonać bazowania poza zdalnym HEAD.

— Samuel

25

Sugerowałbym użycie git rebase -i; przenieś zatwierdzenie, które chcesz wypchnąć na szczyt zatwierdzonych zmian. Następnie użyj, git logaby uzyskać SHA ponownego zatwierdzenia, sprawdź go i wciśnij. Rebase zapewni, że wszystkie twoje zatwierdzenia będą teraz dziećmi tego, którego wypchnąłeś, więc przyszłe wypychania również będą działały dobrze.

— Walter Mundt
źródło

3

Czy mógłbyś podać ruch kompletny przykład esp. jest git logkrok?

— Drux,

4

Załóżmy, że masz 3 względnie niezależne zatwierdzenia z komunikatami „A”, „B”, „C” popełnionymi w tej kolejności i chcesz wcisnąć „B”. „git rebase -i” powinien dostarczyć ci i redaktora listę wszystkich trzech; przesuń B w górę i zapisz / wyjdź. 'git log --pretty = oneline -n3' wyświetli B, A, C z skrótami przed każdą wiadomością, a B jest teraz ostatni. 'git checkout -b temp $ hash_of_B; git push ”powinien w tym momencie nacisnąć B. Prawdopodobnie zechcesz wtedy „git checkout -b master; git branch -d temp ', aby wrócić do poprzedniego stanu, zakładając, że byłeś w lokalnym oddziale głównym; wymienić odpowiednio.

— Walter Mundt,

1

+1 Czy kiedykolwiek spotkałeś się z „gniewem bogów gitów ” po rebase-push-rebase? (Czy to możliwe, że stanie się to również przez przypadek, prawda?)

— Drux,

2

Jeśli dokładnie przeczytasz moją odpowiedź, zobaczysz, że wypychanie następuje tylko po zmianie bazy, a zatwierdzenie zmiany bazy jest przenoszone tylko powyżej innych zatwierdzeń, które nie zostały jeszcze wypchnięte. Po wciśnięciu zatwierdzenia, ogólnie należy go uznać za osadzony w kamieniu; zostaw to w spokoju w przyszłości. Ta technika służy tylko do uporządkowania wielu lokalnych zmian w dobrym porządku przed ich wypchnięciem. Jeśli masz poprawnie skonfigurowane śledzenie, 'git rebase -i' bez żadnych innych argumentów domyślnie nie pokazuje nawet wypychania zatwierdzeń, więc jest bezpieczniejszy od wypadków niż niektóre inne metody.

— Walter Mundt

21

Cherry-pick działa najlepiej w porównaniu ze wszystkimi innymi metodami, jednocześnie wypychając określone zatwierdzenie.

Sposobem na to jest:

Utwórz nowy oddział -

git branch <new-branch>

Zaktualizuj swoją nową gałąź o gałąź pochodzenia -

git fetch

git rebase

Te działania zapewnią, że masz dokładnie te same rzeczy, co twoje pochodzenie.

Wybierz to sha id, co chcesz zrobić push -

git cherry-pick <sha id of the commit>

Możesz uzyskać sha id, uruchamiając

git log

Przekaż to do swojego pochodzenia -

git push

Uruchom, gitkaby zobaczyć, że wszystko wygląda tak, jak chcesz.

— David
źródło

2

Korzystanie git rebase -ibędzie idealnym rozwiązaniem, jak sugerowano w powyższych rozwiązaniach. Wybrania wiśniowego można używać tylko wtedy, gdy chcesz powielić zatwierdzenie.

— Vinay Bhargav

13

Uważam, że musiałbyś „przywrócić” do tego zatwierdzenia, a następnie go wcisnąć. Lub możesz cherry-pickzatwierdzić do nowej gałęzi i wypchnąć ją do gałęzi w zdalnym repozytorium. Coś jak:

git branch onecommit
git checkout onecommit
git cherry-pick 7300a6130d9447e18a931e898b64eefedea19544 # From the other branch
git push origin {branch}

— Josh K.
źródło

9

git revert jest tutaj złym pomysłem - tworzy nowe zatwierdzenie

— hasen

1

@hasen: Możesz wtedy tylko cherry-pickzatwierdzenie, które chcesz.

— Josh K

4

zarówno revert, jak i cherry-pick to złe pomysły. git rebase -i jest tutaj twoim przyjacielem, zobacz odpowiedź Waltera Mundta poniżej.

— Nicolas C

3

@Nicolas, dlaczego wybranie cherry jest złym pomysłem?

— Antoine

3

@Antoine, zazwyczaj chcesz, aby Twój oddział był zsynchronizowany z tym, który śledzi na początku. Jeśli wybierzesz opcję „kopiuj / wklej”, w pewnym momencie będziesz musiał poradzić sobie z nieprzesuniętą kopią. W przypadku zmiany bazy -i wykonujesz „wycinanie i wklejanie” i synchronizowanie gałęzi z pilotem do miejsca, w którym chcesz.

— Nicolas C,

0

Możesz również w innym katalogu:

git clone [twoje repozytorium]
Zastąp katalog .git w oryginalnym repozytorium katalogiem .git repozytorium, które właśnie sklonowałeś.
git dodaj i git zatwierdź swój oryginał

— NunoSempere
źródło