Kurs Git: podstawowe komendy (add, commit, push, pull)

Pięć komend wystarczy do codziennej pracy: status, add, commit, push i pull. Ten rozdział omawia je po kolei, a potem zajmuje się tym, czego nie powinien pomijać żaden kurs: jak się wycofać, kiedy coś pójdzie nie tak.

Jeden warunek wstępny: twoja tożsamość musi być zadeklarowana, inaczej Git odrzuci pierwszy commit. Jeśli tego brakuje, wróć do rozdziału o instalacji.

Trzy obszary Gita

Wszystko staje się prostsze, kiedy zrozumiesz, że twoje pliki zawsze znajdują się w jednym z trzech obszarów.

• Katalog roboczy: pliki takie, jakimi widzisz je w eksploratorze.
• Indeks, nazywany też staging area: lista tego, co trafi do następnego commita. git add umieszcza tam zmiany.
• Repozytorium: historia commitów, którą zasila git commit.

Ten pośredni obszar na początku myli, ale to właśnie dzięki niemu zapiszesz trzy zmiany z pięciu, a dwie pozostałe zostawisz na osobny commit.

git status, komenda do wpisywania bez przerwy

Mówi, w którym miejscu jesteś, a jej komunikaty prawie zawsze zawierają komendę do wpisania w następnej kolejności. Wyrób sobie nawyk uruchamiania jej przed każdą operacją i po niej.

git status

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	.env
	app.js
	node_modules/

nothing added to commit but untracked files present (use "git add" to track)

Krótka wersja mieści się w jednej linii na plik i szybko wchodzi w krew:

git status --short

?? .env
?? app.js
?? node_modules/

?? oznacza plik, którego Git jeszcze nie śledzi, A plik dodany do indeksu, M plik zmodyfikowany.

.gitignore: co nigdy nie powinno trafić do repozytorium

Zanim wpiszesz pierwsze git add, odsiej to, co nie ma czego szukać w repozytorium: zależności, które da się zainstalować od nowa, pliki konfiguracyjne z sekretami, pliki generowane przez system albo edytor.

Utwórz plik .gitignore w katalogu głównym projektu:

node_modules/
vendor/
.env
.env.local
dist/
build/
*.log
.DS_Store
.idea/
.vscode/

Uruchom ponownie git status: zignorowane pliki zniknęły z listy.

?? .gitignore
?? app.js

Sam .gitignore jest wersjonowany: należy do projektu i trzeba go współdzielić z zespołem.

Uwaga na pułapkę: .gitignore nie ma żadnego wpływu na plik już śledzony. Jeśli .env trafił do commita, zanim o tym pomyślałeś, trzeba go jawnie usunąć z indeksu:

git rm --cached .env
git commit -m "Retire le fichier .env du suivi"

Opcja --cached jest tu kluczowa: usuwa plik z indeksu, ale nie kasuje go z dysku.

A sekrety, które zawierał, uznaj za spalone: w historii nadal da się je odczytać. Zmień je.

git add: przygotowanie commita

git add app.js          # jeden plik
git add src/            # cały katalog
git add .               # wszystko, co się zmieniło w bieżącym katalogu
git add -p              # wybór blok po bloku, interaktywnie

git add -p warto wypróbować wcześnie. Git pokazuje każdy blok zmian i pyta, czy ma trafić do commita. To najprostszy sposób na commity, które opowiadają o jednej rzeczy.

git commit: zapisanie zmian

git commit -m "Ajoute la page d'accueil"

[main (root-commit) fd4fdb7] Ajoute la page d accueil
 2 files changed, 3 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 app.js

Jeśli w indeksie nic nie ma, Git niczego nie tworzy i wprost o tym mówi:

On branch main

Initial commit

nothing to commit (create/copy files and use "git add" to track)

Co do komunikatów commitów, warto zapamiętać jedną zasadę: pisz, co commit robi, a nie których plików dotyczy. „Poprawia naliczanie VAT-u w zamówieniach spoza UE” jest lepsze niż „zmiana facture.php”. Piszesz dla siebie za pół roku.

Skrót -am łączy add i commit, ale tylko dla plików już śledzonych:

git commit -am "Corrige le libellé du bouton"

Czytanie historii

git log                                  # pełna historia
git log --oneline                        # jedna linia na commit
git log --oneline --graph --decorate     # z kształtem gałęzi
git log -p app.js                        # historia jednego pliku, razem z diffami

* fd4fdb7 (HEAD -> main) Ajoute la page d accueil

HEAD wskazuje miejsce, w którym stoisz w historii. Strzałka oznacza, że HEAD podąża za gałęzią main.

Podgląd zmian przed commitem

Dwie komendy, często mylone, które patrzą na dwa różne obszary.

git diff            # co się zmieniło, ale nie jest jeszcze w indeksie
git diff --staged   # co jest w indeksie i trafi do następnego commita

diff --git a/app.js b/app.js
index e921523..ebde020 100644
--- a/app.js
+++ b/app.js
@@ -1 +1 @@
-console.log('hello');
+console.log('bonjour');

Po git add app.js ta sama zmiana przeskakuje: git diff nie zwraca już nic, a git diff --staged pokazuje blok. To najlepszy sposób, żeby zobaczyć indeks na własne oczy.

git push i git pull: wymiana z serwerem

git push        # wysyła lokalne commity
git pull        # pobiera i włącza commity innych

Te dwie skrócone formy działają tylko wtedy, gdy gałąź ma powiązanie z serwerem, ustawione opcją -u w poprzednim rozdziale. Żeby sprawdzić to powiązanie:

git branch -vv

* feature/panier bc2203a Page d accueil
  main           bc2203a [origin/main] Page d accueil

Gałąź main śledzi origin/main, gałąź feature/panier na razie nie śledzi niczego.

Jeśli ktoś wypchnął zmiany w trakcie twojej pracy, twój push zostanie odrzucony. Co wtedy zrobić i dlaczego tak się dzieje, opisuje rozdział o gałęziach.

Cofanie wpadki

To ta część, której początkujący szukają najczęściej, a tłumaczy im się ją najrzadziej. Dobry odruch to zacząć od jednego pytania: czy to, co chcę cofnąć, trafiło już na serwer?

Plik jest zmieniony, chcę wrócić do ostatniego commita

git restore app.js       # jeden plik
git restore .            # cały katalog roboczy

Uwaga, ta komenda niszczy twoje zmiany bez żadnej siatki bezpieczeństwa: nigdy nigdzie nie zostały zapisane, więc Git ich nie odzyska.

Plik trafił do indeksu przez pomyłkę

git restore --staged app.js

Plik wychodzi z indeksu, a twoje zmiany zostają nietknięte w katalogu roboczym.

Te dwie komendy to nowoczesny odpowiednik git checkout -- fichier i git reset HEAD fichier. git restore istnieje od Gita 2.23 i jasno mówi, co robi, podczas gdy checkout i reset robią po trzy różne rzeczy zależnie od opcji.

Ostatni commit ma zły komunikat

git commit --amend -m "Le bon message"

Ta sama komenda przyda się do dodania zapomnianego pliku: zrób git add, a potem uruchom git commit --amend. Używaj jej tylko na commicie, który nie został jeszcze wypchnięty: --amend nie modyfikuje commita, tylko tworzy w jego miejsce nowy, a stary identyfikator znika.

Commit jest już wypchnięty, chcę go czysto cofnąć

git revert HEAD

[main 0246de1] Revert "Ajoute un fichier par erreur"
 1 file changed, 1 deletion(-)
 delete mode 100644 bug.txt

git revert tworzy nowy commit, który stosuje odwrotność poprzedniego. Historia się wydłuża, zamiast zostać przepisana, i dokładnie tego trzeba, kiedy inni pobrali już twoją pracę. To jedyna bezpieczna metoda na współdzielonej gałęzi.

Commit nie został wypchnięty, chcę go usunąć

git reset --soft HEAD~1   # cofa commit, zostawia wszystko w indeksie
git reset --mixed HEAD~1  # cofa commit, zostawia pliki zmienione (zachowanie domyślne)
git reset --hard HEAD~1   # cofa commit i usuwa zmiany

--soft jest najbardziej przydatny: oddaje ci zmiany gotowe do zacommitowania inaczej. --hard jako jedyny niszczy pracę i nie ostrzega. Wpisuj go tylko wtedy, gdy masz pewność.

Jeden reset –hard za dużo

Nie wszystko stracone. Git przez kilka tygodni przechowuje ślad wszystkich stanów, przez które przeszedł HEAD:

git reflog

8207e54 HEAD@{0}: reset: moving to HEAD~2
f3951da HEAD@{1}: commit: Version 3
8ac671c HEAD@{2}: commit: Version 2
8207e54 HEAD@{3}: commit (initial): Version 1

Oba skasowane commity wciąż tam są. Znajdź linię odpowiadającą szukanemu stanowi, zapisz jej identyfikator i wróć do niego:

git reset --hard f3951da

reflog ratuje jednak tylko to, co zostało zacommitowane. Zmiany, których nigdy nie zapisano, przepadają bezpowrotnie, co jest kolejnym argumentem za częstym commitowaniem.

Podsumowanie

Umiesz już pracować w pojedynkę. Następny rozdział dokłada resztę: gałęzie, scalanie i konflikty. Ostatni rozdział zajmie się potem organizacją tych gałęzi w skali zespołu.