2012-06-27 15 views
38

Gram z git (nadal bardzo noob) i chciałem poznać różnicę między "reset" i "rebase". Czy ten jest mocniejszy od drugiego?Jaka jest różnica między "reset git" a "git rebase"?

Powiedz, że chciałem usunąć pogrubione 3 zatwierdzenia z historii, którego lepiej użyć, czy też powinienem je oznaczyć, a następnie usunąć przy pomocy git tag -d <tagname>?

17a64df 2012-06-21 | Witam używa style.css (HEAD, origin/style, master),
a6792e4 2012-06-21 | Dodano arkusz stylów CSS
801e13e 2012-06-21 | Dodano README
5854339 2012-06-21 | Dodano indeks.html
0b1dd4c 2012-06-21 | Przeniesiono plik hello.html do biblioteki
55649c3 2012-06-21 | Dodaj autora/komentarz e-mail
9b2f3ce 2012-06-21 | Dodano komentarz autora
cdb39b0 2012-06-21 | Zatwierdź p tagi z tekstem (v1.1)
b7b5fce 2012-06-21 | To przywraca commit a6faf60631b5fbc6ee79b52a1bdac4c971b69ef8.
a6faf60 2012-06-21 | Przywróć "Ups, nie chcieliśmy tego zatwierdzenia"
a006669 2012-06-21 | Ups, nie chcieliśmy tego zatwierdzenia
262d1f7 2012-06-21 | Dodano nagłówek HTML (v1)
b1846e5 2012-06-21 | Dodano standardowe znaczniki strony HTML (v1-beta)
bf1131e 2012-06-21 | Dodano HI TAG
02b86d0 2012-06-21 | Pierwszy Commit

Odpowiedz

43

Są zupełnie inne. git-reset działa z odwołaniami, w katalogu roboczym i indeksie bez dotykania jakichkolwiek obiektów commit (lub innych obiektów). git-rebase z drugiej strony służy do przepisywania wcześniej wykonanych obiektów commit.

Więc jeśli chcesz przepisać historię, git-rebase jest tym, czego potrzebujesz. Zauważ, że powinieneś nigdy przepisać historię, która została pchnięta i była dostępna dla kogoś innego, ponieważ ponowne zapisywanie przepisuje obiekty, czyniąc je niekompatybilnymi ze starymi obiektami, powodując bałagan dla wszystkich zaangażowanych osób.

W związku z tym, co chcesz zrobić, to interactive rebasing. Powołać się go za pomocą git rebase -i 262d1f7 i powinieneś dostać wiersz wygląda tak:

pick 262d1f7 Added HTML header (v1) 
pick a006669 Oops, we didn't want this commit 
pick a6faf60 Revert "Oops, we didn't want this commit" 
pick b7b5fce This reverts commit a6faf60631b5fbc6ee79b52a1bdac4c971b69ef8. 
pick cdb39b0 Commit p tags with text (v1.1) 
pick 9b2f3ce Added an author comment 
pick 55649c3 Add an author/email comment 
pick 0b1dd4c Moved hello.html to lib 
pick 5854339 Added index.html 
pick 801e13e Added README 
pick a6792e4 Added css stylesheet 
pick 17a64df Hello uses style.css (HEAD, origin/style, master), 

Tam po prostu usunąć linie do zatwierdzeń, które chcesz usunąć, zapisać i opuścić edytor i Git będzie przepisać historię. Ponownie, nie rób tego, jeśli już wprowadziłeś zmiany. Ogólnie rzecz biorąc posiadanie takich zobowiązań w historii jest całkowicie w porządku.

+0

Dzięki za odpowiedź i wyjaśnienie, jakie są różnice. – Q10

+0

usuwa linie z rebase tak samo jak zmienia słowo "pick" na "s" dla squasha? – Ninjaxor

+4

@Ninjaxor Nie, usunięcie linii spowoduje całkowite usunięcie zatwierdzeń i zmian wprowadzonych przez historię. To tak, jakby nigdy nie popełniono zobowiązania. Na przykład, jeśli usuniesz commit dodający linię, linia ta nie pojawi się w żadnym późniejszym zatwierdzeniu po podziale. Z drugiej strony, squashowanie zachowa zmiany wprowadzone w zatwierdzeniu, a jedynie pozbędzie się tego osobnego zatwierdzenia. – poke

8

Chociaż nie porównuje różnic między tymi dwoma, here's doskonały artykuł wyjaśniający rebase, który jest łatwy do zrozumienia.

+1

URL jest teraz http://www.jarrodspillers.com/git/2009/08/19/git-merge-vs-git-rebase-avoiding-rebase-hell.html – AnneTheAgile

+1

Ten artykuł mówi, że jedyną korzyścią jest mniejsze łączenie zatwierdza, a pozostałe zatwierdzenia łączenia są bardziej znaczące. To nie wydaje się warte ryzyka. Czy są jakieś inne zalety? –

+0

Ten artykuł był bardzo pomocny. Najlepsze wyjaśnienie, które do tej pory widziałem w Internecie. –

Powiązane problemy