Git commit | git commit, amend, add, status, diff

Git commit amend

Git jako najpopularniejszy rozproszony system kontroli wersji – może się pochwalić rozbudowanym zbiorem funkcjonalności oraz różnego rodzaju integracji – co pozwala wykorzystać go swobodnie w wielu codziennych zadaniach.

W ramach tego materiału dowiesz się jak zapisać zmiany w swoim lokalnym repozytorium wykorzystując komendę git commit.

Git commit – wprowadzenie

Z tego materiału dowiesz się:

  • Czym jest commit (git commit)?
  • Jak zapisywać zmiany za pomocą komendy git commit?
  • Jak nadpisać już zapisane zmiany używając komendy git commit amend?

Git Commit

Git commit to migawka (ang. snapshot) Twojego repozytorium w określonym momencie. Żeby lepiej zrozumieć, jak działa i czym jest git commit najpierw musimy wykonać kilka innych kroków.

W ramach tego materiału zajmiemy się przede wszystkim zapisywaniem zmian w Gicie – natomiast kompletny tutorial Git znajdziesz poniżej. Tam również zapoznasz się ze stanami plików (m.in. z przechowywalnią (ang. stage)).

➡ ZOBACZ 👉: Git tutorial | stash, rebase, commit, merge, checkout, push i clone

Git install – instalacja Git

Jeżeli nie masz jeszcze gita zainstalowanego lokalnie – szybko możesz to nadrobić.
W poniższym materiale znajdziesz instrukcję, jak można to zrobić.

➡ ZOBACZ 👉: Install Git – Instalacja Git, Windows, Ubuntu – Bash, GUI

Git status – sprawdzenie stanu plików w repozytorium

Podstawowym narzędziem do weryfikacji stanu plików jest komenda git status.

Żeby lepiej zobrazować cały proces, przygotujmy w nowo zainicjowanym repozytorium prostą klasę javową.

public class User {
}

Zapisujemy ją w głównym katalogu repozytorium i odpalamy komendę: git status.

tw@tw:~/$ git status
On branch master
Initial commit
Untracked files:
(use git add file... to include in what will be committed)
User.java
nothing added to commit but untracked files present (use git add to track)

Git wykrył, że dodaliśmy nowy plik i ostrzega nas, że nie jest on jeszcze śledzony przez repozytorium.

Git add – śledzenie nowych plików

W celu rozpoczęcia śledzenia naszego pliku posłużymy się komendą: git add.

tw@tw:~/$ git add User.java
tw@tw:~/$ git add -A
tw@tw:~/$ git add .

W naszym wypadku wystarczy wywołanie dowolnej z poniższych komend:

  • git add User.java – dodaje jeden wybrany plik
  • git add -A – dodaje wszystkie nieśledzone pliki
  • git add . – dodaje do śledzenia bieżący katalog ze wszystkimi plikami i katalogami, które się w nim znajdują

Ponowne uruchomienie komendy git status pokazuje, że plik jest już w przechowalni (ang. stage) – status śledzony.

tw@tw:~/$ git status
On branch master
Initial commit
Changes to be committed:
(use git rm --cached file... to unstage)
new file: User.java

Dodawanie zmian do poczekalni (ang. stage)

Git operuje na pojedynczych zmianach, a nie na plikach. Bardzo dobrze to widać podczas dodawania plików za pomocą git add do poczekalni.

W tym celu zmodyfikujemy naszą klasę, dodając jej nowe pole.

public class User {
String name;
}

Ponowne odpalenie git status pokazuje, że plik User.java jest jednocześnie w dwóch sekcjach:

tw@tw:~/$ git status
On branch master
Initial commit
Changes to be committed:
(use git rm --cached file... to unstage)
new file: User.java
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: User.java

Dzieje się tak, ponieważ Git umieszcza plik w poczekalni w dokładnie takiej wersji, w jakiej znajdował się podczas odpalenia komendy git add. Jeżeli w tym momencie zostanie uruchomiona komenda git commit to zatwierdzona zostanie wersja z poczekalni, a nie ta widoczna w katalogu roboczym.

Żeby zaktualizować plik w poczekalni, trzeba go zwyczajnie jeszcze raz dodać przez git add.

Wykorzystanie poczekalni w procesie zatwierdzania zmian daje ogromne możliwości, dzięki temu można wybrać, które konkretnie modyfikacje chce się zatwierdzić i utrwalić w repozytorium.

Git diff – podgląd dokonanych zmian

Git diff to niezwykle ważna funkcjonalność. Przed zatwierdzeniem zmian (git commit) zawsze warto zweryfikować, czy wszystko poszło zgodnie z planem. Może się zdarzyć, że zmiany zostały zrobione nie w tym miejscu, co trzeba lub pojawiły się jakieś dodatkowe wygenerowane pliki, których nie chcemy utrwalać w repo. Dzięki weryfikacji zmian za pomocą git diff w podglądzie można uniknąć tego typu błędów.

