Michał Walendowski

Szybki Start! GIT w moment

Książka stworzona przy pomocy AI.

© Michał Walendowski, 2025

Git jest jednym z najpopularniejszych narzędzi do zarządzania wersjami kodu, stosowanym przez programistów na całym świecie. Niezależnie od tego, czy tworzysz mały projekt hobbystyczny, czy pracujesz w dużym zespole nad złożoną aplikacją, Git ułatwia śledzenie zmian w kodzie i współpracę. Książka stworzona przy pomocy AI.

ISBN 978-83-8384-662-0

Książka powstała w inteligentnym systemie wydawniczym Ridero

Spis treści

1. Szybki Start! GIT w moment

2. Rozdział 1: Wprowadzenie do Git

1. 1.1 Co to jest system kontroli wersji?

2. 1.2 Dlaczego warto używać Git?

3. 1.3 Instalacja Git

4. 1.4 Pierwsza konfiguracja Git

5. 1.5 Podstawowe pojęcia w Git

6. 1.6 Tworzenie pierwszego repozytorium

7. 1.7 Tworzenie pierwszego commitu

8. Podsumowanie

3. Rozdział 2: Podstawowe komendy Git

1. 2.1 Inicjalizacja nowego repozytorium

2. 2.2 Sprawdzanie statusu repozytorium

3. 2.3 Dodawanie plików do staged (git add)

4. 2.4 Tworzenie commitu (git commit)

5. 2.5 Wyświetlanie historii zmian (git log)

6. 2.6 Ignorowanie plików (plik. gitignore)

7. 2.7 Wycofywanie zmian przed commitem (git reset)

8. 2.8 Usuwanie plików z repozytorium (git rm)

9. 2.9 Sprawdzanie różnic między zmianami (git diff)

10. 2.10 Podsumowanie podstawowych komend

11. Podsumowanie

4. Rozdział 3: Praca z repozytorium lokalnym

1. 3.1 Tworzenie nowego repozytorium lokalnego

2. 3.2 Klonowanie istniejącego repozytorium

3. 3.3 Struktura katalogu repozytorium Git

4. 3.4 Ignorowanie plików z. gitignore

5. 3.5 Wyświetlanie listy zdalnych repozytoriów

6. 3.6 Dodawanie nowego zdalnego repozytorium

7. 3.7 Aktualizowanie repozytorium zdalnego

8. 3.8 Wysyłanie zmian do repozytorium zdalnego

9. 3.9 Podsumowanie pracy z repozytorium lokalnym

10. Podsumowanie

5. Rozdział 4: Historia i śledzenie zmian

1. 4.1 Wyświetlanie historii commitów

2. 4.2 Wyświetlanie różnic między commitami

3. 4.3 Śledzenie zmian w konkretnym pliku

4. 4.4 Przeglądanie zmian w plikach z git blame

5. 4.5 Cofanie zmian za pomocą git checkout

6. 4.6 Cofanie commitów z git revert

7. 4.7 Resetowanie historii za pomocą git reset

8. 4.8 Odzyskiwanie utraconych commitów za pomocą git reflog

9. 4.9 Analiza graficzna historii commitów

10. 4.10 Podsumowanie

11. Podsumowanie

6. Rozdział 5: Branching i zarządzanie gałęziami

1. 5.1 Wprowadzenie do gałęzi

2. 5.2 Tworzenie nowej gałęzi

3. 5.3 Wyświetlanie dostępnych gałęzi

4. 5.4 Przełączanie się między gałęziami

5. 5.5 Scalanie gałęzi (merge)

6. 5.6 Konflikty merge i ich rozwiązywanie

7. 5.7 Usuwanie gałęzi

8. 5.8 Praca z gałęziami zdalnymi

9. 5.9 Śledzenie gałęzi zdalnych

10. 5.10 Najlepsze praktyki w pracy z gałęziami

11. 5.11 Podsumowanie pracy z gałęziami

12. Podsumowanie

