Kurs Git: utwórz repozytorium na GitHubie lub GitLabie i sklonuj je

Przypomnienie na start, rozwinięte we wstępie do kursu: Git działa na twojej maszynie, a GitHub i GitLab są tylko hostingiem repozytoriów Gita.

Do projektu śledzonego przez Gita i podpiętego do GitHuba lub GitLaba prowadzą dwie drogi, a wybór zależy wyłącznie od kolejności, w jakiej rzeczy powstają. Albo zdalne repozytorium już istnieje i je pobierasz: to klonowanie. Albo masz katalog na swojej maszynie i go publikujesz: to inicjalizacja, a potem push. Ten rozdział omawia oba przypadki.

Utworzenie zdalnego repozytorium

Na GitHubie służy do tego przycisk New na stronie głównej albo adres github.com/new. Na GitLabie — New project, a następnie Create blank project.

Przy tworzeniu podejmujesz trzy decyzje.

Nazwa. Staje się częścią adresu repozytorium. Trzymaj się małych liter i myślników, bez znaków diakrytycznych i spacji.

Widoczność. Publiczne znaczy czytelne dla wszystkich, łącznie z pełną historią, a więc i ze wszystkim, co przez pomyłkę do niej trafiło. Prywatne ogranicza dostęp do osób, które zaprosisz. W razie wątpliwości zacznij od prywatnego: przejście z prywatnego na publiczne jest natychmiastowe, a w drugą stronę nic już nie usunie tego, co zdążyło zostać skopiowane.

Plik README. Zaznacz to pole tylko wtedy, gdy zamierzasz repozytorium sklonować. Jeśli masz już katalog do opublikowania, zostaw repozytorium całkowicie puste, inaczej trzeba będzie pogodzić dwie historie, które nie mają ze sobą nic wspólnego.

Adres SSH czy adres HTTPS

Po utworzeniu repozytorium strona podsuwa adres w dwóch postaciach. Wskazują na to samo repozytorium i różnią się wyłącznie metodą uwierzytelniania.

Zwróć uwagę na różnicę w zapisie: adres SSH stawia dwukropek po nazwie hosta, a nie ukośnik. I przede wszystkim domena zmienia się razem z usługą. Podanie adresu github.com dla projektu hostowanego na GitLabie to klasyczny błąd kopiuj-wklej.

Jeśli masz już klucz SSH z poprzedniego rozdziału, weź adres SSH: nikt cię już o nic nie zapyta. Adres HTTPS wymaga osobistego tokenu dostępu, który menedżer poświadczeń może zapamiętać.

Pierwszy przypadek: repozytorium istnieje, klonujesz je

Tak wygląda sytuacja, gdy dołączasz do projektu albo gdy repozytorium powstało razem z plikiem README.

git clone git@github.com:utilisateur/projet.git

Git tworzy katalog projet w bieżącym katalogu, pobiera do niego całą historię i zapisuje zdalne repozytorium pod nazwą origin. Żeby wybrać inną nazwę katalogu, podaj ją jako drugi argument:

git clone git@github.com:utilisateur/projet.git mon-dossier

Sprawdź, co z tego wyszło:

cd projet
git remote -v
git branch --show-current

origin	https://github.com/git/git.git (fetch)
origin	https://github.com/git/git.git (push)
master

Dwie uwagi do tego wyniku. origin pojawia się dwa razy, bo Git rozróżnia adres do odczytu i adres do zapisu, prawie zawsze identyczne. Gałąź nazywa się tu master, bo taka jest domyślna nazwa gałęzi w sklonowanym repozytorium: klonowanie przejmuje nazwę z serwera i całkowicie pomija twoje ustawienie init.defaultBranch, które dotyczy wyłącznie repozytoriów zakładanych przez ciebie.

Drugi przypadek: katalog istnieje, publikujesz go

Tak wygląda sytuacja, gdy praca ruszyła wcześniej niż myśl o Gicie. Przejdź do katalogu projektu.

cd ~/projets/ma-boutique
git init

Initialized empty Git repository in /root/a2/.git/

Git właśnie utworzył podkatalog .git, w którym mieści się cała historia. Usunięcie go oznaczałoby usunięcie kontroli wersji, reszta plików pozostaje nietknięta.

Zapisz teraz pierwszy commit, bo bez niego nie ma czego publikować:

git add .
git commit -m "Premier commit"

Zadeklaruj wreszcie zdalne repozytorium i wypchnij zmiany:

git remote add origin git@github.com:utilisateur/ma-boutique.git
git branch -M main
git push -u origin main

Te trzy linie warto wyjaśnić, bo bardzo często są przepisywane bez zrozumienia.

git remote add origin przypisuje krótką nazwę origin do adresu repozytorium. W origin nie ma nic magicznego, to konwencja, można nazwać je inaczej, tylko nikt tego nie robi.

git branch -M main zmienia nazwę bieżącej gałęzi na main. Wielkie -M wymusza zmianę nawet wtedy, gdy gałąź main już istnieje. Ta linia jest zbędna, jeśli w poprzednim rozdziale zostało ustawione init.defaultBranch, ale niczego nie psuje.

git push -u origin main wysyła gałąź i dzięki -u zapamiętuje powiązanie między gałęzią lokalną a tą na serwerze. To właśnie ono pozwala potem pisać samo git push i git pull. Bez niego Git cię zatrzyma:

fatal: No configured push destination.
Either specify the URL from the command-line or configure a remote repository using

    git remote add <name> <url>

and then push using the remote name

    git push <name>

To push to multiple remotes at once, configure a remote group using

    git config remotes.<groupname> "<remote1> <remote2>"

and then push using the group name

    git push <groupname>

Pułapka zaznaczonego README

Jeśli zdalne repozytorium powstało z plikiem README, a lokalny katalog miał już commity, każda ze stron ma własny pierwszy commit i żadnego wspólnego przodka. Git odmawia wtedy ich połączenia:

fatal: refusing to merge unrelated histories

Rozwiązaniem jest poproszenie go o to wprost, jeden jedyny raz:

git pull origin main --allow-unrelated-histories

Merge made by the 'ort' strategy.
 README.md | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 README.md

Obie historie łączy commit scalający, a README dołącza do twoich plików. Potem wypychasz już normalnie.

Zarządzanie zdalnymi repozytoriami

Kilka poleceń, które warto znać na dalszą drogę.

git remote -v                                    # lista zdalnych repozytoriów
git remote set-url origin git@github.com:u/p.git # zmiana adresu, na przykład z HTTPS na SSH
git remote rename origin upstream                # zmiana nazwy
git remote remove origin                         # odłączenie

git remote set-url to polecenie do zapamiętania: właśnie ono ratuje repozytorium sklonowane po HTTPS, które chcesz przełączyć na SSH, bez klonowania wszystkiego od nowa.

Lokalne repozytorium poradzi sobie bez serwera

Nic nie zmusza cię do publikowania. git init i kolejne commity działają doskonale na katalogu, który nigdy nie opuści twojej maszyny, a historia i możliwość cofnięcia się są już na miejscu. Zdalne repozytorium wnosi trzy rzeczy: kopię poza twoim dyskiem, punkt wymiany z innymi oraz dostęp do narzędzi hostingu.

Projekt jest gotowy. Następny rozdział przechodzi do poleceń codziennej pracy i do tego, jak cofnąć błąd.