Git status dostarczy tylko informacji, które pliki zostały zmodyfikowane, natomiast dzięki git diff można dokładnie zobaczyć zmiany, które zostały dokonane.

tw@tw:~/$ git status
On branch master
Initial commit
Changes to be committed:
(use git rm --cached file... to unstage)
new file: User.java
tw@tw:~/$ git diff
tw@tw:~/$ git diff --cached
diff --git a/User.java b/User.java
new file mode 100644
index 0000000..853d1c3
--- /dev/null
+++ b/User.java
@@ -0,0 +1,3 @@
+public class User {
+ String name;
+}
  • różnica między katalogiem roboczym a poczekalniągit diff
  • różnica między poczekalnią a repozytoriumgit diff –cached

Git commit – zatwierdzanie zmian

Jeżeli mamy już pewność, że dokonane zmiany są poprawne, można utrwalić je w lokalnym repozytorium. W tym celu posłużymy się komendą git commit.

git commit stage git master

Wywołanie komendy git commit bez żadnych argumentów uruchomi najpierw domyślny edytor tekstowy w celu podania komentarza dla zatwierdzanych zmian.

tw@tw:~/$ git commit
[master (root-commit) 61a1cba] User initial commit
1 file changed, 3 insertions(+)
create mode 100644 User.java

Opcjonalnie można podać komentarz jako argument już przy samym wywołaniu komendy:

 
git commit -m "User initial commit" 

Po potwierdzeniu zmiany zostaną zapisane w repozytorium w postaci nowej migawki (ang. snapshot).

Git commit -a (–all)

Git commit -a (opcjonalnie: git commit –all) jest to rozszerzenie komendy git commit o komendę git add.

Git commit -a dodaje zmiany ze wszystkich znanych plików (wykonuje git add oraz git rm dla plików usuniętych z katalogu roboczego – ang. working directory), a następnie wykonuje komendę git commit.

Git commit -am jest to rozszerzenie git -a o wiadomość (ang. message).

 
git commit -am "User initial commit" 

Git amend – nadpisanie historii zmian

Najczęściej wykorzystywaną opcją modyfikacji historii jest edycja ostatniego commit’a.

Git commit amend

Dzięki mechanizmowi commit –amend można modyfikować treść komentarza najnowszego commit’a oraz jego zawartość.

W tym celu przeprowadzamy procedurę podobną do zwykłego commit’owania zmian, jakbyśmy chcieli zatwierdzić nowy commit. Jednak wybranie opcji amend połączy ostatni wpis w historii z nowymi zmianami, tworząc jeden wpis w historii.

git commit --amend -a -m "Edit history"

Istnieje również możliwość edycji ostatniego komentarza z poziomu samej listy historii zmian.

Nie powinno się jednak w ten sposób edytować zmian wysłanych już do zdalnego repozytorium. Edytowany w ten sposób commit zmienia swój hash i może to doprowadzić do rozsynchronizowania lokalnego i zdalnego repozytorium.

Git pre-commit

Git pre-commit jest jedną opcji z Git hook scripts. Skrypty te są przydatne do identyfikowania prostych problemów przed przesłaniem kodu do review.

Uruchamiamy hook’i przy każdym użyciu git commit, aby automatycznie wskazać problemy w kodzie, m.in. takie jak brakujące średniki, whitespace i instrukcje debugowania lub sprawdzić odpowiednią dokumentację dotyczącą nowych metod.

Pre-commit jest uruchamiany jako pierwszy, zanim jeszcze wpiszesz wiadomość commit’a. Służy do sprawdzania migawki (ang. snapshot), która ma zostać zatwierdzona, aby sprawdzić, czy czegoś nie zapomniałeś, upewnić się, że testy zostały uruchomione lub zbadać wszystko, co musisz sprawdzić w kodzie.

Zanim będziesz mógł uruchomić hooks, musisz mieć zainstalowany menedżer pakietów pre-commit.

pre-commit install

Git commit – podsumowanie

W ramach tego materiału przećwiczyliśmy zapisywanie zmian w naszym lokalnym repozytorium, a także zapoznaliśmy się z wieloma przydatnymi komendami, które umożliwiają różne operacje w obrębie zapisywania zmian.

Jeżeli chcesz kontynuować swoją przygodę z gitem – to zapraszam do dodatkowych materiałów:

➡ ZOBACZ 👉: Git tutorial | stash, rebase, commit, merge, checkout, push i clone


Jak zostać programistą

8 rzeczy, które musisz wiedzieć, żeby dostać pracę jako programista.

Jak zostać programistą
No comments
Share:

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *