Fundamenty Git i GitHub: Przewodnik wprowadzający w technologię rozproszonej kontroli wersji Git oraz zarządzanie zdalnym repozytorium za pomocą GitHub

Tutorial wprowadzający do technologii Git i GitHub, zawierający fundamenty pozwalające rozpocząć pracę nad projektem z wykorzystaniem rozproszonej kontroli wersji Git oraz zarządzania zdalnym repozytorium za pomocą GitHub.

Spis treści:

• Wprowadzenie do Git & GitHub
• Konfiguracja klucza SSH do autoryzacji w GitHubie
• Przygotowanie projektu do przesłania na GitHub
  • Polecenie git status
  • Konfiguracja użytkownika i email w Gicie
• Przesyłanie projektu do repozytorium GitHub
  • Polecenie git push
• Podsumowanie

Wprowadzenie do Git & GitHub

Zdalne repozytorium umożliwia dostęp do kodu projektu i jego kontroli wersji przez internet.

Standardem w branży są dwa następujące serwisy, tj. GitHub oraz Bitbucket.

https://github.com/ – oferuje kompletnie darmowe konto. Platforma GitHub udostępnia również płatne usługi, jednak jako indywidualni deweloperzy raczej nie będziemy z nich korzystać.

• Tworzenie nowego projektu – New repository
• Nazwa projektu – Repository name

• Public – każdy może zobaczyć Twoje pliki, wybierz wówczas gdy nie zamierzasz przechowywać żadnych wrażliwych danych.
• Private – tylko Ty i osoby, którym przyznasz dostęp, mogą zobaczyć Twoje pliki. Wybierz tę opcję, gdy pracujesz nad projektem zawierającym wrażliwe dane, kody źródłowe lub gdy chcesz zachować prywatność swojej pracy.

Create repository – tworzenie nowego projektu.
W tym momencie powinniśmy uzyskać dostęp do pustej kanwy naszego projektu. Pojawia się teraz pytanie: jak w ogóle wgrać nasze pliki na GitHub, jeśli wcześniej nie robiliśmy czegoś takiego?

Przechodzimy w linii komend do folderu naszego projektu, a następnie inicjalizujemy repozytorium Git:

git init

Następnie musimy się autoryzować, ponieważ w przeciwnym razie każdy mógłby przesyłać pliki do naszego projektu. W przeglądarce logowanie się do konta GitHub jest intuicyjne, ale jak to zrobić w terminalu?

Konfiguracja klucza SSH do autoryzacji w GitHubie

Standardem w branży do autoryzacji w serwisach takich jak GitHub jest klucz SSH.

Pozostając w terminalu, możemy wygenerować klucz SSH na naszym komputerze za pomocą poniższej komendy (niezależnie od tego, czy korzystamy z Maca czy Windowsa):

ssh-keygen -t ed25519 -C "address@mail.com"

-t (type) – określa typ algorytmu szyfrowania używanego do generowania klucza. W tym przypadku ed25519 to nowoczesny, bezpieczny i szybki algorytm asymetryczny. Jest to aktualnie rekomendowany standard zamiast starszego RSA.

-C (comment) – dodaje komentarz do klucza, najczęściej adres e-mail. Komentarz ten służy do identyfikacji klucza i nie wpływa na jego funkcjonowanie. Dzięki niemu łatwiej rozpoznasz, do którego konta GitHub należy dany klucz, zwłaszcza jeśli generujesz wiele kluczy dla różnych kont.

Upewnij się, że adres e-mail odpowiada temu, który powiązany jest z Twoim kontem GitHub.

Następnie zostaniesz poproszony o potwierdzenie, czy wygenerowany klucz zapisać w katalogu domyślnym. Możesz to potwierdzić, naciskając Enter.

Enter file in which to save the key (/Users/szymurai/.ssh/id_ed25519):

Passphrasę możesz również pozostawić pustą.

Enter passphrase for "/Users/szymurai/.ssh/id_ed25519" (empty for no passphrase):
Enter same passphrase again:

Powyższa komenda utworzy dwa nowe pliki na Twoim komputerze.

Klucz publiczny służy do weryfikacji wiadomości podpisanej kluczem prywatnym. Dlatego klucz publiczny należy przesłać do GitHuba. Wchodzimy w ustawienia konta, a następnie z lewego menu bocznego wybieramy opcję „SSH and GPG keys”. Następnie klikamy „New SSH key”.

Na stronie deklaracji nowego klucza wypełniamy odpowiednie pola:

• Title (Nazwa): nazwa Twojego komputera, np. MacBook-username
• Key type (Typ klucza): Authentication Key
• Key (Klucz): zawartość publicznego klucza, który wygenerowaliśmy w poprzednich krokach

Po wypełnieniu powyższych pól klikamy przycisk „Add SSH key”, aby zapisać klucz w ustawieniach GitHuba.

Gratulacje! Jeśli wszystko przebiegło pomyślnie zgodnie z opisem i filmami, publiczny klucz został zapisany w ustawieniach GitHuba!

Przygotowanie projektu do przesłania na GitHub

Od teraz możesz zacząć zarządzać swoimi projektami za pomocą GitHuba.

W celach demonstracyjnych utworzymy przykładowy projekt o nazwie „test” i prześlemy go do nowo utworzonego repozytorium na GitHubie.

W pierwszej kolejności utwórz nowy katalog w wierszu poleceń:

mkdir test

Następnie przejdź do nowo utworzonego katalogu:

cd test

Na koniec zainicjalizuj w nim nowe repozytorium Git:

git init

Dodatkowo stworzymy w katalogu projektu przykładowy plik. Niech to będzie plik index.html z podstawową strukturą HTML. W tym celu, wciąż pozostając w oknie terminala, możemy wpisać, a następnie wywołać następujące po sobie polecenia:

touch index.html
code index.html

Po wpisaniu i wywołaniu polecenia code index.html powinien otworzyć się w programie Visual Studio Code wskazany plik.

Wewnątrz pliku index.html możemy użyć skrótu klawiszowego ! + Tab, aby wygenerować podstawową strukturę HTML. Następnie zapiszmy nasz plik. Wówczas plik powinien pojawić się w stanie Untracked w Git. Oznacza to, że plik istnieje w katalogu projektu, ale Git go jeszcze nie śledzi. Git widzi pliki w naszym projekcie — aby sprawdzić, na jakim statusie są obecnie dane pliki, możemy użyć polecenia git status.

Polecenie git status

Polecenie git status wyświetli nam informacje o plikach w projekcie:

• Untracked files — nowe pliki, które nie zostały jeszcze dodane do Git (pojawią się w czerwonej sekcji)
• Staged files — pliki przygotowane do commitu, które zostały dodane za pomocą git add (pojawią się w zielonej sekcji)
• Modified files — pliki, które już śledzimy, ale zostały zmienione (pojawią się w czerwonej lub zielonej sekcji, w zależności od tego, czy je dodaliśmy do staging area)

Pliki, które Git nie wyświetli w git status:

Git nie pokazuje plików, które znajdują się w pliku .gitignore. Są to pliki specjalnie wykluczane z kontroli wersji, takie jak:

• Pliki tymczasowe i cache (node_modules, .DS_Store)
• Zmienne środowiskowe (.env)
• Pliki systemowe i IDE (.vscode, .idea)
• Artefakty budowania (dist, build)

Pliki już zatwierdzone i zacommitowane (bez zmian) również nie pojawią się w git status — Git pokazuje tylko zmiany względem ostatniego commitu.

W tym miejscu warto zwrócić uwagę, iż macOS tworzy pliki .DS_Store odpowiedzialne za przechowywanie informacji o wyglądzie i ustawieniach folderów (takie jak ikony, rozmiary okien i widok folderu). Dlatego warto przed przesłaniem naszego projektu na GitHub dodać te pliki do specjalnego pliku .gitignore, który mówi Gitowi, jakie pliki ma pominąć w procesie zarządzania wersjonowaniem naszego projektu.

Aby to zrobić, w katalogu projektu tworzymy plik .gitignore:

touch .gitignore

Następnie otwieramy go w edytorze:

code .gitignore

I dodajemy zawartość:

.DS_Store

Po zapisaniu pliku plik .DS_Store (jeśli istnieje w projekcie) nie będzie już śledzony przez Git i nie zostanie przesłany na GitHub.

Ważne: Plik .gitignore znajduje się w katalogu głównym projektu i jest zarządzany przez system Git. Warto pamiętać, że .gitignore jest częścią Gita, ale nie znajduje się wewnątrz katalogu .git — jest natomiast umieszczony wewnątrz głównego katalogu projektu, na równi z katalogiem .git.

Ponieważ pliki .DS_Store mogą się również pojawić w podkatalogach projektu, warto w pliku .gitignore zapisać je w następujący sposób:

**/.DS_Store

Gwiazdki **/ oznaczają, że Git będzie ignorować plik .DS_Store na wszystkich poziomach zagnieżdżenia — zarówno w głównym katalogu, jak i we wszystkich podkatalogach projektu.

Aby dodać plik do obszaru przygotowania (staging area), należy użyć polecenia git add index.html .gitignore lub git add . bądź git add -A (aby dodać wszystkie pliki). Po tym poleceniu plik zmieni status z Untracked na Staged (przygotowany do commitu).

Po dodaniu plików do staging area, aby wysłać zmiany do Gita, musimy użyć polecenia git commit, które wymaga od nas notatki (flaga -m — message). Po wpisaniu wiadomości zmiany będą zapisane w Gicie. Jednak zanim zrobimy swój pierwszy commit, upewnijmy się, czy mamy ustawiony użytkownika Gita i email globalnie bądź lokalnie w ramach bieżącego projektu — jest to wymagane przed wywołaniem polecenia git commit.

Konfiguracja użytkownika i email w Gicie

Aby śledzić autorów zmian w repozytorium, musisz skonfigurować swoje dane w Gicie. Możesz to zrobić na dwa sposoby, w zależności od potrzeb.

Konfiguracja globalna:

Jeśli chcesz używać tych samych danych dla wszystkich projektów na swoim komputerze, wykonaj:

git config --global user.name "Szymurai"
git config --global user.email "address@mail.com"

Konfiguracja lokalna:

Aby użyć różnych danych tylko dla konkretnego projektu, uruchom te polecenia w katalogu projektu (bez flagi --global):

git config user.name "Szymurai"
git config user.email "address@mail.com"

Weryfikacja ustawień:

Możesz sprawdzić, jakie dane są aktualnie skonfigurowane. Aby wyświetlić wszystkie ustawienia:

git config --list

Aby sprawdzić konkretne wartości:

git config user.name
git config user.email

Po ustawieniu użytkownika i emaila możesz teraz wykonać pierwszy commit:

git commit -m "initial commit"

Flaga -m pozwala na dodanie wiadomości commitu bezpośrednio w poleceniu. Jeśli chcesz napisać dłuższą wiadomość, możesz pominąć flagę -m, a Git otworzy domyślny edytor tekstowy.

---

Na tym etapie mamy utworzony nowy testowy projekt, zainicjalizowaną w nim kontrolę wersji Git, dodany nowy plik tj. index.html, który został przeniesiony z Untracked do Staged area, a następnie dodany do Gita za pomocą git commit. Ustawiliśmy również względem danego projektu nazwę i email użytkownika. Teraz przyszedł czas, aby przesłać nasz projekt wraz z konfiguracją Gita do zdalnego repozytorium na serwerze GitHub.

Przesyłanie projektu do repozytorium GitHub

Po utworzeniu nowego repozytorium na GitHub na stronie „Overview” tego projektu pojawi się sekcja „Quick Setup”, gdzie najbardziej będzie nas interesować polecenie linii poleceń git remote add origin.

Polecenie to dodaje tzw. zdalne repozytorium (remote) do naszego lokalnego projektu. Remote to po prostu adres serwera GitHub, gdzie będzie przechowywany nasz projekt.

Przykładowe polecenie wygląda następująco:

git remote add origin https://github.com/username/nazwa-projektu.git

Wyjaśnienie:

• git remote — polecenie zarządzania zdalnymi repozytoriami
• add — dodaj nowe zdalne repozytorium
• origin — nazwa zdalne repozytorium (standardowa nazwa dla głównego repozytorium na GitHub)
• https://github.com/username/nazwa-projektu.git — URL do repozytorium na GitHub

Po wykonaniu tego polecenia nasz lokalny projekt będzie połączony z repozytorium na GitHub. Możemy teraz wysyłać nasze commity na serwer za pomocą polecenia git push.

Polecenie git push

Polecenie git push przyjmuje dwa dodatkowe argumenty:

1. Origin (zdalne repozytorium):

origin to nazwa zdalne repozytorium, które wcześniej dodaliśmy za pomocą git remote add origin <URL>. Wskazuje, gdzie chcemy wysłać nasze zmiany — w tym przypadku na nasz projekt na GitHub. Możliwe jest posiadanie wielu zdalnych repozytoriów (np. origin, backup), ale origin to standardowa nazwa dla głównego repozytorium na GitHub.

2. Branch name (nazwa gałęzi):

branch name to nazwa gałęzi, na którą chcemy wysłać zmiany. Gałęzie to niezależne linie rozwoju projektu. Domyślnie każdy projekt ma gałąź główną — wcześniej była to master, teraz GitHub zaleca main. Wysyłając zmiany, musimy określić, na którą gałąź chcemy je wysłać.

Zmiana nazwy głównej gałęzi na main:

Przed wysłaniem naszego projektu do GitHub zaleca się zmienić nazwę głównej gałęzi na main. W tym celu używamy polecenia:

git branch -M main

Wyjaśnienie:

• git branch — polecenie zarządzające gałęziami
• -M — flaga zmieniająca nazwę gałęzi (M od „Move”)
• main — nowa nazwa dla głównej gałęzi

To polecenie zmieni aktualnie aktywną gałąź (zwykle master) na main.

Pełne polecenie git push:

Po zmianie nazwy gałęzi wykonujemy pełne polecenie:

git push -u origin main

Wyjaśnienie:

• git push — wysyłanie commitów na zdalne repozytorium
• -u (upstream) — ustawia lokalną gałąź main jako śledzącą zdalną gałąź origin/main
• origin — nazwa zdalne repozytorium (GitHub)
• main — nazwa gałęzi, na którą wysyłamy zmiany

Po wykonaniu tego polecenia Twój projekt zostanie wysłany na GitHub z wszystkimi commitami i konfiguracją Gita.

---

Następnie możemy wrócić na GitHub i odświeżyć stronę. Naszym oczom powinny się pokazać przesłane pliki z lokalnego komputera na zdalny serwer GitHub. Od teraz możemy współpracować w rozproszony sposób z innymi developerami danego projektu!

Podsumowanie

W powyższym przewodniku wprowadzającym w technologię Git i Github, zostały przedstawione następujące zagadnienia:

• wprowadzenie w platformę GitHub: zaawansowane narzędzie do zdalnego przechowywania i zarządzania projektami programistycznymi
• Konfiguracja autoryzacji SSH: proces generowania klucza SSH za pomocą algorytmu ed25519, jak i jego konfigurację w ustawieniach GitHub
• Lokalne zarządzanie projektem: obejmuje inicjalizację repozytorium Git, konfigurację pliku .gitignore dla wykluczenia niepożądanych plików systemowych, oraz podstawowe operacje Git takie jak git add, git status i git commit.
  integracja z GitHub. Konfiguracji danych użytkownika w ustawieniach Git.
• Integracja z GitHub: przedstawia proces łączenia lokalnego repozytorium ze zdalnym serwerem GitHub.

W kolejnych krokach pójdziemy głębiej — gałęzie, merge’e, pull requesty, ale to zostawmy sobie na kolejny dedykowany tutorial.