Git i GitHub – własne repozytorium, clone, fork i pull request

 Git i GitHub – instalacja, założenie konta

Jeżeli jeszcze tego nie wiesz lub masz niewielkie pojęcie o tym, jakie Git i GitHub dają możliwości, to zapraszam Cię do lektury artykułu „Co to jest GitHub i do czego służy” (omawiam w nim też krótko Gita).

Aby móc przećwiczyć wskazówki z tego artykułu, będziesz potrzebować:

• Gita – tu znajdziesz stronę instalacji
• GitHuba – tu założysz konto.

W poniższych dwóch filmach zobaczysz instalację Gita na Macu i Windowsie, jego prostą konfigurację (ustawienie nazwy użytkownika i adresu e-mail) oraz jedną z opcji stworzenia swojego pierwszego repozytorium zdalnego.

Co ciekawe, autor tych wideo używa programu Visual Studio Code do sklonowania repozytorium z GitHuba (czyli stworzenia repozytorium lokalnego na podstawie repozytorium zdalnego).

My zrobimy to zaraz za pomocą programu Git Bash (czyli tego, który zainstalujesz lub już zainstalowałeś), dzięki czemu poznasz dokładniej jego działanie.

• Instalacja Gita w systemie Windows
• Instalacja Gita w systemie MacOS.

 Od repozytorium lokalnego do zdalnego (git init, add, commit, push)

Repozytorium lokalne już zapewne masz. Wybierz lub stwórz na swoim komputerze dowolny katalog: możesz mieć tam tylko plik HTML albo tylko plik JS. Możesz mieć nawet jedynie katalog z zasobami (np. obrazami).

Oczywiście nic nie stoi na przeszkodzie, aby był to katalog z jakimś projektem, lecz na razie – póki nie poznaliśmy możliwości pliku .gitignore – lepiej wybierz katalog z jednym lub kilkoma podstawowymi plikami.

Chcemy, aby nasze pliki były bezpieczne (niezależne od awarii lokalnego dysku) – dlatego warto przechowywać je na repozytorium zdalnym. Jak to zrobić? Użyjemy do tego programu Git Bash.

 Zainicjowanie repozytorium Git (lokalnego)

1. Kliknij prawym przyciskiem myszy w swój katalog.
2. Wybierz z menu kontekstowego pozycję „Git Bash Here” – dzięki temu od razu znajdziesz się w tym katalogu (czyli w konsoli programu zobaczysz ścieżkę do katalogu).
   Istnieją też inne sposoby (np. otwarcie katalogu bezpośrednio z Git Basha za pomocą komendy cd ścieżka-do-katalogu lub użycie terminala w VS Code), ale nie będziemy się teraz na nich skupiać – wszystkie te drogi prowadzą do tego samego punktu.
   
3. Zainicjuj repozytorium Gita. Po prostu wpisz w konsoli komendę:
   git init
   Od teraz będziesz mieć możliwość korzystania z dobroci tego programu, czyli np. śledzenia zmian w kodzie. Ale na razie skupmy się na przeniesieniu plików na GitHuba.
4. Dodaj pliki do tzw. staging area. Jest to „miejsce”, w którym znajdują się pliki z zaakceptowanymi zmianami oczekujące na commita (o tym zaraz). W konsoli wpisz:
   git add .
   Kropka oznacza, że dodajesz do staging area wszystkie pliki z katalogu. Jeżeli chciałbyś dodać jeden plik lub kilka, wpisz w miejscu kropki ścieżki do tych plików, np.:
   git add index.html app.js ./styles/main.css
5. Stwórz commita – czyli zapisz zmiany w Gicie (zmianą jest tutaj utworzenie plików: dla Gita nie ma różnicy, czy masz je na dysku lokalnym od dawna, dla niego są nowe) i odpowiednio je opisz. Użyj komendy:
   git commit -m "add index.html"
   Flaga -m oznacza opis commita (m jak message), możesz więc wpisać cokolwiek, co opisuje Twoje działania. Może u Ciebie jest to dodanie pliku app.js albo wszystkich plików projektu (wiadomość mogłaby wyglądać np. tak:
   "add project files").

Nie zamykaj jeszcze Git Basha. Zaraz się przyda.

Dobrze, teraz wszystko jest gotowe do przesłania plików na repozytorium zdalne. Stwórzmy je więc.

 Stworzenie repozytorium na GitHubie (zdalnego)

Pliki z naszego repozytorium lokalnego musimy mieć dokąd przesłać, dlatego stworzymy repozytorium zdalne na GitHubie.

1. Wejdź na swój profil na GitHubie i utwórz nowe repozytorium. Możesz to zrobić np. wchodząc w zakładkę „Your repositories” i klikając przycisk „New” lub szybciej: na górnym pasku klikając ikonę plusika i wybierając „New repository”.
   
2. Otworzy Ci się strona „Create a new repository”:
   1. uzupełnij nazwę repozytorium (Repository name)
   2. wybierz, czy ma to być repo prywatne, czy publiczne
3. Nic więcej nie jest Ci na razie potrzebne. Kliknij „Create repository”
   
4. Na następnej stronie masz parę opcji. Ponieważ my chcemy przenieść pliki z repozytorium lokalnego, wybieramy ostatnią pozycję. Skopiuj widoczne tam komendy.
   
5. Wklej je do konsoli programu Git Bash, którego przed chwilą używałeś (uwaga: na Windowsie nie wkleisz nic za pomocą Ctrl+V, tutaj użyj kombinacji Shift+Insert lub prawym klawiszem myszy otwórz menu kontekstowe i wybierz „Paste”). Kliknij Enter.
   
   Co oznaczają te trzy komendy?
   • git remote add origin (…) – tworzy repozytorium zdalne „origin”, Dzięki temu potem możesz używać tej nazwy zamiast wpisywać cały URL (czyli origin zamiast np. git@github.com:name/new-repo.git)
   • git branch -M main – Twoje zmiany będą zapisywane na gałęzi głównej „main” (właśnie teraz przenosisz się na nią za pomocą flagi -M). Kiedyś gałąź ta nazywała się „master” – spotkasz ją jeszcze na wielu repozytoriach
   • git push -u origin main – oznacza: zapisz zmiany z repozytorium lokalnego na repozytorium zdalnym „origin” na jego gałęzi głównej „main”.
6. Gotowe. Odśwież stronę na GitHubie – powinieneś zostać przekierowany do swojego repozytorium zdalnego i znaleźć tam przesłane (pushowane) pliki.

 Od repozytorium zdalnego do lokalnego – github fork i git clone

Nie będziemy teraz rozpatrywać sytuacji, w której współpracujesz w zespole i robisz pushe do jednej z gałęzi. Są to tematy bardziej zaawansowane, a my skupiamy się na początku nauki programowania.

Dlaczego miałbyś tworzyć repozytorium lokalne na podstawie zdalnego? Przykładowo po to, by:

• mieć gotowe środowisko pracy (pliki, paczki, konfiguracje), np. do projektu tworzonego w materiałach z kursu,
• wykonać zadania programistyczne (w przyszłości także te rekrutacyjne),
• sprawdzić w ramach nauki działanie czyjegoś projektu,
• prześledzić kod omawianego np. w tutorialu rozwiązania, gdy u Ciebie coś nie działa.

Sklonowanie repozytorium zdalnego na dysk lokalny jest prostsze niż omawiana przed chwilą odwrotna sytuacja. Mamy jednak dwie drogi, zależnie od tego, co planujemy:

• Jeśli chcesz jedynie ściągnąć repozytorium i nie masz zamiaru potem korzystać z repozytorium zdalnego (czyli np. przesyłać tam zmian w kodzie), możesz ominąć forkowanie (punkt 2 i 3).
• Jeśli chcesz korzystać z repozytorium zdalnego tak, jakby było Twoje (czyli móc bez przeszkód pushować zmiany z repo lokalnego / pobierać je z repo zdalnego) lub mieć możliwość wykonania pull requesta (o tym za chwilę), to najpierw musisz wykonać forka.

Forkowanie i klonowanie (fork i clone), czyli własne repozytorium lokalne na podstawie czyjegoś repozytorium zdalnego:

1. Wejdź na stronę dowolnego repozytorium publicznego. Możesz skorzystać np. z mojego repozytorium github-helloworld.
2. Kliknij przycisk „Fork”.
   
3. Zostaniesz przeniesiony do niemal identycznie wyglądającego repozytorium, ale… będzie to już Twoje repozytorium – spójrz na górny pasek z nazwą użytkownika.
   
4. Kliknij przycisk „Code” i skopiuj adres URL z wyświetlonego okienka. Uwaga: adres ten musi zawierać Twoją nazwę użytkownika. Jeśli zawiera nazwę autora oryginalnego repozytorium, to znaczy, że nie znajdujesz się na swoim sforkowanym repo.
   
5. Otwórz w Git Bashu katalog, w którym chcesz umieścić repozytorium (przypomnienie: kliknij prawym klawiszem na ten katalog i wybierz „Git Bash Here” z menu kontekstowego).
6. Wpisz komendę:
   git clone https://to-jest-skopiowany-adres-url
7. W katalogu, w którym chciałeś umieścić repo, powinien pojawić się nowy katalog z nazwą sklonowanego repozytorium.
8. Uwaga: Jeżeli na tym etapie chcesz podjąć jakieś działania z poziomu konsoli (np. uruchomić komendę instalującą paczki w tym repozytorium), pamiętaj, by najpierw przejść do nowego katalogu! Samo sklonowanie repo nie przekierowuje Cię do niego (nadal jesteś na poziomie katalogu nadrzędnego). Aby przejść do nowego katalogu, użyj komendy:
   cd nazwa-katalogu-z-repo

Ciekawostka: zamiast z Git Bashem możesz pracować z terminalem w programie VS Code (lub innym edytorze kodu – zwykle ta opcja jest wbudowana). Czyli zamiast otwierać swoje lokalne repo za pomocą programu Git Bash, możesz otworzyć je w VSC (uwaga: zawsze upewnij się, że to katalog projektu, a nie np. katalog nadrzędny).

