tmp/intro.txt

   1 == Wprowadzenie ==
   2
   3 By wprowadzić w zagadnienie kontroli wersji, posłużę się pewną analogią. Dla bardziej rozsądnego wyjaśnienia przeczytajcie http://pl.wikipedia.org/wiki/System_kontroli_wersji[Artykół Wikipedii na temat systemu kontroli wersji].
   4
   5 === Praca jest zabawą ===
   6
   7 Gram w gry komputerowe chyba już przez całe moje życie. W przeciwieństwie do tego, systemy kontroli wersji zacząłem używać dopiero jako dorosły. Przypuszczam, że nie jestem tu odosobniony, a porównanie to pomoże mi w prosty sposób wytłumaczyć zrozumiale jej koncept.
   8
   9 Wyobraź sobie pracę nad twoim kodem albo dokumentami jak granie na komputerze. Jeśli dobrze ci poszło, chciałabyś zabezpieczyć swoje osiągnięcia. W tym celu klikasz na 'zapisz' w wybranym edytorze.
  10
  11 Jednak, przepiszesz przez to poprzednio zapamiętaną wersję. To jak w grach starej szkoły, które posiadały pamięć na zapisanie tylko jednego stanu: oczywiście, mogłeś zapamiętać, ale już nigdy nie mogłeś powrócic do starszego stanu. To była hańba, bo być może poprzednio zabezpieczony stan był w jakimś bardzo interesującym miejscu gry, do którego chętnie chciałbyś jeszcze wrócić. Albo jeszcze gorzej, twój zabezpieczony stan gry utknął w miejsu niemożliwym do rozwiązania i musisz zaczynać wszystko od początku.
  12
  13 === Kontrola wersji ===
  14
  15 Podczas edytowania, by uchronić starą wersję, możesz poprzez wybranie 'zapisz jako ...' zapisać twój dokument pod inną nazwą lub zapamiętać w innym miejscu. Poza tym możesz go jeszcze spakować, by zaoszczędzić miejsce na dysku. Jest to prymitywna i pracochłonna forma kontroli wersji. Gry komputerowe robią tak już od długiego czasu, wiele z nich posiada automatycznie utworzone punkty opatrzone sygnaturą czasu.
  16
  17 Skomplikujmy teraz trochę cały ten problem. Powiedzmy, że posiadasz całą masę plików, które w jakiś sposób są ze sobą powiązane, na przykład kod źródłowy jakiegoś projektu lub pliki strony internetowej. Jeśli chcesz otrzymać starszą wersję musisz archiwizować cały katalog. Archiwizowanie w ten sposób wielu wersji jest pracochłonne i szybko może stać się kosztowne, zabierając niepotrzebnie miejsce na dysku.
  18
  19 Niektóre gry komputerowe składały sie rzeczywiście z jednego katalogu pełnego plików. Gry ukrywały szczegóły przed graczem i prezentowały wygodny interfejs, do zarządzania różnymi wersjami katalogu.
  20
  21 Systemy kontroli wersji nie różnią się tutaj zbytnio. Wszystkie posiadają wygodne interfejsy, aby zarządzać katalogami pełnymi plików. Możesz archiwizować stan katalogu tak często jak często chcesz i później możesz do każdego z tych punktów powrócić. W przeciwieństwie jednak do gier, są one z regóły wszystkie zoptymalizowane pod kątem oszczędności pamięci. W więlszości przypadków tylko niewiele danych ulega zmianie pomiędzy dwoma wersjami, a same zmiany nie są zbyt obszerne. Oszczędność miejsca na dysku polega głównie na zapamiętywaniu jedynie różnic, a nie kopii całego katalogu.
  22
  23 === Rozproszona kontrola ===
  24
  25 Wyobraź sobie teraz bardzo skomplikowaną grę komputerową. Tak trudną, że wielu doświadczonych graczy na całym świecie postanawia o współnych siłach przejść grę, wymieniając się w tym celu swoimi zapamiętanymi wynikami. 'Speedruns' mogą posłużyć jako przykład z prawdziwego życia: gracze, którzy wyspecjalizowali się w różnych poziomach gry współpracują ze sobą dla uzyskania fascynujących wyników.
  26
  27 W jaki sposób skonstruowałbyś taki system, który w prosty sposób jest w stanie otrzymywać archiwa od innych? Natomiast własne innym udostępni?
  28
  29 Kiedyś każdy projekt korzystał z własnego scentralizowanego systemu kontroli wersji. Jeden serwer zapamiętywał wszystkie gry, nikt inny. Każdy gracz posiadał jedynie kilka zapamiętanych na swoim komputerze gier. Jeśli jakiś gracz chciał popchać grę trochę do przodu, musiał najpierw zładować ze serwera aktualny stan, trochę pograć, zapisać własny stan, a następnie załadować na serwer, by mógł go wykorzystać ktoś inny.
  30
  31 A gdy jakiś gracz z jakiegoś powodu chce otrzymać jakiś starszy stan? Może aktualnie zapamiętany stan gry nie jest do przejścia, bo ktoś na trzecim poziomie zapomniał zabrać jakiś objekt, i teraz próbują znaleźć stan startując od którego gra staje się znowu możliwa do przejścia. Albo chcecie porównać dwa stany, by sprawdzić ile jakiś gracz przyczynił się.
  32
  33 Jest wiele powodów, dla których można chcieć zobaczyć straszy stan, wynik jednak jest zawsze taki sam. Za każdym razem trzeba ściągnąć wszystkie dane z serwera. Czym więcej gier zostało zapamiętanych, tym więcej wymaga to komunikacji.
  34
  35 Nowa generacja systemów kontroli wersji, do których należy również git, nazywana jest systemami rozproszonymi i mogą być rozumiane jako uogólnienie systemów scentralizowanych. Jeśli gracze ładują teraz z serwera, otrzymują każdy zapisany stan, nie tylko ostatnio zapisany Wygląda to jak klonowanie serwera.
  36
  37 Pierwszy klon może być drogi, przede wszystkim, jeśli posiada długą historię, ale na dłuższy okres opłaci się. Jedną z bezpośrednich zalet jest to, że gdykolwiek potrzebny będzie jakiś starszy stan, komunikacja z głównym serwerem będzie zbędna.
  38
  39 === Głupi przesąd ===
  40
  41 Szeroko rozpowszechnianym nieporozumieniem jest opinia, że rozproszony system nie nadaje się dla projektów wymagających oficjalnego centralnego repozytorium. Nic nie jest bardziej oddalone od rzeczywistości. Fotografując kogoś nie kradziemy jego duszy. Tym samym klonowanie centralnego repozytorium nie umniejsza jego znaczenia.
  42
  43 Jednym z pierszych pozytywnych zbliżeń, jest to, iż wszystko co potrafi scentralizowany system kontroli wersji, dobrze dopracowany system rozproszony potrafi lepiej. Zasoby sieciowe są po prostu droższe niż zasoby lokalne. Również, gdy w późniejszym czasie dostrzeżemy wady systemów rozproszonych, można to przyjąć jako ogólną zasade mniej podatną na złe porównania.
  44
  45 Mały projekt wykorzysta prawdopodobnie tylko ułamek możliwości systemu. Ale, by z tego powodu korzystać z prostego systemu, nie posiadającego możliwości rozszerzenia, to tak jak stosowanie rzymskich cyfr do przeprowadzania obliczeń na małych liczbach.
  46
  47 Poza tym może sie zdarzyć, że twój projekt daleko przerośnie początkowe oczekiwania. Używając git od samego początku, to jak noszenie ze sobą scyzoryka szwajcarskiego, nawet gdy najczęściej posłuży do otwierania butelek. Być może pewnego dnia będziesz pilnie potrzebawała użyć śrubokrętu, ucieszysz się, że masz przy sobie coś więcej niż tylko zwykły otwieracz do butelek.
  48
  49 === Konflikty z 'merge' ===
  50
  51 Do przedstawienia tego punktu wykorzystanie analogii do gier komputerowych nie jest odpowiednia. Zamiast tego wyobraźmy sobie znowu, że edytujemy jakiś dokument.
  52
  53 Wyobraź sobie, Alicja dodaje linijkę na początku dokunentu, natomiast Bob na jego końcu. Obydwoje ładują swoje zmiany na serwer. Większość systemów wybierze automatycznie rozsądną drogę: zaakceptuje obie zmiany i połączy je ze sobą, tym samym obje poprawki wpłyną do dokumentu.
  54
  55 Wyobraź sobie jednak, że Alicja i Bob dokonują zmian w tej samej lini. W tym wypadku dalsze praca nie będzie możliwa bez ludzkiego udziału. Druga z osób, próbująca zładować dokument na serwer, zostanie poinformowana o wystąpieniu konfliktu 'merge' i musi zdecydować, która ze zmian zostanie przyjęta lub ponownie zrewidować całą linijkę.
  56
  57 Mimo to mogą wystąpić dużo bardziej skomplikowane sytuacje. Systemy kontroli wersji potrafią poradzić sobie z prostymi przypadkami a te trudniejsze pozostawiają ludziom. Zazwyczaj ich zachowanie daje się ustawić.