pl/multiplayer.tmp

   1 == Multiplayer Git ==
   2
   3 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.
   4
   5 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.
   6
   7 === Kim jestem? ===
   8
   9 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:
  10
  11  $ git config --global user.name "Jan Kowalski"
  12  $ git config --global user.email jan.kowalski@example.com
  13
  14 Jeśli opóścisz przełącznik '--global' zmiany zostaną zastosowane wyłącznie do aktualnego repozytorium.
  15
  16 === Git przez SSH, HTTP ===
  17
  18 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.
  19
  20 Zładuj git, skompiluj i zainstaluj pod własnym kontem oraz utwórz repozytorium w twoim katalogu strony internetowej.
  21
  22  $ GIT_DIR=proj.git git init
  23  $ cd proj.git
  24  $ git --bare update-server-info
  25  $ cp hooks/post-update.sample hooks/post-update
  26
  27 Przy starszych wersjach git samo polecenie 'cp' nie będzie funkcjonować, wtedy musisz jeszcze:
  28
  29 chmod a+x hooks/post-update
  30
  31 Od teraz możesz publikować aktualizacje z każdego klonu poprzez SSH.
  32
  33  $ git push web.server:/sciezka/do/proj.git master
  34
  35 i każdy może teraz sklonować twój projekt przez:
  36
  37  $ git clone http://web.server/proj.git
  38
  39 === Git ponad wszystko ===
  40
  41 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*.
  42
  43 Nadawca tworzy 'bundle':
  44
  45  $ git bundle create plik HEAD
  46
  47 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:
  48
  49
  50  $ git pull plik
  51
  52 Odbiorca może to zrobić z pustym repozytorium. Mimo swojej wielkości +plik+ zawiera kompletny orginał repozytorium.
  53
  54 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:
  55
  56
  57  $ git bundle create plik HEAD ^1b6d
  58
  59 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:
  60
  61  $ git tag -f ostatnibundle HEAD
  62
  63 a nowy 'bundle' tworzymy następnie poprzez:
  64
  65  $ git bundle create nowybundle HEAD ^ostatnibundle
  66
  67 === Patches: globalny środek płatniczy ===
  68
  69 '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.
  70
  71 Przypomnij sobie pierwszy rozdział:
  72
  73  $ git diff 1b6d > moj.patch
  74
  75 produkuje 'patch', który można dołączyć do maila dla dalszej dyskusji. W repozytorium git natomiast podajesz:
  76
  77  $ git apply < moj.patch
  78
  79 By zastosować patch.
  80
  81 W bardziej oficjalnym środowisku, jeśli nawiska autorów i ich sygnatury powinny również być notowane, tworz 'patch' od pewnego punktu, po wpisaniu:
  82
  83  $ git format-patch 1b6d
  84
  85 Uzyskane w ten sposób dane mogą przekazane być do *git-send-mail* albo odręcznie wysłane. Możesz podać grupę 'commits'
  86
  87  $ git format-patch 1b6d..HEAD^^
  88
  89 Po stronie odbiorcy zapamiętaj email jako daną i podaj:
  90
  91  $ git am < email.txt
  92
  93 Patch zostanie wprowadzony i utworzy commit, włącznie z informacjami jak naprzykład o autorze.
  94
  95 Jeśli stosujesz webmail musisz ewentualnie kliknąć, by pokazać treść niesformatowaną, zanim zapamiętasz patch do pliku.
  96
  97 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!
  98
  99 === Przepraszamy, przeprowadziliśmy się ===
 100
 101 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:
 102
 103  $ git config --list
 104
 105 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ć.
 106
 107 Jeśli orginalne repozytorium zostanie przesunięte, możemy zaktualizować link poprzez:
 108
 109  $ git config remote.origin.url git://nowy_link/proj.git
 110
 111 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.
 112
 113 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ć.
 114
 115  $ git pull git://example.com/inny.git master
 116
 117 To wyjaśnia dlaczego nasze poprzednie przykłady z 'push' i 'pull' nie posiadały argumentów.
 118
 119 === Oddalone 'Branches' ===
 120
 121 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.
 122
 123 Oddalone 'branches' możesz pokazać poprzez:
 124
 125  $ git branch -r
 126
 127 Powinieneś zobaczyć coś jak:
 128
 129 origin/HEAD origin/master origin/experimental
 130
 131 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ć:
 132
 133  $ git diff origin/HEAD
 134
 135 Możesz też sprawdzić co działo się w 'Branch' ``experimental''
 136
 137 $ git log origin/experimental
 138
 139 === Więcej serwerów ===
 140
 141 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:
 142
 143 $ git remote add inny git://example.com/jakies_repo.git $ git pull inny jakis_branch
 144
 145 Teraz przyłączyliśmy jeden branch z dwóch repozytorii i uzyskaliśmy łatwy dostęp do wszystkich branch z wszystkich repozytorii.
 146
 147 $ git diff origin/experimental^ inny/jakis_branch~5
 148
 149 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:
 150
 151 $ git fetch # Fetch z origin, jako standard. $ git fetch inne # Fetch od drugiego programisty.
 152
 153 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ę.
 154
 155 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.
 156
 157 Sprawdź *git help remote* by zobaczyć, jak usuwa się repozytoria, ignoruje pewne branches i więcej-
 158
 159 === Moje ustawienia ===
 160
 161 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.
 162
 163 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.-
 164
 165 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)].
 166
 167 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.