Aby otworzyć terminal w VS Code, wystarczy wybrać z menu opcję Terminal > New Terminal lub skorzystać ze skrótu klawiszowego Ctrl+`.

W terminalu tym wpisujesz komendy dokładnie tak samo, jak w Git Bashu (różnica jest taka, że Ctrl+V działa).

 Pull request

Jesteśmy na etapie, w którym już sforkowałeś i sklonowałeś np. zadanie z kursu. Wykonałeś je u siebie na komputerze, a teraz chcesz przesłać zmiany do repozytorium zdalnego i powiadomić o nich autora
repozytorium (np. Twojego mentora) – aby mógł zapoznać się ze zmianami i je skomentować (czyli wykonać code review).

Upewnij się, że zacommitowałeś (czyli zapisałeś w historii śledzenia zmian) wszystkie modyfikacje kodu i dodane pliki – komendy „git commit” i „git add” już poznałeś – oraz że je pushowałeś (czyli wysłałeś je na repozytorium zdalne za pomocą komendy git push).

Jeśli to zrobiłeś, to na swoim sforkowanym repo na GitHubie zobaczysz informację o łącznej liczbie commitów, a przy zmienionych plikach znajdziesz wiadomości przypisane do ostatnich zmian.

Jeżeli używasz VS Code, to możesz wykorzystać jego funkcję, która ułatwia dodawanie plików do staging area, robienie commitów i pushów bez korzystania z komend w konsoli. Jeśli Cię to zainteresowało,
to polecam artykuł o commitach i pushach w VS Code.

Czyli jeszcze raz po kolei:

1. Zmiany w swoim lokalnym repozytorium zacommituj i pushuj (git push) na zdalne repo.
2. Wejdź na GitHuba na swoje sforkowane repozytorium zdalne. Przy zmienionych plikach powinieneś widzieć nazwy ostatnich commitów.
   Jeśli ich nie ma, to albo jesteś na niewłaściwym repo (np. u autora projektu zamiast na swoim forku), albo nie wykonałeś pusha.
3. Kliknij „Contribute” i wybierz „Open pull request”.
   
4. Wyświetli Ci się strona pull requesta. Nadaj mu tytuł, który opisuje Twoje zmiany w kodzie. Możesz też dodać obszerniejszy komentarz, np. o tym, na co autor repo powinien zwrócić szczególną uwagę. Następnie kliknij „Create pull request”.
   
5. Aby zweryfikować, czy Twój PR na pewno trafił na listę, przejdź do zakładki „Pull requests”. Tam powinieneś go znaleźć.
   

Teraz zmiany, których dokonałeś, mogą zostać skomentowane lub zmergowane (połączone przez właściciela repo) z kodem i plikami z repozytorium. Listę otwartych przez siebie pull requestów znajdziesz na
podstronie swojego konta: „Pull requests”. Jeżeli autor repo ustosunkował się do Twojego kodu w komentarzach, przy swoim PR zobaczysz dymek z liczbą.

 Git nie działa? Sprawdź te pułapki

Powyżej wspominałem w paru miejscach o błędach, które często zdarzają się początkującym programistom. Tutaj je podsumuję. Jeśli coś nie działa Ci podczas prostego tworzenia, klonowania czy forkowania
repozytorium lub otwierania pull requesta, przejrzyj tę listę.

 Nie mogę pushować zmian

Upewnij się, że sklonowałeś własne repozytorium lub własnego forka. Być może przypadkowo sklonowałeś cudze repozytorium. W adresie URL wklejanym do komendy musi widnieć nazwa Twojego profilu:
git clone https://github.com/twojaNazwa/twoje-repo.git

 Nie mogę dodawać ani commitować zmian

Sprawdź, czy na 100% znajdujesz się w katalogu projektu. Bardzo prawdopodobne, że tak nie jest, jeśli podczas próby użycia komend dla Gita widzisz taki błąd:

fatal: not a git repository (or any of the parent directories): .git

Po sklonowaniu repozytorium do katalogu nadrzędnego często zapominamy przejść „w głąb” – do sklonowanego repo. Z poziomu katalogu nadrzędnego (w którym znajdujesz się zaraz po sklonowaniu do niego repozytorium z GitHuba) zrobisz to za pomocą komendy:

cd nazwa-sklonowanego-repo

Możesz też otworzyć nowo utworzony katalog ze sklonowanym repozytorium bezpośrednio w Git Bashu lub w VS Code.

 Nie mogę zainstalować paczek (komenda: npm i)

Być może widzisz poniższy błąd:

npm ERR! enoent ENOENT: no such file or directory, open 'C:UsersTwojUserDesktopkatalog-nadrzednypackage.json'

npm ERR! enoent This is related to npm not being able to find a file.

Musimy założyć, że wiesz, co robisz i że w sklonowanym repozytorium rzeczywiście jest plik, który umożliwia instalację paczek (package.json).

Jeśli tak, to prawdopodobnie popełniłeś błąd, o którym piszę w punkcie powyżej: po klonowaniu nie przeszedłeś do nowo utworzonego katalogu sklonowanego repozytorium.

Zobaczysz to w ścieżce błędu, która będzie wyglądała np. tak:

'C:UsersTwojUserDesktopkatalog-nadrzednypackage.json'

Zamiast tak:

'C:UsersTwojUserDesktopkatalog-nadrzednykatalog-sklonowanego-repopackage.json'

Przejdź do punktu „Nie mogę dodawać ani commitować zmian”, by rozwiązać problem.

 Moich commitów nie ma na repozytorium na GitHubie

Upewnij się, że:

• wykonałeś commity i zrobiłeś pusha:
  git push
• na GitHubie wszedłeś na właściwie repozytorium. Często przez pomyłkę trafiamy na repozytorium oryginalne, a nie na nasze sforkowane. Sprawdź nazwę użytkownika tego repozytorium (musi mieć Twoją nazwę, a nie nazwę autora, od którego forkowałeś).

 Nie jestem pewien, czy mój pull request dotarł do autora

Na swoim profilu na GitHubie wejdź w zakładkę „Pull Requests” – tam znajduje się lista otworzonych przez Ciebie pull requestów.

Możesz też wejść do pull requestów przypisanych do danego repozytorium. Wówczas na GitHubie ze strony oryginalnego repozytorium wejdź w zakładkę „Pull requests”. Znajdziesz tam wszystkie pull requesty (także te wykonane przez innych programistów).

 Mojego pull requesta nie ma na liście „Pull requests”

Jeżeli wykonywałeś tego pull-requesta jakiś czas temu i wracasz do niego teraz (bo np. wcześniej czekałeś na komentarze lub zmergowanie), to możesz nie znaleźć go na liście otwartych pull requestów. Zobacz, czy nie został zakończony (zakładka „Closed”).