[gitmagic.git] / tmp / multiplayer.txt

== Multiplayer Git ==

Na początku zastosowałem git przy prywatnym projekcie, gdzie byłem jedynym developerem. Z poleceń w związku z rozproszoną naturą git, potrzebowałem jedynie poleceń *pull* i *clone*, dzięki czemu mogłem trzymać ten sam projekt w kilku miejscach.

Później chciałem opublikować mój kod za pomocą git i dołączyć zmiany kolegów Musiałem nauczyć się zarządzać projektami, nad którymi zaangażowani byli programiści z całego świata. Na szczęście jest to silną stroną git i chyba jego racją bytu.

=== Kim jestem? ===

Każdy 'commit' otrzymuje nazwę i adres email autora, które zostaną pokazane w *git log*. Standardowo git korzysta z ustawień systemowych do wypełnienia tych pól. Aby wprowadzić te dane bezpośrednio, podaj:

$ git config --global user.name "Jan Kowalski" $ git config --global user.email jan.kowalski@example.com

Jeśli opóścisz przełącznik '--global' zmiany zostaną zastosowane wyłącznie do aktualnego repozytorium.

=== Git przez SSH, HTTP ===

Załóżmy, posiadasz dostęp SSH do serwera stron internetowych, gdzie jednak git nie został zainstalowany. Nawet, jeśli jest to mniej efektywne jak własny protokół git, git potrafi komunikować się przez HTTP.

Zładuj git, skompiluj i zainstaluj pod własnym kontem oraz utwórz repozytorium w twoim katalogu strony internetowej.

$ GIT_DIR=proj.git git init $ cd proj.git $ git --bare update-server-info $ cp hooks/post-update.sample hooks/post-update 

Przy starszych wersjach git samo polecenie 'cp' nie będzie funkcjonować, wtedy musisz jeszcze:

chmod a+x hooks/post-update 

Od teraz możesz publikować aktualizacje z każdego klonu poprzez SSH.

$ git push web.server:/sciezka/do/proj.git master 

i każdy może teraz sklonować twój projekt przez:

$ git clone http://web.server/proj.git 

=== Git ponad wszystko ===

Chciałbyś synchronizować repozytoria bez pomocy serwera czy nawet bez użycia sieci komputerowej? Musisz improwizować w nagłym wypadku? Widzieliśmym, że poleceniami <<makinghistory, *git fast-export* i *git fast-import* możemy konwertować całe repozytoria w jeden jedyny plik i spowrotem>>. W ten sposób możemy transportować tego typu pliki za pomocą dowolnego medium, jednak bardziej wydajnym narzędziem jest *git bundle*. 

Nadawca tworzy 'bundle':

$ git bundle create plik HEAD

i transportuje 'bundle' +plik+ do innych zaangażowanych: przez email, stik-usb, *xxd* hexdump i skaner OCR, kod morse przez telefon, znaki dymne itd. Odbiorca wyciąga 'commits' z 'bundle' poprzez podanie:


$ git pull plik

Odbiorca może to zrobić z pustym repozytorium. Mimo swojej wielkości +plik+ zawiera kompletny orginał repozytorium.

W dużych projektach unikniesz śmieci danych, jeśli tylko zrobisz 'bundle' zmian brakujących w innych repozytoriach. Na przykład załóżmy, że 'commit' ``1b6d...'' jest najaktualniejszym, które posiadają obie partie:


$ git bundle create plik HEAD ^1b6d

Jeśli robi się to regularnie, łatwo można zapomnieć, który 'commit' został wysłany ostatnio. Strony pomocy zalecają stosowanie tagów, by rozwiązać ten problem. To znaczy, po wysłaniu 'bundle', podaj:

$ git tag -f ostatnibundle HEAD

a nowy 'bundle' tworzymy następnie poprzez:

$ git bundle create nowybundle HEAD ^ostatnibundle

=== Patches: globalny środek płatniczy ===

'Patches' to jawne zobrazowanie twoich zmian, które mogą być jednocześnie rozumiane przez komputer i człowieka. Dodaje im to uniwersalnej mocy przyciągania. Możesz wysłać patch prowadzącym projekt, niezależnie od tego, jakiego używają systemu kontroli wersji. Doputy twoi współpracownicy potrafią czytać swoje maile, mogą widzieć również twoje zmiany. Również i z twojej strony wszystko, czego ci potrzeba to fukcjonujące konto mailowe: nie istnieje konieczność zakładania repozytorium online.

Przypomnij sobie pierwszy rozdział:

$ git diff 1b6d > moj.patch

produkuje 'patch', który można dołączyć do maila dla dalszej dyskusji. W repozytorium git natomiast podajesz:

$ git apply < moj.patch

By zastosować patch.

W bardziej oficjalnym środowisku, jeśli nawiska autorów i ich sygnatury powinny również być notowane, tworz 'patch' od pewnego punktu, po wpisaniu:

git format-patch 1b6d 

Uzyskane w ten sposób dane mogą przekazane być do *git-send-mail* albo odręcznie wysłane. Możesz podać grupę 'commits'

$ git format-patch 1b6d..HEAD^^ 

Po stronie odbiorcy zapamiętaj email jako daną i podaj:

$ git am < email.txt 

Patch zostanie wprowadzony i utworzy commit, włącznie z informacjami jak naprzykład o autorze.

Jeśli stosujesz webmail musisz ewentualnie kliknąć, by pokazać treść niesformatowaną, zanim zapamiętasz patch do pliku.

Występują minimalne różnice między aplikacjami emailowymi bazującymi na mbox, ale jeśli korzystasz z takiej, należysz do grupy ludzi która za pewne umią się z nimi obchodzić bez czytania instrukcji!

=== Przepraszamy, przeprowadziliśmy się ===

Po sklonowaniu repozytorium, polecenia *git push* albo *git pull* będą automatycznie wskazywały na orginalne URL. Jak Git to robi? Tajemnica leży w konfiguracji, która utworzona zostaje podczas klonowania. Zaryzykujmy spojrzenie:

$ git config --list 

Opcja +remote.origin.url+ kontroluje źródłowe URL; ``origin'' to alias, nadany źródłowemu repozytorium. Tak jak i przy konwencji z  ``master'' 'Branch' , możemy ten alias zmienić albo skasować, zwykle jednak nie ma powodów by to robić.

Jeśli orginalne repozytorium zostanie przesunięte, możemy zaktualizować link poprzez: 

git config remote.origin.url git://nowy_link/proj.git

Opcja +branch.master.merge+ definuje standardowy Remote-'Branch' dla *git pull*. Podczas początkowego klonowania, zostanie ustawiony na aktualny branch źródłowego repozytorium, że nawet i potym jak 'HEAD' źródłowego repozytorium przejdzie do innego branch, późniejszy 'pull' pozostanie wierny orginalnemu branch.

Ta opcja jest ważna jedynie dla repozytorium, z którego dokonało się pierwsze klonowanie, co zapisane jest w opcji +branch.master.remote+. Przy 'pull' z innego repozytorium musimy podać z którego branch chcemy korzystać.

$ git pull git://example.com/inny.git master

To wyjaśnia dlaczego nasze poprzednie przykłady z 'push' i 'pull' nie posiadały argumentów.

=== Oddalone 'Branches' ===

Jeśli klonujesz repozytorium, klonujesz równierz wszystkie jego 'branches' Może jeszcze tego nie zauważyłeś, ponieważ Git je ukrywa: musisz się o nie specjalnie pytać: To zapobiega temu, że branches z oddalonego repozytorium nie przeszkadza twoim lokalnym branches i czyni to Git łatwiejszym dla początkujących.

Oddalone 'branches' możesz pokazać poprzez:

$ git branch -r 

Powinieneś zobaczyć coś jak:

origin/HEAD origin/master origin/experimental

Lista ta ukazje BRANCHES i HEAD odległego repozytorium, które mogą być również stosowane w zwykłych poleceniach Git. Przyjmijmy, na przykład, że wykonałeś wiele COMMITTS i chciałbyś uzyskać porównanie do ostatnio ściągniętej wersji. Możesz przeszukać logi za odpowiednim kluczem SHA1, ale dużo prościej jest podać:

$ git diff origin/HEAD 

Możesz też sprawdzić co działo się w 'Branch' ``experimental'' 

$ git log origin/experimental

=== Więcej serwerów ===

Przyjmijmy, dwóch innych programistów pracuje nad twoim projektem i chcielibyśmy mieć ich na oku. Możemy obserwować więcej niż jedno reposytorium jednocześnie:

$ git remote add inny git://example.com/jakies_repo.git $ git pull inny jakis_branch

Teraz przyłączyliśmy jeden branch z dwóch repozytorii i uzyskaliśmy łatwy dostęp do wszystkich branch z wszystkich repozytorii. 

$ git diff origin/experimental^ inny/jakis_branch~5

Co jednak zrobić, gdy chcemy porównać zmiany w nich bez wpływu na naszą pracę? Innymi słowami, chcemy zbadać ich branches bez importowania ich zmian do naszego katalogu roboczego. Zamiast 'pull' skorzystaj z:

$ git fetch # Fetch z origin, jako standard. $ git fetch inne # Fetch od drugiego programisty.

Polecenie to załaduje jedynie historię Mimo, że nasz katalog pozostał bez zmian, możemy teraz referować z każdego repozytorium poprzez polecenia Gita, ponieważ posiadamy lokalną kopię.

Przypomnij sobie, że 'pull' za kulisami to to samo co 'fetch' z następującym za nim *merge*. W normalnym wypadku wykonalibyśmy *pull*, bo chcielibyśmy przywołać również ostatnie 'commmits'. Ta przywołana sytuacja jest wyjątkiem wartym wspomnienia.

Sprawdź *git help remote* by zobaczyć, jak usuwa się repozytoria, ignoruje pewne branches i więcej-

=== Moje ustawienia ===

W moich projektach preferuję, gdy pomagający mi programiści przygotują własne repozytoria, z których mogę wykonać 'pull'. Większość hosterów Gita pozwala na utworzenie jednym kliknięciem twojego własnego forka innego projektu. 

Gdy przywołałem moją gałęź korzystam z poleceń Gita dla nawigacji i kontroli zmian, które najłepiej  gdy są dobrze zorganizowane i udokumentowane. Wykonuję 'merge' moich własnych zmian i przeprowadzam ewentualnie dalsze zmiany. Gdy już jestem zadowolony, 'push' do zentralnego repozytorium.-

Mimo, iż dość rzadko otrzymuję posty, jestem zdania, że ta metoda się opłaca. Zobacz http://torvalds-family.blogspot.com/2009/06/happiness-is-warm-scm.html[Post na Blogu Linusa Torvalds (po angielsku)].

Pozostając w świecie Gita jest wygodniejsze niż otrzymywanie patchów, ponieważ zaoszczędza mi to konwertowanie ich do 'commits' Gita. Pozatym Git martwi się o szczegóły, jak nazwa autora i adres maila, tak samo jak i o datę i godzinę oraz motywuje autora do opisywania swoich zmian.