Używanie Git & GitHub

Pasek boczny 3.5

procent przetłumaczone

W tym rozdziale dowiesz się:

  • Jak używać GitHub pracując z książką.
  • GitHub jest społecznościowym repozytorium dla projektów open-source bazujących na systemie kontroli wersji Git i jego podstawową funkcją jest ułatwienie współdzielenia kodu i współpracy przy pracy nad projektami.

    Ten rozdział zakłada, że nie jesteś zaznajomiony z Git i GitHub. Jeżeli znasz oba, możesz przeskoczyć do następnego rozdziału!

    Praca z commitami

    Podstawowym narzędziem, zmianą części pliku jest commit. Możesz myślić o commit jak o zrzucie stanu bazy plików w danym momencie czasu.

    Zamiast dostarczenia całego kodu Microcope, robiliśmy takie zrzuty w trakcie pisania książki i możesz je zobaczyć online na GitHub.

    Przykładowo, tak wygląda ostatni commit poprzedniego rozdziału:

    Commit Git wyświetlany na GitHub.
    Commit Git wyświetlany na GitHub.

    Możesz tutaj zobaczć “diff” (skrót z ang. difference) pliku post_item.js, innymi słowy zmiany, jakie zostały dokonane w danym commicie. W tym przypadku, stworzyliśmy od postaw plik posts_item.js, zatem cała jego zawartość jest podświetlona na zielono.

    Porównajmy ten przykład z przykładem z dalszej części książki:

    Wprowadzanie zmian kodu.
    Wprowadzanie zmian kodu.

    Tym razem wyłącznie zmienione linie zostały podświetlone na zielono.

    Oczywiście czasami ani nie dodajesz ani zmieniasz linie kody, ale je usuwasz:

    Usuwanie kodu.
    Usuwanie kodu.

    Pierwszy raz użyliśmy GitHub: zmiany są widoczne natychmiastowo.

    Przeglądanie kodu commita

    Okno przeglądania commita Gita pokazuje zmiany zawarte w danym commicie, ale czasem chciałbyś spojrzeć na pliki, które nie uległy zmianie, aby się upewnić, że ich zawartość jest poprawna w danym momencie czasu.

    Ponownie GitHub okazuje się pomocny. Gdy jesteś na stronie commita, kliknij na przycisk Browse code:

    Przycisk `Browse code`.
    Przycisk `Browse code`.

    Będziesz miał teraz dostęp do całego repozytorium w momencie danego commita.

    Repozytorium podczas commita 3-2.
    Repozytorium podczas commita 3-2.

    GitHub nie pokazuje wielu wizualizacji tego, co obserwujemy patrząc na commit, ale możesz go porównać z “"normalnym” widokiem brancha master i zerknąć na różnice w strukturze pliku:

    Repozytorium podczas commita 14-2.
    Repozytorium podczas commita 14-2.

    Lokalny dostęp do commita

    Zobaczyliśmy przed chwilą, jak przeglądać kod danego commita online na GitHub. Ale co jeśli chciałbyć osiągnąć to samo lokalnie? Przykładowo, mógłbyś mieć ochotę na uruchomienie aplikacji lokalnie na danym commicie, aby zobaczyć jak ma się zachowywać w danym momencie czasu.

    Aby to osiągnąć, przejdziemy przez pierwsze kroki (przynajmniej w tej książce) z konsolową aplikacją git. Dla początkujących, upewnij się, że zainstalowałeś Git. Następnie sklonuj (inaczej mówiąc, pobierz z serwera kopię) repozytorium Microscope za pomocą:

    $ git clone git@github.com:DiscoverMeteor/Microscope.git github_microscope
    

    Ostatni parametr github_microscope jest lokalną nazwą repozytorium, do którego będziesz klonował aplikację. Zakładając, że już posiadasz folder microscope, wybierz dowolną nazwę (nie musi być taka sama, jak repozytorium na GitHub).

    Następnie przejdźmy do tego folderu używając cd i zacznijmy używać konsolową aplikację git:

    $ cd github_microscope
    

    Teraz gdy sklonowaliśmy respozytorium z GitHub, pobraliśmy cały kod aplikacji, co oznacza że mamy dostęp do najnowszego commita.

    Na szczęście jest możliwość wrócenia do dowolnego miejsca w czasie i pobranie (ang. “check out”) danego commita bez wpływania na pozostałe. Wypróbujmy to teraz:

    $ git checkout chapter3-1
    Note: checking out 'chapter3-1'.
    
    You are in 'detached HEAD' state. You can look around, make experimental
    changes and commit them, and you can discard any commits you make in this
    state without impacting any branches by performing another checkout.
    
    If you want to create a new branch to retain commits you create, you may
    do so (now or later) by using -b with the checkout command again. Example:
    
      git checkout -b new_branch_name
    
    HEAD is now at a004b56... Added basic posts list template and static data.
    

    Git poinformował, że jesteśmy obecnie w stanie “detached HEAD”, co oznacza, że możemy obserwować poprzednie commity, ale nie możemy ich modyfikować. Możesz wyobrazić sobie w tym momencie wróżkę patrzącą w szklaną kulę.

    (Uwaga: Git posiada w swoim arsenale również komendy pozwalające na zmianę poprzednich commitów. Tu mógłbyś wyobrazić sobie podróżnika w czasie zmieniającego przeszłość, ale jest to poza zakresem tego krótkiego wstępu do Gita).

    Powodem, dla którego mogłeś wpisać chapter3-1 jest to, że otagowaliśmy wszystkie commity Microscope poprawnym znacznikiem rozdziału. Gdybyśmy tego nie zrobili, konieczne byłoby odnalezienie hasha lub mówiąc inaczej unikalnego idetyikatora danego commita.

    Ponownie w takim przypadku GitHub ułatwia pracę. Można znaleźć tag commita w dolnym prawym rogu niebieskiego przycisku nagłówka, jak pokazano poniżej:

    Znajdowanie hasha commita.
    Znajdowanie hasha commita.

    Wypróbujmy zatem użyć hash zamiast taga:

    $ git checkout c7af59e425cd4e17c20cf99e51c8cd78f82c9932
    Previous HEAD position was a004b56... Added basic posts list template and static data.
    HEAD is now at c7af59e... Augmented the postsList route to take a limit
    

    A co, jeżeli znudzi nam się patrzenie w szklaną kulę i chcemy wrócić do stanu początkowego? W takim przypadku nakazujemy Git, aby pobrał branch master:

    $ git checkout master
    

    Zanotuj, że możesz również uruchomić aplikację za pomocą komendy meteor w dowolnym momencie tego procesu, nawet w stanie “detached HEAD”. Może zaistnieć konieczność zawołania mrt update jeżeli Meteor wyświetli komunikat błędu o brakującym pakiecie, ponieważ kod pakietów nie jest dołączony do repozytorium Git dla Microscope.

    Oglądanie historii zmian

    Często napotkasz następujący scenariusz: patrzysz na plik i zauważasz zmiany, których wcześniej nie widziałeś. Nie pamiętasz kiedy plik uległ zmianie. Możesz sprawdzić każdy commit po kolei, aż nie znajdziesz prawidłowego, ale istnieje łatwiejszy sposób aby to odnaleźć dzięki funkcji Historia (ang. History) w GitHub.

    Po pierwsze, znajdź dany plik w repozytorium w GitHub, następnie odszukaj przycisk “History.

    Przycisk History w GitHub.
    Przycisk History w GitHub.

    Widzimy teraz uporządkowaną listę commitów, które zmieniły dany plik:

    Wyświetlenie historii plików.
    Wyświetlenie historii plików.

    Znajdowanie osoby odpowiedzialnej za dokonane zmiany

    Aby zebrać wszystkie informacje, przyjrzymy się bliżej Blame.

    Przycisk Blame w GitHub.
    Przycisk Blame w GitHub.

    Uporządkowany widok informuje kto i w jakim commicie modyfikował dany plik (innymi słowo, kogo winić za popełnione czyny, jeżeli coś nie chce działać).

    Widok Blame w GitHub.
    Widok Blame w GitHub.

    Ponieważ Git oraz GitHub są całkiem skomplikowanymi narzędziami, nie mamy zamiaru przedstawić wszystkich informacji na ich temat w pojedyńczym rozdziale. Tak naprawdę dotknęliśmy tylko czubka góry lodowej, ale mamy nadzieję, że przedstawiona wiedza okaże się przydatna podczas dalszego czytania tej książki.