Lip 03 2009

git tutorial - część 2 - branch

Kategorie: git Programowanie Techblog — Matthew @ 21:23:54

Druga część naszego tutoriala. Dzisiaj zajdziemy do lasu i pobawimy się gałęziami. ;]
Rozproszone systemy kontroli wersji, przez swoją specyfikę, mają nijako wymuszone łatwe zarządzanie gałęziami oraz ich łączenie. Nie inaczej jest z gitem. Własną gałąź najprościej utworzyć tak:

git branch dev

I tym sposobem zrobiliśmy nową gałąź o nazwie dev. Teraz możemy się do niej przełączycz wydając polecenie:

git checkout dev

Możemy również cały proces zautomatyzować dodając do checkout parametr -b, dzięki czemu jednocześnie zostanie utworzona gałąź o odpowiedniej nazwie (bez wydawania polecenia branch) i zostaniemy do niej przeniesieni. Teraz edytujemy nasz projekt, commitujemy (inaczej git nie pozwoli na zmianę gałęzi (chyba, że dodacie odpowiednie parametry, o których możecie przeczytać tutaj), ew. zmiany przeniesie do docelowej gałęzi, jeżeli obecna wywodzi się z docelowej) i przełączamy się do gałęzi głównej (master) aby zobaczyć, że faktycznie w masterze nie ma tego co było w dev.

Jednak branche nic nie znaczą, jeżeli nie da się ich połączyć. W gitcie służy do tego polecenie merge (wcześniej przechodzimy do gałęzi do której chcemy zmergeować inną gałąź):

git merge dev

Jeżeli gałąź którą chcemy zmergeować wywodzi się z tej, do której chcemy łączyć (a nie wprowadzaliśmy w niej żadnych zmian), wtedy przesuwane jest tylko oznaczenie gałęzi (nazywa się to fast-forward). Może się czasami zdarzyć, że trafił się nam konflikt, wtedy wystarczy wyedytować plik w którym się on znajduje (konkretne kawałki kodu są dobrze oznaczone) oraz commitować zmiany.

Oprócz możliwości łączenia gałęzi możemy jeszcze połączyć dwie gałęzie w jedną. Służy do tego polecenie rebase:

git rebase dev

Gałęzie przed wydaniem polecenia rebase:

 B---C---D dev
 /
A-----------E master

Oraz po:

A---B'--C'--D'--E master

Cała gałąź dev zostanie przepisana i wstawiona w inne miejsce. Nie są to dokładnie te same commity (choć jak sie spojrzy przez diff to wyglądają tak samo), ale ze względu na inne ułożenie w gałęzi są z puktu widzenia gita troszeczkę inne.

Kolejnym ciekawym poleceniem jest cherry-pick. Pozwala ono na utworzenie nowego commita dla danej gałęzi, który będzie w sobie zawierał wszystkie commity począwszy od oznaczenia gałęzi aż do commita podanego jako argument. Dzięki temu możemy utrzymać większy porządek w naszym drzewie.

To tyle z działu gałęzi. Jeżeli ktoś chce pogłębić swoją wiedzę to zapraszam do czytania dokumentacji. Jest bardzo prosto napisana i nie powinna sprawić nikomu problemu. Polecam również narzędzie gitk z parametrem --all, które jest świetnym, graficznym podglądem ułożenia gałęzi w projekcie.

Komentarze:

  1. dreame4:
    03 Lip 2009, 22:07:14

    Używam gita od niedawna, komendy jak i ogólne działanie jest proste i logiczne, ale na pierwszy rzut oka wydaje się po prostu trudne (szczególnie, jak ktos siedzi na windzie i konsole widzi rzadko...).
    A takie tutoriale się przydadzą. ;)

    Ci co chcą więcej: http://hoth.entp.com/output/git_for_designers.html
    Jak dla mnie konkretnie, treściwie. Na początek świetne.

  2. hash:
    03 Lip 2009, 23:21:04

    nie jestem pewien, ale git rebase służy do czegoś innego.

  3. Matthew:
    03 Lip 2009, 23:25:55

    @hash: całkiem możliwe, ja sam z niego nie korzystam, a lepiej wytłumaczyć nie potrafię co on robi.

  4. hash:
    03 Lip 2009, 23:37:21

    ja używam go do łączenia małych commit-ów.

  5. Matthew:
    03 Lip 2009, 23:38:04

    @hash: w różnych gałęziach?

  6. hash:
    03 Lip 2009, 23:45:05

    robię sobie jakąś gałąź "dev" commit-uję regularnie, następnie git rebase -i master patrzę co da się połączyć etc., git checkout master, git merge dev i w master mam ładną historię zmian.

  7. Matthew:
    03 Lip 2009, 23:48:57

    Tak teraz czytam z innego opracowania (http://blog.endpoint.com/2009/05/git-rebase-just-workingness-baked-right.html) i wychodzi na to, że w ogólności jest to po prostu scalenie dwóch gałęzi.

  8. hash:
    03 Lip 2009, 23:53:44

    najlepiej u źródła ;) http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html

  9. Matthew:
    03 Lip 2009, 23:55:00

    Źródło pod tym względem niestety nie jest najlepsze. ;]
    Ale tutaj jest fajnie wytłumaczone: http://www.gitready.com/intermediate/2009/01/31/intro-to-rebase.html

  10. Radarek:
    04 Lip 2009, 01:05:17

    Algorytm rebase jest bardzo prosty. Jeśli jestem na gałęzi A (git checkout A) i zrobię rebase na podstawie gałęzi B (git rebase B) to:
    - git znajdzie pierwszego wspólnego przodka A i B (czyli miejsce, gdzie gałęzie się rozdzieliły)
    - usunie tymczasowo wszystkie commity z A, których nie ma w B (czyli, które pojawiły się od pierwszego wspólnego przodka w A)
    - przepisze wszystkie commity z B, których nie ma w A (czyli w tym momencie to jest fast-forward)
    - nałoży z powrotem te tymczasowo usunięte commity (mogą pojawić się konflikty), a ponieważ to są nowe commity (mają innych parentów) to ich SHA1 się zmieni (zatem nie można tego robić jeśli zmiany zostały już wypchane do innego repo!)

  11. HB:
    06 Lip 2009, 12:43:40

    Będzię jeszcze więcej części? Bardzo mi się ten tutek podoba.

  12. Matthew:
    06 Lip 2009, 12:44:34

    @HB: na pewno będą, tylko jeszcze nie wiadomo kiedy. ;)

  13. el_es:
    07 Lip 2009, 10:09:29

    Hej, wspomnialem o tym w komentarzu na jakilinux : http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html.
    <quote>
    People can (and probably should) rebase their _private_ trees (their own
    work). That's a _cleanup_. But never other peoples code. That's a "destroy
    history"
    </quote>

  14. DarkV:
    07 Lip 2009, 14:13:52

    To ja poproszę jeszcze tutorial w sytuacji gdy mamy jednego koordynatora i kilku developerów (z ograniczonym zaufaniem). Jak ustawić serwer i z jakich komend Ci panowie będą korzystać?

    I jeszcze czy da się zmienić nazwę commita? Np w przypadku gdy…
    git commit -a -m "zroobiliśmy literuwkę"

Dodaj komentarz: