Cofanie zmian w Git przy użyciu Bitbucket Cloud

W dalszej części samouczka, w ramach nauki sposobów cofania zmian, poznasz kilka innych poleceń git. Zaczynajmy.

Na początku utwórzmy unikatowe repozytorium zawierające cały kod z pierwotnego repozytorium. Proces ten nazywamy „podziałem repozytorium”. Podział jest rozbudowanym procesem git, który można zastosować, gdy udostępniane repozytorium jest hostowane w zewnętrznej usłudze hostingowej, takiej jak Bitbucket.

1. Kliknij łącze lub wpisz następujący adres URL: https://bitbucket.org/atlassian/tutorial-documentation-tests/commits/all

2. Kliknij symbol + na lewym pasku bocznym, a następnie wybierz opcję Fork this repository (Podziel to repozytorium), zapoznaj się z treścią okna dialogowego i kliknij opcję Fork repository (Podziel repozytorium).

3. Powinien pojawić się widok ogólny nowego repozytorium.

4. Kliknij symbol +, a następnie wybierz opcję Clone this repository (Klonuj to repozytorium).

5. Sklonuj repozytorium na komputerze.

6. Przejdź do katalogu zawierającego sklonowane repozytorium.

Teraz, gdy masz już repozytorium zawierające kod oraz dotychczasową historię w systemie lokalnym, możesz przystąpić do cofania niektórych zmian.

Musisz znaleźć zmianę, którą chcesz cofnąć, i odwołać się do niej. Można to zrobić, korzystając z funkcji przeglądania commitu w interfejsie użytkownika Bitbucket. Dostępnych jest kilka narzędzi wiersza polecenia, za pomocą których można zlokalizować konkretną zmianę.

Musisz znaleźć zmianę, którą chcesz cofnąć, i odwołać się do niej. Można to zrobić, korzystając z funkcji przeglądania commitu w interfejsie użytkownika Bitbucket. Dostępnych jest kilka narzędzi wiersza polecenia, za pomocą których można zlokalizować konkretną zmianę.

W tym przypadku wynik działania polecenia git status pokazuje nam, że wszystko jest zaktualizowane ze zdalną gałęzią main i nie ma żadnych zmian oczekujących na zatwierdzenie. W kolejnym przykładzie wprowadzimy pewne zmiany w repozytorium i przyjrzymy się mu w stanie oczekujących zmian. Oznacza to, że w plikach znajdujących się w repozytorium w systemie lokalnym wprowadzono zmiany, które nie zostały przygotowane (ani umieszczone w przechowalni) w celu dodania ich do historii projektu.

Aby zobaczyć ten kolejny przykład, najpierw otwórz plik myquote2.html. Wprowadź dowolne modyfikacji w zawartości pliku myquote2.html, a następnie zapisz go i zamknij. Wykonajmy raz jeszcze polecenie git status, aby przyjrzeć się repozytorium w tym stanie.

Wyświetlony w tym przypadku wynik wskazuje, że plik myquote2.html zawiera oczekujące modyfikacje. Dobre wieści! Jeśli, jak w powyższym przykładzie, zmiana, którą chcesz cofnąć, nie została jeszcze dodana do przechowalni, wystarczy edytować plik i kontynuować pracę. System Git zaczyna śledzić zmianę dopiero, gdy zostanie ona dodana do przechowalni, a następnie zatwierdzona w historii projektu.

Teraz „cofnijmy” zmiany wprowadzone w pliku myquote2.html. Jest to przykład uproszczony, a zmiany są minimalne, dlatego mamy do dyspozycji dwie metody cofania zmian. Jeśli wykonamy polecenie git checkout myquote2.html w repozytorium przywrócona zostanie poprzednio zatwierdzona wersja pliku myquote2.html. Możemy również wykonać polecenie git reset --hard, które spowoduje przywrócenie całego repozytorium do ostatniego commita.

Za pomocą polecenia git log można wyświetlić listę historii projektu, zastosować do niej filtr i wyszukać konkretne zmiany. Polecenie git status pozwala sprawdzić katalog roboczy i przechowalnię, natomiast polecenie git log jedynie wyświetla historię commitów.

Ten sam rejestr historii commitów można znaleźć w interfejsie użytkownika Bitbucket, przechodząc do widoku „commitów” repozytorium. Widok commitów dla naszego demonstracyjnego repozytorium można znaleźć pod adresem: https://bitbucket.org/dans9190/tutorial-documentation-tests/commits/all. Zawartość tego widoku będzie przypominać wynik użycia polecenia git log w narzędziu wiersza polecenia. Można wykorzystać to polecenie do wyszukiwania oraz identyfikacji commitów, które mają być cofnięte.

W poniższym przykładzie widać kilka elementów w historii, jednak każda zmiana jest w istocie commitem, który musimy znaleźć i cofnąć.

Przyjrzyjmy się nieco bliżej jednemu z commitów na liście:

Jak widać, każdy komunikat dotyczący commita składa się z czterech elementów:

Najprawdopodobniej zmiana, którą chcesz cofnąć, będzie znajdowała się gdzieś wcześniej w historii projektu, która może być dość rozbudowana. Nauczmy się zatem kilku podstawowych operacji z użyciem polecenia git log, które pozwolą wyszukać konkretną zmianę.

1. Otwórz okno terminala i za pomocą polecenia cd (zmień katalog) przejdź do najwyższego poziomu lokalnego repozytorium.

Wprowadź polecenie got log --oneline. Dodanie opcji --oneline spowoduje wyświetlenie każdego commita w jednym wierszu, dzięki czemu można przeglądać w terminalu większy fragment historii.

W dowolnej chwili możesz nacisnąć klawisz q, aby zamknąć dziennik commitów i powrócić do wiersza polecenia.

Powinna się pojawić podobna zawartość jak w poniższym przykładzie:

2. Naciśnij klawisz q, aby powrócić do wiersza polecenia.

3. Zlokalizuj commit z hashem c5826da i komunikatem more changes na liście wygenerowanej po wykonaniu polecenia git log. Ktoś nie dodał opisowego komunikatu dotyczącego commita, więc będziemy musieli się dowiedzieć, czy zawiera on zmiany, o które nam chodzi.

4. Zaznacz i skopiuj hash commita c5826da z wyniku polecenia git log w oknie terminala.

5. Wpisz git show, a następnie wklej lub przepisz skopiowany hash commita i naciśnij klawisz Enter. Widok powinien być mniej więcej następujący:

Wiersz u dołu będzie wypełniał się treścią, aż wyświetlona zostanie cała zmiana. Naciśnij klawisz q, aby powrócić do wiersza polecenia.

W bardzo dużym skrócie omówiliśmy polecenie git log. Jeśli podoba Ci się praca w wierszu polecenia, prawdopodobnie zechcesz zapoznać się z zaawansowanym samouczkiem dotyczącym polecenia git log.

1. W oknie terminala wprowadź polecenie git log --oneline.

2. Skopiuj hash drugiego commita w dzienniku: 52f823c, a następnie naciśnij klawisz q, aby zamknąć dziennik.

3. W oknie terminala wprowadź polecenie git reset --soft 52f823c. Jeśli wszystko przebiegło pomyślnie, to polecenie powinno zostać uruchomione w tle. To wszystko. Właśnie udało Ci się cofnąć swoją pierwszą zmianę. Przyjrzyjmy się teraz rezultatowi tej czynności.

4. W oknie terminala wprowadź polecenie git status. Zobaczysz, że commit został cofnięty i funkcjonuje teraz jako niezatwierdzona zmiana. Powinno to wyglądać mniej więcej tak:

5. W oknie terminala wprowadź polecenie git log --oneline. Widok powinien być mniej więcej następujący:

6. Widać, że nowy wskaźnik HEAD gałęzi to commit 52f823c, czyli dokładnie to, o co nam chodziło.

7. Naciśnij klawisz q, aby zamknąć dziennik. Nie zamykaj jeszcze terminala. Wiesz już, jak wykonać prosty reset, dlatego teraz spróbujemy czegoś nieco bardziej złożonego.

1. Wprowadź polecenie git log --online.

2. Skopiuj hash commita 1a6a403 (myquote edited online with Bitbucket), czyli commita znajdującego się tuż pod pull requestem nr 6, gdyż to on zawiera zmiany, które chcemy cofnąć.

3. W oknie terminala wprowadź polecenie git reset 1a6a403. Powinien się pojawić mniej więcej następujący widok:

Jak widać, zmiany mają teraz stan niezatwierdzony. Oznacza to, że usunęliśmy kilka zmian zarówno z historii projektu, jak i z przechowalni.

4. W oknie terminala wprowadź polecenie git status. Powinien się pojawić mniej więcej następujący widok:

Widać teraz, że system git w ogóle nie śledzi pierwszej cofniętej zmiany (w pliku bitbucket-pipelines.yml). Stało się tak dlatego, że polecenie git reset usuwa zmianę zarówno ze wskaźnika HEAD gałęzi, jak i z obszaru śledzenia lub indeksu systemu git. Proces, jaki realizuje to polecenie, jest nieco zbyt złożony, abyśmy mogli go tutaj omówić. Więcej informacji na ten temat można przeczytać w opisie polecenia git reset.

5. W oknie terminala wprowadź polecenie git log --oneline.

Na liście dziennika widać teraz, że historia commitów również została zmodyfikowana i rozpoczyna się od commita 1a6a403. Na potrzeby niniejszej demonstracji oraz kolejnego przykładu przyjmijmy, że chcemy teraz cofnąć reset, który wykonaliśmy przed chwilą. Być może po dłuższym namyśle doszliśmy do wniosku, że chcemy zatrzymać zawartość pull requestu nr 6.

Polecenia git reset są jedną z kilku metod „cofania”, jakie oferuje system Git. Resety uważa się zasadniczo za „niezbyt bezpieczną” opcję cofania zmian. Sprawdzają się one dobrze podczas pracy w środowisku lokalnym nad wyizolowanym kodem, ale w przypadku współdzielenia pracy z innymi członkami zespołu ich użycie może być ryzykowne.

Aby udostępnić zresetowaną gałąź zdalnemu zespołowi, trzeba wykonać „wymuszone wypchnięcie”. „Wymuszone wypchnięcie” inicjuje się za pomocą polecenia git push -f. Wymuszone wypchnięcie spowoduje zniszczenie całej historii gałęzi utworzonej po wypchnięciu.

Oto przykład tego „niebezpiecznego” scenariusza:

• Programista A pracuje na gałęzi, tworząc nową funkcję.
• Programista B pracuje na tej samej gałęzi, tworząc odrębną funkcję.
• Programista B decyduje się zresetować gałąź do wcześniejszego stanu z okresu, zanim programiści A i B przystąpili do pracy.
• Programista B wymusza wypchnięcie zresetowanej gałęzi do zdalnego repozytorium.
• Programista A pobiera gałąź, aby otrzymać wszelkie aktualizacje. W trakcie tego pobrania programista A otrzymuje wymuszoną aktualizację. W efekcie lokalna gałąź programisty A zostaje przywrócona do stanu sprzed wykonania przez obu programistów jakichkolwiek prac, przez co traci on swoje commity.

Po użyciu polecenia git reflog powinien się pojawić widok zbliżony do powyższego. Można w nim prześledzić historię czynności w repozytorium. Górny wiersz zawiera odniesienie do resetu wykonanego w celu zresetowania pull requestu nr 6. Zresetujmy zatem teraz ten reset, aby przywrócić pull request nr 6. W drugiej kolumnie tego widoku dziennika reflog znajduje się element odnoszący się do czynności modyfikacji wykonanej w repozytorium. W tym przypadku HEAD@{0} jest odniesieniem do uprzednio wykonanego polecenia resetowania. Nie chcemy powtarzać tego polecenia resetu, dlatego przywrócimy repozytorium do stanu HEAD@{1}.

Przeanalizujmy teraz historię commitów w repozytorium za pomocą polecenia git log --oneline:

Na liście dziennika widać teraz, że historia commitów również została zmodyfikowana i rozpoczyna się od commita 1a6a403. Na potrzeby niniejszej demonstracji oraz kolejnego przykładu przyjmijmy, że chcemy teraz cofnąć reset, który wykonaliśmy przed chwilą. Być może po dłuższym namyśle doszliśmy do wniosku, że chcemy zatrzymać zawartość pull requestu nr 6.

Do zaprezentowania procedury wybierzmy na przykład ostatni commit 1f08a70. Na potrzeby niniejszego scenariusza załóżmy, że chcemy cofnąć zmiany wprowadzone w tym commicie. Wykonaj polecenie:

Spowoduje ono uruchomienie przepływu pracy git merge. System Git utworzy nowy commit, którego zawartość będzie odwrotnością commita wskazanego do przywrócenia. Następnie system Git otworzy skonfigurowany edytor tekstu wraz z monitem o wprowadzenie komunikatu dotyczącego nowego commita. Z uwagi na ten przepływ pracy związany z commitem, przywracanie uznaje się za bezpieczniejszą opcję cofania zmian. Utworzenie odwrotnego commita pozostawia wyraźny ślad w historii commitów, wskazując jednoznacznie, kiedy operacja cofnięcia została wykonana.

Gratulacje! Udało Ci się. Możesz w dowolnej chwili powrócić do tego samouczka lub przejść do sekcji Cofanie zmian, aby dowiedzieć się więcej. Życzymy owocnej pracy w Bitbucket!