7. Rozdział 6: Łączenie gałęzi (Merge)

1. 6.1 Wprowadzenie do merge

2. 6.2 Przeprowadzanie merge

3. 6.3 Typy merge: Fast-Forward i Three-Way Merge

4. 6.4 Konflikty merge i ich rozwiązywanie

5. 6.5 Rebase jako alternatywa dla merge

6. 6.6 Merge commit vs. Squash merge

7. 6.7 Unieważnienie merge

8. 6.8 Najlepsze praktyki przy merge

9. 6.9 Praktyka: Scalanie dwóch gałęzi

10. 6.10 Podsumowanie

11. Podsumowanie

8. Rozdział 7: Rebase — alternatywa dla merge

1. 7.1 Wprowadzenie do rebase

2. 7.2 Przeprowadzanie rebase

3. 7.3 Jak działa rebase?

4. 7.4 Konflikty podczas rebase i ich rozwiązywanie

5. 7.5 Rebase vs. Merge — porównanie

6. 7.6 Interaktywny rebase

7. 7.7 Łączenie commitów (squash) podczas rebase

8. 7.8 Najlepsze praktyki przy użyciu rebase

9. 7.9 Praktyka: Rebase gałęzi feature do main

10. 7.10 Cofanie rebase

11. 7.11 Podsumowanie

12. Podsumowanie

9. Rozdział 8: Praca zdalna z Git

1. 8.1 Wprowadzenie do repozytoriów zdalnych

2. 8.2 Dodawanie zdalnego repozytorium

3. 8.3 Wysyłanie zmian do repozytorium zdalnego (push)

4. 8.4 Pobieranie zmian z repozytorium zdalnego (pull)

5. 8.5 Pobieranie danych ze zdalnego repozytorium (fetch)

6. 8.6 Klonowanie zdalnego repozytorium

7. 8.7 Praca z wieloma repozytoriami zdalnymi

8. 8.8 Usuwanie i zmiana repozytorium zdalnego

9. 8.9 Forkowanie repozytorium

10. 8.10 Tworzenie Pull Requestów

11. 8.11 Konfiguracja SSH do autoryzacji

12. 8.12 Zarządzanie gałęziami zdalnymi

13. 8.13 Synchronizacja z repozytorium zdalnym

14. 8.14 Praktyka: Wysyłanie zmian do GitHub

15. 8.15 Podsumowanie

16. Podsumowanie

10. Rozdział 9: Tagowanie wersji

1. 9.1 Wprowadzenie do tagowania

2. 9.2 Tworzenie tagów lekkich

3. 9.3 Tworzenie tagów adnotowanych

4. 9.4 Wyświetlanie tagów

5. 9.5 Przechodzenie do konkretnego tagu

6. 9.6 Przesyłanie tagów do repozytorium zdalnego

7. 9.7 Usuwanie tagów

8. 9.8 Aktualizacja tagów

9. 9.9 Praktyka: Tworzenie tagu adnotowanego

10. 9.10 Najlepsze praktyki przy tagowaniu

11. 9.11 Przykład wersjonowania: Tworzenie tagów dla wydań

12. 9.12 Automatyzacja tagowania z użyciem skryptów

13. 9.13 Podsumowanie

14. Podsumowanie

11. Rozdział 10: Resetowanie zmian

1. 10.1 Wprowadzenie do resetowania

2. 10.2 Resetowanie za pomocą git reset

3. 10.3 Przechodzenie do wcześniejszej wersji plików za pomocą git checkout

4. 10.4 Cofanie zmian za pomocą git revert

5. 10.5 Różnice między reset, checkout a revert

6. 10.6 Cofanie zmian w plikach

7. 10.7 Praktyka: Resetowanie ostatniego commitu

8. 10.8 Przykład użycia git revert w pracy zespołowej

9. 10.9 Przykładowe scenariusze resetowania

10. 10.10 Najlepsze praktyki przy resetowaniu

11. 10.11 Jak odzyskać utracone commity

12. 10.12 Przywracanie historii za pomocą reflog

13. 10.13 Podsumowanie

14. Podsumowanie

12. Rozdział 11: Stashing — zapisywanie chwilowych zmian

1. 11.1 Wprowadzenie do stashing

2. 11.2 Tworzenie stash

3. 11.3 Sprawdzanie dostępnych stashy

4. 11.4 Przywracanie stashy

5. 11.5 Usuwanie stashy

6. 11.6 Przykład użycia stashing w praktyce

7. 11.7 Przechowywanie tylko zmian w katalogu roboczym

8. 11.8 Przechowywanie tylko zmian w staging area

9. 11.9 Przykład: Praca z wieloma stashami

10. 11.10 Najlepsze praktyki przy używaniu stashing

11. 11.11 Problemy z łączeniem stashy

12. 11.12 Podsumowanie

13. Podsumowanie

13. Rozdział 12: Git w zespole

1. 12.2 Tworzenie i zarządzanie gałęziami

2. 12.3 Współpraca z zdalnym repozytorium

3. 12.4 Ustalanie standardów pracy zespołowej

4. 12.5 Zarządzanie konfliktami

5. 12.6 Code Review

6. 12.7 Współpraca w zdalnym zespole

7. 12.8 Przykład pracy w zespole

8. 12.9 Najlepsze praktyki przy pracy w zespole

9. 12.10 Podsumowanie

10. Podsumowanie

14. Rozdział 13: Debugowanie i naprawianie błędów w Git

1. 13.1 Najczęstsze błędy w Git

2. 13.2 Diagnostyka problemów

3. 13.3 Naprawa utraconych zmian

4. 13.4 Rozwiązywanie konfliktów

5. 13.5 Wycofywanie commitów

6. 13.6 Naprawianie zdalnych błędów

7. 13.7 Użycie reflog do odzyskiwania commitów

8. 13.8 Podsumowanie

9. Podsumowanie

15. Rozdział 14: Optymalizacja i zaawansowane techniki Git

1. 14.1 Optymalizacja repozytoriów

2. 14.2 Zautomatyzowane procesy z Git hooks

3. 14.3 Użycie aliasów do uproszczenia poleceń

4. 14.4 Praca z submodułami

5. 14.5 Wykorzystanie cherry-pick

6. 14.6 Praca z rebase

7. 14.7 Wykorzystanie stash do zarządzania zmianami

8. 14.8 Monitorowanie wydajności z Git

9. 14.9 Podsumowanie

10. Podsumowanie

16. Bibliografia

Rozdział 1: Wprowadzenie do Git

Git jest jednym z najpopularniejszych narzędzi do zarządzania wersjami kodu, stosowanym przez programistów na całym świecie. Niezależnie od tego, czy tworzysz mały projekt hobbystyczny, czy pracujesz w dużym zespole nad złożoną aplikacją, Git ułatwia śledzenie zmian w kodzie i współpracę. W tym rozdziale poznasz, czym jest Git, jakie są jego zalety oraz jak go zainstalować i skonfigurować.

1.1 Co to jest system kontroli wersji?

System kontroli wersji (ang. Version Control System, VCS) to narzędzie, które pozwala na śledzenie zmian w plikach w miarę ich edytowania. Dzięki temu możesz cofnąć się do poprzednich wersji, porównywać zmiany, a także pracować równolegle z innymi nad tym samym projektem. Istnieją różne systemy kontroli wersji, takie jak CVS, SVN, Mercurial, jednak Git jest obecnie najbardziej popularny ze względu na swoją szybkość, elastyczność i wsparcie społeczności.

1.2 Dlaczego warto używać Git?

Git posiada kilka kluczowych zalet, które czynią go wyjątkowym:

Rozproszony model pracy: Każdy użytkownik posiada pełną kopię repozytorium lokalnie, co umożliwia pracę offline i zapewnia większą niezależność.

Wydajność: Operacje takie jak commit, log czy diff są wykonywane bardzo szybko, ponieważ operacje odbywają się na lokalnej kopii repozytorium.

Wersjonowanie i współpraca: Możesz pracować na różnych gałęziach projektu, równocześnie z innymi programistami, co jest kluczowe w pracy zespołowej.

Historia zmian: Każda zmiana w plikach jest zapisywana, co pozwala na przeglądanie historii projektu oraz analizowanie wprowadzonych modyfikacji.

1.3 Instalacja Git

Zanim rozpoczniesz pracę z Git, musisz go zainstalować. Poniżej znajdują się instrukcje instalacji na różnych systemach operacyjnych.

Instalacja Git na Linuxie

W przypadku systemów opartych na Ubuntu lub Debian, otwórz terminal i wpisz:

bash

sudo apt update

sudo apt install git

Dla dystrybucji opartych na Red Hat (np. Fedora):

bash

sudo dnf install git

Instalacja Git na macOS

Jeśli masz zainstalowany Homebrew, wystarczy, że wpiszesz:

bash

brew install git

Instalacja Git na Windows

Na Windowsie możesz pobrać instalator z oficjalnej strony git-scm.com i postępować zgodnie z instrukcjami. Po instalacji Git Bash zostanie zainstalowany, co pozwala na używanie Git z poziomu terminala w Windowsie.

1.4 Pierwsza konfiguracja Git

Po zainstalowaniu Git, konieczne jest skonfigurowanie podstawowych ustawień, takich jak nazwa użytkownika i adres e-mail. Te dane będą widoczne przy każdym commicie, który wykonasz. Aby to zrobić, otwórz terminal i wpisz następujące komendy:

bash

git config — global user.name „Twoje Imię”

git config — global user. email "twojemail@example.com”

Możesz sprawdzić swoją konfigurację za pomocą polecenia:

bash

git config — list

Zobaczysz listę aktualnych ustawień.

1.5 Podstawowe pojęcia w Git

Zanim przejdziesz do dalszych rozdziałów, warto zrozumieć kilka podstawowych pojęć, które będą używane w dalszej części książki:

Repository (repozytorium): Jest to miejsce, gdzie Git przechowuje wszystkie wersje twojego projektu. Może być lokalne (na twoim komputerze) lub zdalne (np. na GitHubie).

Commit: Operacja, która zapisuje zmiany w repozytorium. Każdy commit zawiera unikalny identyfikator oraz opis zmian.

Branch (gałąź): Gałąź pozwala na pracę nad różnymi wersjami projektu równocześnie. Domyślną gałęzią w Git jest main lub master.

Merge: Proces łączenia dwóch gałęzi. Zmiany wprowadzone w jednej gałęzi mogą zostać scalone z drugą.

Remote: Zdalne repozytorium, na przykład na serwerze GitHub czy GitLab. Umożliwia współpracę nad projektem w zespole.

1.6 Tworzenie pierwszego repozytorium

Po zainstalowaniu i skonfigurowaniu Git, możemy utworzyć nasze pierwsze repozytorium. Aby to zrobić, najpierw utwórz nowy katalog i przejdź do niego:

bash

mkdir moj-pierwszy-projekt

cd moj-pierwszy-projekt

Następnie, aby zainicjować repozytorium Git, wykonaj komendę:

bash

git init

Ta komenda tworzy ukryty folder. git, w którym Git będzie przechowywał całą historię projektu.

1.7 Tworzenie pierwszego commitu

Dodajmy teraz pierwszy plik do naszego repozytorium. Utwórz nowy plik README.md:

bash

echo „# Mój pierwszy projekt” > README.md

Aby dodać plik do obszaru staged, użyj komendy:

bash

git add README.md

Następnie wykonaj commit, aby zapisać zmiany:

bash

git commit -m „Dodano plik README”

Gratulacje! Właśnie utworzyłeś swój pierwszy commit w Git.

Podsumowanie

W tym rozdziale dowiedziałeś się, czym jest Git i jakie są jego zalety. Przeszliśmy przez proces instalacji Git na różnych systemach operacyjnych, konfiguracji użytkownika oraz utworzenia pierwszego repozytorium. Teraz jesteś gotowy, aby przejść do kolejnych rozdziałów, gdzie zgłębimy bardziej zaawansowane funkcje Git.

Rozdział 2: Podstawowe komendy Git

W tym rozdziale nauczymy się podstawowych komend Git, które są niezbędne do pracy z repozytorium. Poznasz jak tworzyć i zarządzać zmianami w swoim projekcie, dodawać pliki, wykonywać commity, oraz jak sprawdzać status swojego repozytorium.

2.1 Inicjalizacja nowego repozytorium

Każdy projekt w Git zaczyna się od repozytorium. Jeśli jeszcze tego nie zrobiłeś, musisz zainicjować nowe repozytorium Git. Aby to zrobić, użyj komendy:

bash

git init

Ta komenda tworzy nowe, puste repozytorium w bieżącym katalogu. W katalogu pojawi się ukryty folder. git, który zawiera wszystkie pliki kontrolujące wersje.

2.2 Sprawdzanie statusu repozytorium

Po wprowadzeniu zmian do swojego projektu warto sprawdzić status repozytorium. Możesz to zrobić za pomocą komendy:

bash

git status

Komenda git status wyświetli informacje o bieżących zmianach, plikach dodanych do staged (do zatwierdzenia) oraz tych, które są jeszcze nieśledzone.

2.3 Dodawanie plików do staged (git add)

Aby dodać pliki do obszaru staged i przygotować je do zatwierdzenia (commit), użyj komendy:

bash

git add nazwa_pliku

Na przykład, jeśli chcesz dodać plik README.md, wpisz:

bash

git add README.md

Jeżeli chcesz dodać wszystkie zmodyfikowane i nowe pliki w repozytorium, możesz użyć:

bash

git add.

2.4 Tworzenie commitu (git commit)

Commit to kluczowa operacja w Git, która zapisuje zmiany do repozytorium. Aby utworzyć commit, użyj komendy:

bash

git commit -m „Krótki opis wprowadzonych zmian”

Przykład:

bash

git commit -m „Dodano nowy plik README”

Flaga -m pozwala na dodanie wiadomości opisującej zmiany, co ułatwia śledzenie historii projektu.

2.5 Wyświetlanie historii zmian (git log)

Aby zobaczyć historię commitów w swoim repozytorium, możesz użyć komendy:

bash

git log

Komenda ta wyświetli listę commitów, w tym ich identyfikatory, autorów, daty oraz wiadomości opisujące zmiany. Aby wyświetlić historię w bardziej czytelnej formie, użyj:

bash

git log — oneline — graph — decorate

Dzięki temu otrzymasz skondensowaną wersję historii, w której widać również strukturę gałęzi projektu.

2.6 Ignorowanie plików (plik. gitignore)

Często w projekcie znajdują się pliki, które nie powinny być śledzone przez Git (np. pliki tymczasowe, zrzuty pamięci, pliki konfiguracji lokalnej). W takim przypadku warto stworzyć plik. gitignore i dodać do niego wzory nazw plików i katalogów, które mają być ignorowane. Przykładowa zawartość pliku. gitignore:

bash

# Ignoruj pliki tymczasowe edytora

*.swp

*.tmp

# Ignoruj katalog build

/build/

Plik. gitignore pozwala na efektywne zarządzanie tym, które pliki i katalogi mają być ignorowane przez Git.

2.7 Wycofywanie zmian przed commitem (git reset)

Jeśli dodasz plik do staged za pomocą git add, ale zmienisz zdanie i chcesz go usunąć z obszaru staged, użyj komendy:

bash

git reset nazwa_pliku

Ta komenda cofnie plik do statusu nieśledzonego, co pozwala na wprowadzenie dalszych zmian przed commitowaniem.

2.8 Usuwanie plików z repozytorium (git rm)

Jeśli chcesz usunąć plik zarówno z repozytorium, jak i z obszaru roboczego, użyj komendy:

bash

git rm nazwa_pliku

git commit -m „Usunięto plik nazwa_pliku”

Jeśli chcesz usunąć plik tylko z repozytorium, ale pozostawić go w obszarze roboczym, dodaj opcję — cached:

bash

git rm — cached nazwa_pliku

git commit -m „Usunięto plik z repozytorium”

2.9 Sprawdzanie różnic między zmianami (git diff)

Aby sprawdzić, jakie zmiany zostały wprowadzone w plikach przed commitowaniem, możesz użyć komendy:

bash

git diff

Komenda ta wyświetla szczegółowe różnice pomiędzy bieżącym stanem plików a ostatnim commitem.

2.10 Podsumowanie podstawowych komend

Podstawowe komendy Git omówione w tym rozdziale to:

git init — inicjalizacja nowego repozytorium

git status — sprawdzanie statusu repozytorium

git add — dodawanie plików do obszaru staged

git commit — zapisywanie zmian w repozytorium

git log — wyświetlanie historii commitów

git diff — sprawdzanie różnic między zmianami

git rm — usuwanie plików z repozytorium

Opanowanie tych komend pozwoli ci efektywnie zarządzać swoim kodem i jego wersjami.

Podsumowanie

W tym rozdziale poznaliśmy podstawowe komendy Git, które są niezbędne do codziennej pracy z repozytorium. Teraz potrafisz inicjować repozytorium, dodawać pliki, tworzyć commity, zarządzać historią zmian oraz korzystać z pliku. gitignore. W kolejnych rozdziałach zajmiemy się bardziej zaawansowanymi funkcjami Git, takimi jak praca z gałęziami i zarządzanie zdalnymi repozytoriami.

Rozdział 3: Praca z repozytorium lokalnym

W tym rozdziale skupimy się na zarządzaniu repozytorium lokalnym. Dowiesz się, jak tworzyć, klonować repozytoria, zarządzać ich strukturą oraz jak ignorować pliki, które nie powinny być śledzone przez Git.

3.1 Tworzenie nowego repozytorium lokalnego

Aby utworzyć nowe repozytorium lokalne, przejdź do katalogu, w którym chcesz je utworzyć, i wpisz:

bash

mkdir moj-projekt

cd moj-projekt

git init

Komenda git init inicjuje nowe repozytorium Git w bieżącym katalogu. Tworzy ukryty katalog. git, który zawiera wszystkie pliki niezbędne do zarządzania wersjami projektu.

3.2 Klonowanie istniejącego repozytorium

Klonowanie repozytorium jest jednym z najczęstszych sposobów na rozpoczęcie pracy nad istniejącym projektem. Aby sklonować repozytorium zdalne (np. z GitHub), użyj komendy:

bash

git clone https://github.com/uzytkownik/nazwa-repozytorium.git

Po wykonaniu tej komendy Git pobierze całą historię projektu i utworzy jego lokalną kopię w katalogu o nazwie nazwa-repozytorium.

Opcjonalnie możesz określić inny katalog docelowy, w którym ma zostać utworzone repozytorium:

bash

git clone https://github.com/uzytkownik/nazwa-repozytorium.git moj-projekt

To utworzy katalog moj-projekt i umieści tam zawartość repozytorium.

3.3 Struktura katalogu repozytorium Git

Repozytorium Git składa się z kilku kluczowych elementów:

Obszar roboczy (Working Directory): Zawiera wszystkie pliki projektu, nad którymi aktualnie pracujesz.

Indeks (Staging Area): Jest to tymczasowe miejsce, gdzie umieszczasz zmiany za pomocą komendy git add, zanim je zatwierdzisz (commit).

Lokalne repozytorium: Zawiera historię wszystkich commitów, które zostały zatwierdzone do tej pory.

Praca z tymi trzema elementami pozwala na precyzyjne zarządzanie zmianami w projekcie i ich wprowadzanie do repozytorium.

3.4 Ignorowanie plików z. gitignore

Czasami istnieją pliki, które nie powinny być śledzone przez Git, na przykład pliki konfiguracyjne, pliki tymczasowe lub katalogi generowane automatycznie. Aby wykluczyć te pliki z kontroli wersji, należy użyć pliku. gitignore.

Tworzenie pliku. gitignore

W głównym katalogu repozytorium utwórz plik. gitignore i dodaj do niego wzory nazw plików i katalogów, które mają być ignorowane. Przykładowy. gitignore:

bash

# Ignoruj pliki tymczasowe systemu operacyjnego

*.log

*.tmp

# Ignoruj katalogi generowane przez narzędzia budujące

/build/

/node_modules/

# Ignoruj pliki konfiguracyjne

*.env

Dzięki plikowi. gitignore te pliki i katalogi nie będą śledzone przez Git, nawet jeśli zostaną utworzone lub zmienione w obszarze roboczym.

3.5 Wyświetlanie listy zdalnych repozytoriów

Aby zobaczyć, z jakimi zdalnymi repozytoriami jest połączone twoje repozytorium lokalne, użyj komendy:

bash

git remote -v

Wyświetli ona listę zdalnych repozytoriów oraz adresy URL, które są z nimi powiązane. Najczęściej spotykanym zdalnym repozytorium jest origin, które domyślnie wskazuje na miejsce, z którego repozytorium zostało sklonowane.

3.6 Dodawanie nowego zdalnego repozytorium

Jeśli chcesz dodać nowe zdalne repozytorium do swojego projektu, użyj komendy:

bash

git remote add origin https://github.com/uzytkownik/nazwa-repozytorium.git

W tym przypadku origin to nazwa zdalnego repozytorium. Możesz używać innych nazw, ale origin jest standardem.

3.7 Aktualizowanie repozytorium zdalnego

Kiedy pracujesz nad projektem w zespole, musisz regularnie synchronizować swoje zmiany z repozytorium zdalnym. Aby pobrać najnowsze zmiany z repozytorium zdalnego, użyj:

bash

git fetch origin

Komenda git fetch pobiera wszystkie zmiany z repozytorium zdalnego, ale nie łączy ich jeszcze z twoją bieżącą gałęzią. Aby połączyć te zmiany z twoją gałęzią, użyj:

bash

git merge origin/main

Alternatywnie, możesz użyć jednego polecenia, które jednocześnie pobiera i łączy zmiany:

bash

git pull origin main

3.8 Wysyłanie zmian do repozytorium zdalnego

Aby wysłać swoje zmiany (commity) do repozytorium zdalnego, użyj komendy:

bash

git push origin main

Tutaj main to nazwa gałęzi, którą wysyłasz do repozytorium zdalnego. Jeśli gałąź, do której wysyłasz zmiany, nie istnieje jeszcze na repozytorium zdalnym, Git utworzy ją automatycznie.

3.9 Podsumowanie pracy z repozytorium lokalnym

W tym rozdziale dowiedzieliśmy się, jak:

Tworzyć i klonować repozytoria lokalne

Zarządzać strukturą repozytorium Git

Ignorować niepożądane pliki za pomocą. gitignore

Zarządzać zdalnymi repozytoriami, w tym pobierać i wysyłać zmiany

Opanowanie tych umiejętności pozwala efektywnie zarządzać repozytorium lokalnym oraz współpracować z innymi programistami poprzez repozytoria zdalne.

Podsumowanie

W tym rozdziale nauczyliśmy się podstaw pracy z repozytorium lokalnym w Git. Teraz jesteś gotowy, aby lepiej zarządzać swoim projektem oraz synchronizować zmiany z repozytoriami zdalnymi. W kolejnych rozdziałach zajmiemy się bardziej zaawansowanymi tematami, takimi jak praca z gałęziami oraz łączenie zmian.

Rozdział 4: Historia i śledzenie zmian

W tym rozdziale skupimy się na analizie historii zmian w repozytorium Git. Nauczysz się, jak przeglądać historię commitów, śledzić zmiany w plikach oraz jak cofać się do wcześniejszych wersji projektu. Praca z historią Git jest kluczowa do rozumienia, co i kiedy zostało zmienione, co ułatwia debugowanie i rozwijanie projektu.

4.1 Wyświetlanie historii commitów

Podstawową komendą do przeglądania historii commitów w Git jest:

bash

git log

Komenda ta wyświetli szczegółową listę commitów w kolejności od najnowszego do najstarszego. Informacje zawarte w logu obejmują identyfikator commitu, autora, datę oraz wiadomość opisującą zmiany.

Jeśli chcesz zobaczyć historię w bardziej kompaktowej formie, możesz użyć opcji:

bash

git log — oneline

Wynik będzie zawierał tylko skrócone identyfikatory commitów oraz ich opisy, co ułatwia szybkie przeglądanie.

4.2 Wyświetlanie różnic między commitami

Aby zobaczyć, co dokładnie zmieniło się między dwoma commitami lub od ostatniego commitu, możesz użyć komendy git diff. Wyświetla ona różnice w plikach między bieżącym stanem a ostatnim commitem.

bash

git diff

Jeśli chcesz porównać zmiany między dwoma określonymi commitami, użyj:

bash

git diff commit1 commit2

Zamień commit1 i commit2 na odpowiednie identyfikatory commitów, aby zobaczyć różnice między nimi.

4.3 Śledzenie zmian w konkretnym pliku

Aby zobaczyć historię zmian wprowadzonych do konkretnego pliku, użyj komendy:

bash

git log — nazwa_pliku

Dzięki tej komendzie wyświetlisz listę commitów, które wpłynęły na dany plik, co pozwala na śledzenie jego ewolucji w czasie.

4.4 Przeglądanie zmian w plikach z git blame

Narzędzie git blame pozwala dokładnie zobaczyć, kto zmodyfikował daną linię w pliku oraz w którym commicie to się stało. Aby użyć tej komendy, wpisz:

bash

git blame nazwa_pliku

Wynik pokaże każdą linię pliku z informacją o commitcie, który wprowadził zmianę, oraz o autorze tej zmiany. Jest to bardzo przydatne przy debugowaniu i analizie kodu.

4.5 Cofanie zmian za pomocą git checkout

Czasami potrzebujesz tymczasowo cofnąć zmiany wprowadzone do pliku, aby przywrócić go do stanu z ostatniego commitu. Możesz to zrobić za pomocą komendy:

bash

git checkout nazwa_pliku

Ta komenda przywraca wersję pliku do ostatnio zatwierdzonego stanu, usuwając wszystkie lokalne zmiany.

4.6 Cofanie commitów z git revert

Aby cofnąć zmiany wprowadzone przez określony commit, ale jednocześnie zachować historię repozytorium, użyj komendy:

bash

git revert commit_id

Zamień commit_id na identyfikator commitu, który chcesz cofnąć. Komenda git revert tworzy nowy commit, który odwraca zmiany wprowadzone przez wskazany commit, nie zmieniając historii projektu.

4.7 Resetowanie historii za pomocą git reset

W przypadku gdy chcesz całkowicie usunąć historię commitów i cofnąć stan repozytorium do wcześniejszej wersji, możesz użyć komendy:

bash

git reset — hard commit_id

Opcja — hard powoduje, że Git resetuje zarówno obszar roboczy, jak i obszar staged do stanu wskazanego commitu, co może prowadzić do utraty zmian, które nie zostały zatwierdzone.

Uwaga: Należy używać git reset — hard ostrożnie, ponieważ może to prowadzić do trwałej utraty danych.

4.8 Odzyskiwanie utraconych commitów za pomocą git reflog

Koniec darmowego fragmentu książki.

Zachęcamy do zakupu pełnej wersji.