Close

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.
Logo Git
materiały pokrewne

Git — ściągawka

Logo Bitbucket
POZNAJ ROZWIĄZANIE

Poznaj środowisko Git z rozwiązaniem Bitbucket Cloud

Użycie

git status

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

Dyskusja

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)

The first status output will show the file as unstaged. The git add action will be reflected in the second git status, and the final status output will tell you that there is nothing to commit—the working directory matches the most recent commit. Some Git commands (e.g., git merge) require the working directory to be clean so that you don't accidentally overwrite changes.

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.

Git status vs git log

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>"

Search for commits by a particular author. The <pattern> argument can be a plain string or a regular expression.

git log --grep="<pattern>"

Search for commits with a commit message that matches <pattern>, which can be a plain string or a regular expression.

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.

Dyskusja

5. Sprawdź status pliku.

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.

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.

git log --oneline main..some-feature

Udostępnij ten artykuł
Następny temat

Zalecane lektury

Dodaj te zasoby do zakładek, aby dowiedzieć się więcej na temat rodzajów zespołów DevOps lub otrzymywać aktualności na temat metodyki DevOps w Atlassian.

Ludzie współpracujący przy ścianie pełnej narzędzi

Blog Bitbucket

Ilustracja DevOps

Ścieżka szkoleniowa DevOps

Demonstracje funkcji z ekspertami Atlassian

Zobacz, jak Bitbucket Cloud współpracuje z Atlassian Open DevOps

Zapisz się do newslettera DevOps

Thank you for signing up