java4people 2009 System kontroli wersji GIT Andrzej Śliwa This report is solely for the use of client personnel. No part of it may be distributed, quoted, or reproduced outside the client organisation without the prior written approval of Consileon Business Consultancy. This material was prepared by Consileon Business Consultancy for use during an oral presentation; it is not a complete record of the discussion. Consileon Business Consultancy GmbH
Czym jest GIT? "I m an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'." (Linus Torvalds)... A Stupid Content Tracker - szybkim rozproszonym systemem kontroli wersji - zbiorem narzędzi w postaci wielu poleceń: dostarcza zarówno wysoko poziomowych operacji jak również wewnętrznych, nisko poziomowych - oryginalnie stworzony przez Linus Trovalds do rozwoju Kernela Linuxa, po zablokowaniu darmowej wersji BitKeepera - GNU General Public License, wersja 2
Podstawowe możliwości: - rozproszony model pracy - wsparcie dla nieliniowego developmentu (tworzenie i praca na branch ach) - świetnie nadaje się do dużych projektów (bardzo dobra wydajność) - repozytoria mogą być łatwo publikowane (git://, ssh://, http://) - możliwość podpisywania tagów w oparciu o GPG - wewnętrzne obiekty są adresowane przez zawartość (odcisk SHA-1) - praca na lokalnych branch ach (praca w trybie offline)
Modele Pracy: obecnie wyróżniamy dwa najbardziej znaczące modele pracy z systemami kontroli wersji: Model zcentralizowany - ( Subversion, StartTeam, CVS... ) Model distributed - ( GIT, Mercurial, Baazar... )
Modele Pracy: model zcentralizowany - używanie systemu kontroli wersji nie jako narzędzia wspierającego development, raczej jako archiwum kodu (mechanizm tworzenia kopi zapasowych) - każda zmiana wpływa na prace pozostałych programistów - brak prywatnych branch y - wymaga połączenie do serwera dla większości standardowych operacji (praca na historii...)
Modele Pracy: model distributed (rozproszony) - możliwość pracy na wielu repozytoriach, w oparciu o różne schematy i konfiguracje - wsparcie dla lokalnych branch y - nie wymaga połączenia dla większości operacji - udostępnia lokalnie całą historie zmian ( praca w trybie offline ) - zmiany mogę być łatwo publikowane ( git://, ssh://, http://, email: )
Git poprawi jakość twojej pracy: - tworzenie branch y i mergowanie jest łatwe i szybkie - możesz łatwo prototypować ( pracując na lokalnych branch ach ) - możesz współpracować z innymi developerami wymieniając kod który nie jest ukończony i kompletny - możesz łatwo (np każdego dnia) przebudować twoje zmiany w oparciu o aktualny kod źródłowy
Git poprawi jakość twojej pracy: - możesz często merge ować (lokalnie) i przebudowywać swoje zmiany eliminując konflikty w przypadku merge owania z głównym repozytorium - twoje zmiany mogą przechodzić przez kilka etapów nim trafią do wersji finalnej (w zależności od wybranego schematu)
Podstawowe terminy: working dir - katalog roboczy na którym odbywają się zmiany index - rodzaj cache, miejsce w którym składujemy nasze zmiany przed commit em master branch - główny branch z którym merge ujemy nasze zmiany przed wysłaniem do zdalnego repozytorium
Przykład użycia poleceń: oba przypadki użycia są tożsame: $ git <nazwa komendy> [opcje] $ git-<nazwa komendy> [opcje] korzystanie z pomocy: $ git help <nazwa komendy> $ man git-<nazwa komendy>
Toolkit zamiast pojedyńczego programu: GIT nie jest pojedynczym plikiem binarnym zawierającym kod całej funkcjonalności jest podzielony na małe pliki wykonywalne (polecenia) odpowiedzialne za dostarczenie konkretnej funkcjonalności, dlatego GIT jest bardziej zbiorem narzędzi niż programem Wyróżniamy 2 następujące typy poleceń: porcelain - są to polecenia które używamy na co dzień w nasze pracy z GIT, są to plecenia wysokiego poziomu plumbing - są to polecenia które są używane wewnętrznie przez system GIT, są to polecenia niskiego poziomu (ale dostępne również dla zaawansowanych użytkowników)
Podstawowe polecenia: $ git init # tworzy puste repozytorium (ukryte w katalogu./.git) $ git add # dodaje zawartość plików do następnego commit u (do index u) $ git rm #usuwa plik z index u ( i po za commit owaniu z repo.) $ git mv #przenosi plik $ git status # pokazuje bieżący status katalogu roboczego oraz index u
Podstawowe polecenia: $ git commit # wprowadza zmiany do repozytorium (na podstawie index u) $ git log # pokazuje log a commit ów $ git show # pokazuje commit y (lub inne obiekty) $ git fetch # pobiera nowe zmiany z zewnętrznego repozytorium $ git pull # fetch + merge $ git push # wysyła zmiany do zewnętrznego repozytorium
Zaawansowane :) polecenia: $ git branch # tworzy/modyfikuje/usuwa branch e $ git checkout # przełącza katalog roboczy na inny branch $ git merge # merge uje dwa lub więcej branch y $ git rebase # zmienia punkt startu dla brancha $ git reset # przywraca stan katalogu roboczego $ git stash # zapisuje/odtwarza zmiany (rodzaj bardzo użytecznego schowka) $ git gc # porządkowanie i usuwanie duplikatów
Wewnętrzne obiekty: Wszystkie obiekty są adresowane odciskiem SHA-1 ich zawartości oraz są kompresowane (ZLib) commit - wskazuje na tree i parent (połączenie w historii projektu) zawiera informacje o autorze i osobie commit ującej oraz treść komunikatu tree - reprezentuje stan pojedynczego katalogu (lista obiektów typu blob oraz zagnieżdżonych obiektów tree) blob - zawiera zawartość pliku bez żadnej dodatkowej struktury
Implementacja: blob Przypomnienie : GIT śledzi zmiany treści, nie poszczególne pliki nazwy i tryby plików nie są przechowywane w obiekcie blob W GIT zawartość każdego pliku jest zapisywany w obiektach typu blob Jeżeli w strukturze katalogów projektu posiadamy dwa pliki o takiej samej treści (nie zależnie od nazwy plików) GIT zapisze dokładnie jeden obiekt blob z zawartością pliku!
Implementacja: blob (schematy) Katalog roboczy: Katalog GIT a (./.git):./ pom.xml blob: a427b1 src/ main/ scala/ gitandscala/ App.scala blob: a0b60a
Implementacja: tree obiekt tree jest zwykłą listą innych obiektów typu tree lub blob lista ta zawiera w sobie typy obiektów, ich referencje oraz pełne rzeczywiste nazwy plików/katalogów na które wskazują w/w referencje każdy element list posiada informacje o typie pliku/katalogu jego trybie (binarny/tekstowy) oraz pełnej nazwie obiekt tree również jest kompresowany (ZLib)
Implementacja: tree (schemat) Katalog roboczy: Katalog GIT a (./.git):./ tree: a5b60b pom.xml blob: a427b1 src/ main/ scala/ gitandscala/ App.scala tree: a53e0d tree: da460a tree: fa23a2 tree: f12d34 blob: a0b60a
Implementacja: commit obiekt commit odpowiada za naszą historię w repozytorium obiekt commit przechowuje następujące informacje: author committer message referencje na parent commit (w przypadku pierwszego commitu pole te nie istnieje) referencje na obiekt typu tree Za każdym razem gdy commitujemy zmiany w GIT, tworzony jest snapshot całej struktury projektu, wszystkich plików
implementacja: commit Katalog roboczy: Katalog GIT a (./.git):./ tree: a5b60b pom.xml blob: a427b1 src/ main/ scala/ gitandscala/ App.scala tree: a53e0d tree: da460a tree: fa23a2 tree: f12d34 blob: a0b60a commit: f0c40e
Referencje: Branch: zawiera odcisk SHA-1 commit u (.git/refs/heads) Tag: zawiera odcisk SHA-1 commit u może zawierać opis może być podpisany cyfrowo (PGP) (.git/refs/tags) HEAD: wskazuje na obecny branch
Referencje obiektów: SHA-1 40 znakowa (hex) nazwa obiektu tag zrozumiała przez człowieka nazwa dla commit u {nazwa comm.}^n - N-ty rodzic (nadrzędny commit) {nazwa comm.}~n - N-ta generacja nadrzędnego nazwanego commit u rodzica np. rev~3 = rev^^^ = rev^1^1^1 $ git reset HEAD^
Bezpieczeństwo i zaufanie: wszystkie obiekty w obiektowej bazie GIT a są adresowane w oparciu o odcisk zawartości (SHA-1) SHA-1 jest sprawdzana za każdym razem celem sprawdzenia integralności zawartość, historia, i treść komunikatów mogą być podpisane cyfrowo (GPG) poprzez tag.
Konfiguracja: globalna konfiguracja znajduje się w pliku ~/.gitconfig $ git config --global --list wyświetli nam konfiguracje tylko globalną $ git config --list wyświetli konfiguracje dla repozytorium
Konfiguracja: podstawowe ustawienia: $ git config --global user.name "Your Name" $ git config --global user.email your.email@domain.com $ git config --global color.branch auto $ git config --global color.diff auto $ git config --global color.interactive auto $ git config --global color.status auto $ git config --global core.editor "mate -w"
Przykładowa zawartość pliku ~/.gitconfig [user] [core] name = Andrzej Śliwa email = andrzej.sliwa@i-tool.eu editor = mate -w
Krótkie przypomnienie: branch - jest to linia developmentu (jego historii), przebiegająca równolegle do głównej linii historii commit commit branch commit commit commit commit commit master commit commit commit commit branch
Krótkie przypomnienie: tag - jest markerem konkretnej wersji (commit u) w historii tag: v1.0 commit commit commit commit commit master
Przykładowy projekt: Celem prezentacji możliwości GIT a stworzymy prosty projekt aplikacji napisanej w scali oparty o maven a: mvn org.apache.maven.plugins:maven-archetype-plugin:1.0-alpha-7:create \ archetypegroupid=org.scala-tools.archetypes \ archetypeartifactid=scala-archetype-simple \ archetypeversion=1.2 \ remoterepositories=http://scala-tools.org/repo-releases \ groupid=gitandscala -DartifactId=git-and-scala
Tworzenie repozytorium: stworzenie nowego repozytorium: $ cd git-and-scala $ git init dodanie plików do repozytorium: $ git add. $ git commit -m initial import
Ogólny schemat pracy: Local repository commit Working dir. Current Branch (in./.git) merge checkout (switch to branch) Branch (in./.git) pull push pull push Branch Branch Remote repository (np. origin)
Tworzenie repozytorium: dodanie zdalnego repozytorium: $ git remote add origin git@github.com:andrzejsliwa/git-andscala.git skonfigurowanie połaczenia miedzy lokalnym branch em master a zdalnym origin: $ git config branch.master.remote origin $ git config branch.master.merge refs/heads/master
Tworzenie repozytorium: możemy również dodać dowolną liczbę innych zewnętrznych repozytoriów, z którymi będzięmy synchronizować nasze zmiany: $ git remote add michal ssh://michal@niczsoft.com/ glassfish-maven-plugin.git $ git remote add andrzej ssh://andrzej@andrzejsliwa.com/ glassfish-maven-plugin.git
Przykładowy plik konfiguracji (./.git/config) [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true ignorecase = true [remote "andrzej"] url = ssh://andrzej@i-tool.eu/testowy.git fetch = +refs/heads/*:refs/remotes/andrzej/* [remote "origin"] url = git@github.com:andrzejsliwa/git-and-scala.git fetch = +refs/heads/*:refs/remotes/origin/* [branch "master"] remote = origin merge = refs/heads/master
Zarządzanie tagami: tworzenie tag a: $ git tag v1.0 tworzenie tag a podpisanego z komentarzem: $ git tag -s v1.0 wyświetlenie listy tagów: $ git tag wysyłanie naszego tag a na zdalne repozytorium: $ git push --tags
Zarządzanie tagami: kasowanie tag a lokalanego: $ git tag -d v1.0 kasowanie tag a na zdalnym repozytorium: $ git push origin :refs/tags/v1.0
Zarządzanie branch ami: tworzenie brancha: $ git branch nazwa_brancha przełączenie się na brancha: $ git checkout nazwa_brancha tworzenie i przełączenie się w jednym kroku: $ git checkout -b nazwa_brancha tworzenie brancha na zdalnym repozytorium: $ git push origin nazwa_brancha
Zarządzanie branch ami: mergowanie branch y: $ git checkout master $ git status $ git merge nazwa_brancha... jeżeli były konflikty, to poprawiamy je, następnie ręcznie commitujemy: $ git commit -a -m
Zarządzanie branch ami: kasowanie branch a zmergowanego z master em: $ git branch -d nazwa_brancha kasowanie branch a nie zmergowanego z master em: $ git branch -D nazwa_brancha kasowanie zdalnego branch a: $ git push origin :heads/nazwa_brancha
Przeglądanie zmian: sprawdzenie log a commit ów: $ git log $ git log --since= 2 weeks ago $ git log nazwa_pliku sprawdzenie kto zmieniał poszczególne lini pliku: $ git blame nazwa_pliku $ git blame -L 10,15 nazwa_pliku
Standardowe modele pracy z GIT: Praca z GIT em 1. pobranie zmian ze zdalnego repo.: $ git pull 2. stworzenie lokalnego branch a do pracy nad nowym ficzerem ;) i przęłączenie się na niego: $ git checkout -b dodanie_tagowania 3. dodanie zmian do index u (nasz cache zmian do commit a): $ git add nazwa_pliku $ git add nazwa_katalogu $ git rm nazwa_pliku...
Standardowe modele pracy z GIT: Praca z GIT em 4. commit zmian do repozytorium (nadal lokalnie!) $ git commit -m komentarz # commit z komentarzem lub: $ git commit # commit z komentarzem dodanym w edytorze lub: $ git commit -a # j/w, ale wszystkie zmiany zostaną dodane automatycznie, bez dodawania ich do repozytorium commit ujemy wielokrotnie w ramach ficzera... 5. wracamy do master a $ git checkout master
Standardowe modele pracy z GIT: Praca z GIT em 6. uaktualniamy sobie master a (ze zdalnego repo.): $ git pull 7. mergujemy brancha z master em: $ git merge dodanie_tagowania 8. wypychamy zmiany na zdalne repozytorium: $ git push
Standardowe modele pracy z GIT: Praca z GIT em Zalety takiego rozwiązania: - cały czas mamy nie ruszony master, by szybko robić pilne poprawki czy zmiany - jeżeli praca nad ficzerem trwa dłużej, możemy uaktualniać kod branch a w oparciu o master a żeby uniknąć dużych konfliktów przy finalnym mergow aniu. - nasze branche są tylko lokalnie, i stanowią dla nas wygodny mechanizm wspomagający prace
Standardowe modele pracy z GIT: Praca z GIT-SVN Git udostępnia funkcjonalność która pozwala nam na używanie w połączeniu z repozytorium Subversion (jako centralnym repo.), przy jednoczesnym korzystaniu z dobrodziejstw GIT a (lokalne branch e, pełna historia offline itd.) zmieniają się tylko dwie komendy w następujących krokach: 1. i 6. $ git pull -> $ git svn rebase 8. $ git push -> $ git svn dcommit
Funkcja z której często korzystam: często ma miejsce sytuacja gdy pracując na danym branchu, nim jeszcze za commit ujemy nasze zmiany, ktoś wpada z następującą prośbą: - uaktualnij sobie kod, sprawdź coś... - popraw szybko, jest tutaj problem... - itd... w tym momencie użyteczną funkcją jest stash: $ git stash # przenosi nasze zmiany do schowka po tej komendzie mamy czysty katalog roboczy (ostatni commit), możemy pobrać kod, coś poprawić i wrócić do zmian ze schowka : $ git stash apply
Wizualizacja i narzędzia: wizualizacja pomaga w pracy na branch ach, pozwala lepiej zrozumieć miejsce w którym się bieżąco znajdujemy Podgląd historii : Gitk, GitNub, QGit, Netbeans... Narzędzia do commit owania: git gui, GitX, Netbeans...
Hurra!! Koniec... KONIEC. dziękuje za uwagę. Pytania?!?