Start z Github


Wpis ma na celu sporządzenie prostej instrukcji, która krok po kroku pokaże jak zacząć publikować projekty na Github w oparciu o systemem kontroli wersji Git. Zakładam, że masz już zainstalowany u siebie program z dostępnym poleceniem git w konsoli, jeżeli nie zerknij tutaj.

  1. Zakładasz konto na Github.
  2. Zakładasz nowe repozytorium, co sprowadza się do podania jego nazwy a następnie zatwierdzenia create. Propozycję utworzenia repozytorium dostaniesz po zalogowaniu się i raczej ciężko ją przeoczyć.
  3. Klonowanie zdalnego repozytorium na dysk lokalny. Po założeniu nowego repozytorium na Github zostanie udostępniony do niego link wyglądający mniej więcej tak:

    https://github.com/NazwaKonta/nazwa-repozytorium.git

     Wpisz teraz z poziomu katalogu przeznaczonego na repozytorium :

    git clone https://github.com/NazwaKonta/nazwa-projektu.git

    Zostaniesz poproszony o hasło, które podałeś przy zakładaniu konta na serwerze. Następnie  w katalogu głównym repo pojawi się folder z repozytorium utworzonym na Github (zwykle nazwa projektu). Wewnątrz pojawi się ukryty katalog .git zawierający strukturę oraz konfigurację pustego repozytorium. Od tej chwili link do zdalnego repo będzie zapisany w pliku tekstowym /.git/config a repozytorium na Github oraz lokalne będą dla siebie widoczne.

  4.  Jak już sklonowałeś te zdalne repozytorium, to może narazie sobie nie mieszaj tym punktem i idź dalej. W każdym razie alternatywą dla klonowania pustego repozytorium z serwera zdalnego jest stworzenie lokalnego repozytorium i połączenie się ze zdalnym. Z poziomu katalogu lokalnego repozytorium wpisz w konsoli:
    git init
    git remote add origin https://github.com/NazwaKonta/nazwa-repozytorium.git

    Pierwsza linijka sprawi, że wewnątrz folderu, który przeznaczyłeś na repozytorium zostanie utworzony ukryty katalog  .git zawierający konfigurację oraz odpowiednią strukturę. Cokolwiek wrzucisz do katalogu, w którym znajduje się .git oddane zostaje “pod opiekę” systemu kontroli wersji Git. Drugą linijką łączysz się ze zdalnym repo.

  5. Stwórz teraz w katalogu repozytorium plik tekstowy .gitignore, który pomoże utrzymać kontrolę nad przekazywaną do śledzenia treścią. To co tu wpiszesz zostanie przez Git zignorowane. Możesz stosować konkretne nazwy plików (np. brudnopis.txt ) i katalogów lub proste wzory wyrażeń regularnych, żeby były ignorowane całe grupy określonego typu.  Idea jest taka, że Git ma śledzić zmiany przede wszystkim w kodzie (pliki .java) i plikach, które bezpośrednio dotyczą projektu, jak np. pom.xml a nie w plikach, które dotyczą IDE zainstalowanego na komputerze. Jeżeli używasz Intellij IDEA możesz go uzupełnić w ten sposób:
    *.class
    *.iml
    .idea
    target
  6.  Skopiuj teraz katalog ze swoim projektem do lokalnego repozytorium z .git i wpisz w konsoli:
    git status
    git add .
    git status

    Po pierwszym git status zauważysz, że Git wykrył nieśledzony nowy katalog z projektem – będzie podświetlony na czerwono. Poleceniem git add . dodajesz wszystko co nie zostanie zignorowane z katalogu repozytorium do poczekalni Git. Następnym git status możesz podejrzeć co zostało dodane – podświetla się na zielono.  Jeżeli jest coś czego nie chciałeś dodawać, użyj polecenia:

    git rm -r -f --cached .

    W ten sposób zostanie usunięte rekursywnie wszystko co dodałeś, jeżeli zamiast kropki na końcu wpiszesz np. konkretną nazwę pliku, to tylko on zostanie usunięty.

  7. Kolejnym krokiem będzie “zakomitowanie” tego co czeka w poczekalni, czyli przesunięcie katalogów i plików projektu do lokalnego repozytorium. Każdy commit, zwany też rewizją, zostanie zapamiętany i będzie można do niego wrócić. Stale pracując nad kodem będzie on ewoluował, a Git daje możliwość kontroli poszczególnych wersji poprzez tworzenie rozgałęzień – sam się tego dopiero uczę. Domyślną główną gałęzią jest master.
    git commit -m “opis / nazwa rewizji”
    git log
    git log --oneline

    Pierwszą linią wykonujesz commit dodając jakiś opis związany np. z dokonanymi zmianami od ostatniej rewizji lub “initial commit” jeżeli to pierwszy commit. Druga linia wyświetli listę “komitów”. Trzecia zrobi to samo w skróconej formie tj. w jednej lini.

  8.  Kolejny krok to wypchanie zawartości lokalnego repozytorium na serwer. Jeżeli użyłeś git clone wystarczy:
    git push

    Jeżeli wybrałeś git remote wpisz:

    git push -u origin remote

    -u origin remote używa się przy pierwszym wypchnięciu aby Git zapamiętał ustawienia gałęzi. Jeżeli dostałeś komunikat o błędach, to spróbuj wpierw scalić lokalne repozytorium ze zdalnym.

    git pull origin master

    Dostałeś komunikat: “fatal: refusing to merge unrelated histories” ? Wpisz tak:

    git pull origin master --allow-unrelated-histories

    Następnie jeszcze raz:

    git push -u origin remote

    Możesz teraz sprawdzić swoje zdalne repozytorium na Github, powinna się w nim pojawić zawartość lokalnego repo.

    Na koniec dodam, że analogiczną instrukcję można zastosować do rozpoczęcia pracy z serwerem Bitbucket. Oba z Github służą do tego samego.
    Zasadnicza różnica jest taka, że założone repozytoria w opcji darmowej na Github są dostępne publicznie, a na Bitbucket nie muszą takie być. W praktyce Github często pełni rolę wizytówki, a Bitbucket bardziej nadaje się jako przestrzeń robocza, która nie jest ogólnie widoczna.

    Warning! Tego nie pisał programista z doświadczeniem, ale dev-wannabe. Jak coś poknociłem, chętnie się o tym dowiem.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *