Ścieżka Kariery Computer Vision – BLOG – Miesiąc 1. – Nauka GITa

Drugie zadanie w pierwszym miesiącu do nauka GITa. Mamy na to poświęcić aż 6 godzin! To dużo, ale jeśli to rzeczywiście Twoja pierwsza styczność z GITem, i tak pewnie nie ogarniesz całokształtu, dopóki nie zaczniesz z nim pracować. Dlatego polecam nie spinać się za bardzo i wkuć tylko absolutne podstawy.

W tym zadaniu mamy dwa linki – oba są dostępne po polsku, a Pro Git nawet można dotłumaczyć i złapać kilka punktów do CV za działalność na rzecz społeczności. 🙂

1. Interaktywny kurs learngitbranching.js.org
2. ebooka: Pro Git

Ad. A – Learn Git Branching app

Zacznijmy od interaktywnego kursu. Jest suuuuper! Fajnie się klika, łatwo obsługuje i ma przyjemne (choć nieco retro) animacje. W dodatku wszystkie instrukcje są opisane i pokazane na mini animacjach, dzięki czemu trochę łatwiej zrozumieć drzewo, jakim jest Git. No i jest dostępna polska wersja, więc duuuużo łatwiej zrozumieć zawiłe instrukcje.

Każde zadanie ma pokazane graficzny stan PRZED i PO, a Twoim zadaniem jest tak pokierować komendami Git, żeby uzyskać identyczny efekt.

A jeśli się gdzieś zakręcisz lub nie wiesz, jak rozwiązać dany problem, możesz kliknąć na menu w prawym dolnym rogu i zobaczyć rozwiązanie.

Podoba mi się ta appka, ale niestety tematem jeg Git, który nie jest super interesujący (jeśli już się z nim pracuje). Dotrwałam do poziomu 6, zanim mnie kompletnie zmuliło. Dalej nie robię.

Ad. B – Git Pro

Rozdziały 2 i 3 zawierają następujące podrozdziały:

Przyznam, że nie chciało mi się tego wszystkiego czytać. Z pomocą przyszedł ChatGPT, który zrobił krótkie podsumowanie tych rozdziałów. I tak mamy:

Rozdziały te stanowią fundament pracy z Gitem — poznajesz podstawy: tworzenie repozytorium, robienie commitów, cofanie zmian, pracę z zdalnymi repozytoriami i tagami.
Uczysz się jak skutecznie pracować równolegle nad projektem dzięki gałęziom i skalować kod za pomocą merge lub rebase.


2.1 Tworzenie repozytorium

git init tworzy nowe repozytorium lokalnie.
git clone <url> kopiuje istniejące repozytorium wraz z historią.


2.2 Rejestrowanie zmian

Edycja plików → git add dodaje je do obszaru staging („index”).
git commit -m "komentarz" zapisuje snapshot do bazy Git (Git directory).

Git operuje na trzech stanach pliku: modified, staged, committed 

** Po naszemu to oznacza zmiany, które zrobiliśmy, ale jeszcze nie dodaliśmy nigdzie, zmiany dodane do “stage’a” i zmiany zacommitowane ***

2.3 Przegląd historii

git log pokazuje historię commitów. 

***W praktyce nikt tego nie robi. Znacznie łatwiej jest sprawdzić zmiany w GUI.***

Można dodać różne opcje np. --oneline, --graph.


2.4 Cofanie zmian

git checkout -- <plik> przywraca plik z ostatniego commita.
git reset HEAD <plik> cofa plik ze staging area.
git revert <commit> tworzy nowy commit cofający zmiany.

***Tu dodałabym git reset --hard – to szybko sposób, by pozbyć się WSZYSTKIEGO (zacommitowanego i nie) na lokalnym branchu i pobrać na świeżo stan z ostatniego wypchniętego commita. Ja w swojej pracy wypycham zmiany dopiero wtedy, kiedy jestem ich pewna. Dzięki temu tzw. twardy reset przywraca zawsze kod w poprawnym i działającym stanie.***


2.5 Praca z repozytoriami zdalnymi

git remote add origin <url> – dodaje repozytorium zdalne.
git fetch pobiera zmiany, 
git pull – fetch + merge. 

***W praktyce zazwyczaj wybieram git pull —  co mi po zmianach, które nie domerdżują się do mojego obecnego stanu?***

git push wysyła lokalne commity na serwer.


2.6 Tagowanie

git tag <nazwa> – oznacza konkretny commit (np. wersję).
Można tworzyć tagi podpisane (-a, -s).

***Czy ktokolwiek tego używa? Nigdy się z tym nie spotkałam.***


2.7 Aliasowanie

git config --global alias.st status — definiuje alias „st” dla „status”.

***Tak samo tu - być może 1% najbardziej leniwych devów zrobi sobie aliasy, żeby nie wypisywać za każdym razem git commit -m (13 znaków) i zamiast tego będzie pisać git c (5 znaków). Ale jeśli masz autouzupełnianie komend, to ma jeszcze tak duże znaczenie? Nie sądzę.***


Rozdział 3: Git Branching

3.1 Gałęzie w pigułce

Gałąź to wskaźnik na commit – bardzo lekkie.
Umożliwiają równoległą pracę bez ingerowania w główną linię czasu


