No i Git! Kontrola wersji służy nie tylko programistom

To pierwszy z dwóch wpisów, który chcę poświęcić tematowi kontroli wersji za pomocą Gita. Pierwszy będzie wprowadzający i nie pojawi się w nim słowo rebase. W drugim się pojawi, ponieważ jestem nim zaintrygowana. Obu towarzyszyć będą commity do mojego repozytorium projektowego w ramach konkursu Daj się poznać.

Wstęp (dla informatyków)

Zacznę od wyjawienia wstydliwej prawdy: nie znam się Gicie. Tak  wyszło, że w pracy najpierw używaliśmy CVS, potem SVN, potem Perforce (P4). To już i tak niezły mętlik – prosta komenda checkout w SVN i P4 znaczy coś zupełnie odmiennego : odpowiednio pobranie projektu na lokalny dysk albo otwarcie pliku do edycji wraz z zablokowaniem wersji na serwerze. Kilka razy w życiu musiałam dotknąć Gita bądź GitHuba: głównie w zadaniach domowych na Courserze bądź w ramach współpracy z zespołami, które z Gita korzystały.

Życie zmusiło mnie nawet do napisania (wraz z kompanami, co chyba jeszcze pogarsza sprawę) kodu, który automatycznie synchronizował dane w Gicie z danymi w Perforce. Istnieje, co prawda, odpowiedni plugin do P4, ale mieliśmy zbyt starą wersję serwera…

 

Wstęp (dla tych, co nie lubią „tajemniczych szyfrów”*)

System kontroli wersji to narzędzie, które pozwala śledzić zmiany wprowadzane w dokumencie. Dzięki temu zawsze możesz sprawdzić, Wiesz kto i kiedy wprowadził zmianę (czyli dodał, usunął lub zmienił linijkę tekstu). Jeśli zmiany są wprowadzane przez kilka osób, możesz łatwo (a przynajmniej łatwiej niż w innych okolicznościach) je połączyć. Możesz przywrócić dowolną wersję dokumentu – nawet taką, która w rzeczywistości nigdy nie istniała (np. zawierającą zmiany wprowadzone przez dwie osoby, a bez zmian trzeciej).

Systemy kontroli wersji służą przede wszystkim programistom, ale mogą przydać się właściwie każdej osobie pracującej z tekstem, jak dziennikarz czy tłumacz. Można zresztą pilnować w ten sposób nawet listy zakupów… Żeby jednak w pełni skorzystać z funkcjonalności takiego systemu (np. porównywanie dwóch różnych wersji) dane powinny być w postaci czysto tekstowej – takiej, jaką da się otworzyć za pomocą zwykłego edytora tekstu (jak windowsowy Notatnik).

Obecnie najpopularniejszym systemem kontroli wersji jest Git, któremu poświęcony jest ten wpis. Znalazłam nawet artykuł (po angielsku) o tym, jak wersjonować w Gicie pliki MS Word. Do domowych zastosowań wystarczy prostszy koncepcyjnie Subversion.

* Dostałam dzisiaj taką miłą recenzję: Twojego bloga czyta się jednym tchem (gdy pomijam oczywiście wpisy poświęcone jakimś tajemniczym szyfrom ;)).

 

Anegdotka

Żeby nie musieć od razu zabierać się do pracy, opowiem jeszcze anegdotkę.

Zostałam kiedyś zaproszona do wygłoszenia wykładu na temat ciągłej integracji. Połowę czasu spędziłam na live coding (yeah). Pokazałam, jak stworzyć projekt i buildy na serwerze Bamboo (w chmurze firmy Atlassian), oraz w jaki sposób można uruchomić (wyzwolić) plany. Ponieważ na moim prezentacyjnym netbooku z Windows 8 (teraz mieszka tam Linux Mint, więc powstrzymajcie kamienie) nie miałam zainstalowanego żadnego systemu kontroli wersji, wyedytowałam plik w GitHubie (kod też miał być w chmurze) przez przeglądarkę.

Na koniec organizator tego spotkania (który zresztą również bierze udział w konkursie) zwierzył mi się, że o ile treść wykładu zawierała informacje już mu znane, to nie miał pojęcia, że można zmieniać kod w GitHubie z poziomu przeglądarki i to właśnie z tego wykładu wyniesie.

Treść wykładu można znaleźć na blogu: Ciągła Integracja: anioł stróż dobrego programisty i Ciągła Integracja: jak skonfigurować proces budowania na serwerze Bamboo?

 

Git: cechy charakterystyczne

  • System rozproszony: programiści utrzymuję własne lokalne repozytoria i tylko czasami wysyłają kod do repozytorium głównego.
  • Łatwość tworzenia i scalania gałęzi (branches) do pracy nad różnymi wersjami czy funkcjonalnościami.
  • Staging Area: można wygodnie wskazać, które spośród wprowadzonych zmian mają się znaleźć w commicie, nawet jeśli dotyczą tego samego pliku.
  • Darmowe narzędzie z otwartymi źródłami.

githubheart

Do rzeczy: jak wersjonować projekt w Gicie i przechowywać w ogólnodostępnym repozytorium GitHub?

W 12 krokach:

1. Zainstalować Git w wersji dla odpowiedniego systemu ze strony https://git-scm.com/downloads.
2. Utworzyć konto na stronie GitHub: https://github.com/
3. Utworzyć repozytorium dla projektu

W tym celu należy wybrać na stronie opcję New Repository i wybrać pożądane opcje (repozytorium publiczne lub prywatne, puste lub z plikiem Readme.md; można dodać informację o licencji oraz ignorowanych typach plików). W ten sposób powstało repozytorium mojego projektu.

(GitHub oferuje dodatkowe możliwości, jak strony Wiki czy możliwość zgłaszania błędów – ale o tym nie będziemy tu rozmawiać.)

4. Pobrać kod, tworząc przy okazji lokalne repozytorium

W wybranej przeze mnie lokalizacji wywołuję komendę:

Zawartość katalogu szafbook:

Jeśli przyjrzymy się dokładniej, znajdziemy jeszcze ukryty katalog z informacjami dla systemu kontroli wersji:

Nie będziemy tam zaglądać.

5. Status

Na wszelki wypadek sprawdźmy teraz status plików projektowych i upewnijmy się, że działamy na aktualnej wersji gałęzi MASTER (główna i domyślna gałąź repozytorium):

6. Pora coś popsuć! Zmiana w kodzie

Wprowadziłam zmianę w pliku README.md. Po jej zapisaniu:

7. Dodanie pliku

Utworzę jeszcze nowy plik w tym samym katalogu. Nazwę go test.txt. Po zapisaniu:

Git pokazuje mi, co zmieniłam, a także informuje mnie, że jeśli chcę odwzorować te zmiany w repozytorium, muszę użyć komendy add.

8. Staging: pomiędzy zmianą a commitem

Ponieważ chcę zapisać zmiany w repozytorium, użyję komendy add:

9. Wysłanie zmian do repozytorium

Uwaga 1: Na razie do mojego repozytorium na dysku, a nie do centralnego repozytorium GitHub!)
Uwaga 2: Na tym etapie git może poprosić o podanie informacji o użytkowniku.

W domyślnym edytorze tekstu otwarty zostanie plik z informacjami na temat aktualnego zestawu zmian, gdzie należy wprowadzić objaśniający komentarz.

Alternatywnie mogę podać ten komentarz od razu przy wywołaniu polecenia commit:

10. Historia zmian

Historię zmian możemy śledzić za pomocą komendy log:

11. Wysłanie zmian do centralnego repozytorium GitHub

  • origin to repozytorium, z którego oryginalnie pobrałam kod (czyli mój projekt w GitHub, zapamiętany przy wywołaniu polecenia clone)
  • master to nazwa gałęzi w repozytorium

Uwaga: gdyby w międzyczasie ktoś zmienił kod w głównym repozytorium, musiałabym najpierw zaakceptować jego zmiany – system nie pozwoliłby mi wysłać moich. W tym wypadku jestem jednak jedyną osobą z prawem zapisu, więc mam pewność, że nie natknę się na tego typu kłopoty.

12. Podejrzenie zmian

Na tym etapie moje zmiany są już widoczne w portalu GitHub! Hurra!

 

Więcej?

Więcej informacji: np. jak cofnąć wprowadzone zmiany, odkopać starszą wersję, poradzić sobie ze zmianami wprowadzonymi przez różnych użytkowników, znajdziesz w podręczniku na oficjalnej stronie Gita. Jesteśmy teraz w rozdziale Git Basics.

Komentarze

12 myśli nt. „No i Git! Kontrola wersji służy nie tylko programistom”

  1. Fajne wprowadzenie do używania gita z konsoli, ja korzystam z niego na codzień ale będę podsyłać tego posta ludziom którzy chcą z nim zacząć ^^

  2. Jak rozumiem repozytorium gdzie składowane są dane jest poza moją własną siecią? Czy jest możliwość posadzenia „serwera GitHub” w lokalnej sieci tak aby składowane dane nie wychodziły do DMZ?

      1. Wówczas każdy developer ma lokalne repozytorium u siebie, a wspólne (zamiast GitHuba) macie na jakimś własnym serwerze. Przy czym GitHub pozwala na tworzenie niepublicznych repo – tu są informacje o kosztach: https://github.com/pricing

    1. Na „prywatnego Githuba” polecam https://gitlab.com – jest to rowiązanie na Githubie w dużej mierze bazujące, niemniej już obecnie posiadające kilka funkcji, których w Githubie brakuje. Prywatne repozytoria w wersji hostowanej przez nich są bezpłatne, a można też sobie uruchomić własną instancję na własnym serwerze, będąc tym samym w pełni niezależnym od zewnętrznego usługodawcy. Ta opcja również jest darmowa (jest też płatna wersja Enterprise Edition).

Dodaj komentarz

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