Git Status: sprawdzanie repozytorium

git status

Polecenie git status wyświetla stan katalogu roboczego i przechowalni. Pozwala zobaczyć, które zmiany zostały zapisane w przechowalni, a które nie, a także które pliki nie są śledzone przez system Git. Dane wyjściowe stanu nie zawierają informacji na temat historii commitów. Do tego należy użyć polecenia git log.

Powiązane polecenia git

git tag
- Tagi to odwołania wskazujące określone punkty w historii Git. Polecenia git tag zwykle służy do oznaczenia punktu w historii stanowiącego podstawę opublikowanej wersji (np. v1.0.1).
git blame
- Wysokopoziomową funkcją git blame jest wyświetlanie metadanych autora dołączonych do określonych zatwierdzonych wierszy w pliku. Umożliwia przejrzenie historii określonego kodu i znalezienie odpowiedzi na pytania: jaki kod został dodany do repozytorium, dlaczego i w jaki sposób.
git log
- Polecenie git log wyświetla zatwierdzone migawki. Pozwala wyświetlić historię projektu, zastosować do niej filtr i wyszukać konkretne zmiany.

Użycie

git status

Wyświetla listę plików zapisanych i niezapisanych w przechowalni oraz nieśledzonych.

Omówienie

Działanie polecenia git status jest stosunkowo proste. Pokazuje efekty działania git add i git commit. Komunikaty o stanie zawierają również odpowiednie instrukcje dotyczące zapisania/wycofania plików z przechowalni. Przykładowy wynik przedstawiający trzy główne kategorie wywołania git status wygląda następująco:

# On branch main
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
#modified: hello.py
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
#modified: main.py
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
#hello.pyc

Ignorowanie plików

Nieśledzone pliki zazwyczaj dzielą się na dwie kategorie. To jeszcze niezatwierdzone pliki niedawno dodane do projektu albo skompilowane pliki binarne takie jak .pyc, .obj, .exe itp. Uwzględnianie tych pierwszych w wynikach polecenia git status jest zdecydowanie korzystne, lecz te drugie mogą utrudnić zorientowanie się, co właściwie się dzieje w repozytorium.

Z tego względu Git pozwala całkowicie ignorować niektóre pliki, umieszczając ich ścieżki w specjalnym pliku o nazwie .gitignore. Pliki do zignorowania należy umieścić w osobnych wierszach. Można także użyć symbolu * jako symbolu wieloznacznego. Na przykład dodanie poniższej informacji do pliku .gitignore w katalogu głównym projektu zapobiegnie pojawianiu się skompilowanych modułów Pythona w wynikach polecenia git status:

*.pyc

Przykład

Dobrą praktyką jest sprawdzanie stanu repozytorium przed wprowadzeniem zmian, aby przypadkiem nie zatwierdzić czegoś niepożądanego. Poniższy przykład pokazuje stan repozytorium przed zapisaniem w przechowalni i zatwierdzeniem migawki oraz po wykonaniu tych czynności:

# Edit hello.py
git status
# hello.py is listed under "Changes not staged for commit"
git add hello.py
git status
# hello.py is listed under "Changes to be committed"
git commit
git status
# nothing to commit (working directory clean)

Pierwszy wynik przedstawi plik jako niezapisany w przechowalni. Użycie git add zostanie odzwierciedlone w drugim wyniku git status, a w końcowym pojawi się informacja, że nie ma nic do zatwierdzenia — katalog roboczy będący zbieżnym z ostatnim commitem. Niektóre polecenia systemu Git (np. git merge) wymagają uporządkowanego katalogu roboczego, aby by nie doszło do przypadkowego nadpisania zmian.

git log

Polecenie git log wyświetla zatwierdzone migawki. Pozwala wyświetlić historię projektu, zastosować do niej filtr i wyszukać konkretne zmiany. Polecenie git status umożliwia sprawdzenie katalogu roboczego i przechowalni, natomiast git log jedynie wyświetla historię commitów.

Dane wyjściowe dziennika można spersonalizować na kilka sposobów: od zwykłego filtrowania commitów do wyświetlania ich w całkowicie zdefiniowanym przez użytkownika formacie. Poniżej przedstawiamy niektóre z najpopularniejszych konfiguracji git log.

Użycie

git log

Wyświetla całą historię commitu zgodnie z domyślnym formatowaniem. Jeśli dane wyjściowe zajmują więcej niż jeden ekran, możesz nacisnąć spację, aby przewinąć widok, lub klawisz q, aby wyjść.

git log -n <limit>

Ogranicz liczbę commitów za pomocą argumentu . Na przykład git log -n 3 spowoduje wyświetlenie tylko trzech commitów.

Skondensowanie każdego commitu do jednego wiersza przydaje się w celu uzyskania ogólnego podglądu historii projektu.

git log --oneline

git log --stat

Oprócz zwykłych informacji git log uwzględnia informacje o tym, które pliki zostały zmienione i ile wierszy dodano lub usunięto.

git log -p

Wyświetla łatkę reprezentującą każdy commit. Przedstawia pełny wykaz różnic dla każdego commitu, co stanowi najbardziej szczegółowy widok historii projektu.

git log --author="<pattern>"

Wyszukaj commity według autora. Argument może mieć postać zwykłego ciągu znaków lub wyrażenia regularnego.

git log --grep="<pattern>"

Wyszukaj commity za pomocą komunikatu commitu pasującego do wzorca , który może mieć postać zwykłego ciągu znaków lub wyrażenia regularnego.

git log <since>..<until>

Wyświetla tylko commity z przedziału określonego argumentami i . Oba mogą mieć postać identyfikatora commitu, nazwy gałęzi, wskaźnika HEAD lub dowolnego innego rodzaju odniesienia do wersji.

git log <file>

Wyświetla tylko commity zawierające określony plik. To prosty sposób na przejrzenie historii wybranego pliku.

git log --graph --decorate --oneline

Kilka przydatnych opcji do rozważenia. Flaga --graph tworzy tekstowy wykres commitów po lewej stronie komunikatów commitów. Flaga --decorate dodaje nazwy gałęzi lub tagi do wyświetlanych commitów. Flaga --oneline powoduje wyświetlenie informacji o commitach w jednym wierszu, co ułatwia ich przeglądanie.

Omówienie

Polecenie git log stanowi podstawowe narzędzie systemu Git do przeglądania historii repozytorium. Używa się go do znalezienia konkretnej wersji projektu lub sprawdzenia, jakie zmiany zostaną wprowadzone wskutek scalania z gałęzią funkcji.

commit 3157ee3718e180a9476bf2e5cab8e3f1e78a73b7
Author: John Smith

Większość jest dość łatwa do zrozumienia; pierwszy wiersz wymaga jednak wyjaśnienia. Ciąg 40 znaków po zwrocie commit to suma kontrolna SHA-1 zawartości commitu. Pełni dwie funkcje. Po pierwsze zapewnia integralność commitu — w przypadku uszkodzenia commit miałby wygenerowaną inną sumę kontrolną. Po drugie służy jako unikalny identyfikator commitu.

Ten identyfikator może znaleźć zastosowanie w poleceniach takich jak git log .. celem odniesienia do konkretnych commitów. Na przykład git log 3157e..5ab91 wyświetli wszystkie commity o identyfikatorach pomiędzy 3157e a 5ab91. Oprócz sum kontrolnych do popularnych metod odwoływania się do poszczególnych commitów należą nazwy gałęzi (omówione w module nt. gałęzi) oraz słowa kluczowe wskaźnika HEAD. Wskaźnik HEAD zawsze odnosi się do bieżącego commitu — czy to gałęzi, czy konkretnego commitu.

Znak ~ przydaje się do tworzenia względnych odniesień do elementu nadrzędnego commitu. Na przykład 3157e~1 odnosi się do commitu poprzedzającego 3157e, a HEAD~3 oznacza nadrzędność trzeciego stopnia względem bieżącego commitu.

Istotą wszystkich tych metod identyfikacji jest umożliwienie wykonywania działań na podstawie określonych commitów. Polecenie git log zazwyczaj stanowi punkt wyjścia dla tych interakcji, ponieważ umożliwia znalezienie commitów, na których mamy pracować.

Przykład

W sekcji Użycie znajduje się wiele przykładów zastosowania polecenia git log, lecz warto pamiętać, że kilka opcji można połączyć w jedno polecenie:

git log --author="John Smith" -p hello.py

To polecenie wyświetli pełen wykaz różnic w obrębie wszystkich zmian dokonanych przez Johna Smitha w pliku hello.py.

Opcja .. stanowi przydatne narzędzie do porównywania gałęzi. Poniższe polecenie wyświetli krótki przegląd wszystkich commitów dotyczących funkcji some-feature, które nie znajdują się w gałęzi main.