3.2 Proste gałęzie i łączenie

git branch <nazwa> tworzy gałąź.
git checkout <nazwa> przełącza na inną gałąź.
git checkout -b <nazwa> – tworzy i przełącza.
git merge <gałąź> scala zmiany z innej gałęzi

***To akurat bardzo ważne rzeczy. git branch, git checkout i git merge są używane praktycznie codziennie. Ja osobiście nie lubię używać argumentów (np. -b, -f), ponieważ można łatwo się pomylić (zwłaszcza przy autouzupełnianiu komend) i przypadkiem coś namieszać.***


3.3 Zarządzanie gałęziami

Usuwanie: git branch -d <nazwa>.
Przenoszenie: git branch -m <stara> <nowa>.
Przegląd gałęzi lokalnych (git branch) i zdalnych (git branch -r).

***Nigdy nie usuwałam brancha za pomocą komendy — w przypadku Merge Request’ów w GitHubie można zaznaczyć opcję, by usunąć brancha po domerdżowaniu. To IMO bezpieczny i czysty sposób na sprzątanie Gita i nie muszę się bawić w argumenty.
 
Przenoszenie branch’ów - nie stosowałam i nie spotkałam się z tym. W praktyce czyściej jest stworzyć nowego brancha w miejscu docelowym i domerdżować starego brancha do nowego.

Przeglądanie branch’ów - tylko w GUI.***


3.4 Workflowy gałęzi
Feature branching – osobne gałęzie dla funkcjonalności.
Gitflow, GitHub flow, Trunk-based development – różne strategie zarządzania release’ami, hotfixami itd.

***
W moim zespole rzeczywiście używamy tzw. feature branch’ów dla osobnych funkcjonalności. Merdżujemy do tych branch’ów zmiany z naszych poszczególnych ticketów i dopiero po zakończeniu i przetestowaniu całości domerdżowujemy feature branch do mastera. 

Problem robi się, jeśli pracujemy na feature branch’u zbyt długo i za bardzo różni się od mastera. Rozwiązywanie konfliktów przy MR do ZŁO! 
***


3.5 Gałęzie zdalne

git push -u origin <gałąź> – tworzy gałąź zdalną i ustawia tracking.
git fetch && git merge origin/<gałąź> – synchronizuje.
git pull --rebase – pobranie z rebase zamiast merge’a.

***
Najważniejszy git push -u origin <branch>. W ten sposób łączymy branch lokalną z branchem na GitHubie.
***


3.6 Rebasing

Alternatywa dla scalenia – „przenosi” sekwencję commitów tak, by historia była liniowa.
Workflow: git checkout feature, git rebase master, potem git checkout master && git merge feature (fast-forward).
Zalety: czysta i liniowa historia. Wady: modyfikuje historię – nie stosować na gałęziach wspólnych.

***
Git rebase jest problematyczny, ponieważ trzeba rozwiązać konflikty z każdym commitem po kolei. Więc jeśli nasz branch i branch, na który chcemy się przepiąć, dzieli 20 commitów, będziemy musieli 20x rozwiązać te same konflikty. Nie polecam.
***

I to koniec podsumowania autorstwa ChataGPT.  

Podsumowanie

Ze swojej strony mogę tylko dodać, że NIE WARTO uczyć się na pamięć wszystkich tych komend (oprócz kilku podstawowych). Po pierwsze większość z nas pracuje z graficznym interfejsem GITa (tzn. dodaje, commituje i puszuje za pomocą specjalnego menu w IDE). A po drugie 90% tych komend jest używanych raz na sto lat i zdążysz je zapomnieć, zanim będą Ci potrzebne.

Zamiast czytania podręcznika, polecam wpis na stronie porozmawiAImy.pl i ściągawkę do wydrukowania. A jeśli chcesz mieć więcej komend pod ręką (my planujemy jeszcze wersję dla zaawansowanych z merdżami, rebasami i resetami), to polecam ten wątek na Quorze. Mnie osobiście podoba się ta ściągawka od Jana Krugera i ta od Nerd Girl.

---

---

Co dalej?

→ Zapisz się do naszego newslettera, żeby nigdy nie przegapić żadnego wartościowego artykułu.

→ Zajrzyj do sekcji Kariera w AI, gdzie znajdziesz konkretne materiały o zmianach na rynku pracy – w Polsce i na świecie – oraz ścieżkach kariery związanych ze sztuczną inteligencją (nie tylko jako programista!).

→ A jeśli chcesz pisać modele i pracować jako Architekt AI, ale nie wiesz, od czego zacząć (lub utknąłeś gdzieś na ścieżce), odwiedź dział Nauka AI – czeka tam wiedza, ciekawostki i realne wsparcie.

---

! Uwaga

Niniejszy ebook ma charakter informacyjny i edukacyjny. Nie stanowi porady prawnej ani oferty pracy w rozumieniu przepisów krajowych lub unijnych.
Przy tworzeniu niniejszego artykułu korzystano ze wsparcia narzędzi opartych na sztucznej inteligencji – m.in. w zakresie porządkowania treści, analizy źródeł, przyspieszenia redakcji i wyszukiwania źródeł Jednak wszelkie decyzje dotycząca treści, interpretacji i ostatecznej formy zostały podjęte przez człowieka.