Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00447 008671 10464252 na godz. na dobę w sumie
Kontrola wersji z systemem Git. Narzędzia i techniki programistów. Wydanie II - książka
Kontrola wersji z systemem Git. Narzędzia i techniki programistów. Wydanie II - książka
Autor: , Liczba stron: 424
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-246-8176-1 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> inne - programowanie
Porównaj ceny (książka, ebook, audiobook).

Systemy kontroli wersji przechodzą ciągłą ewolucję. Jeszcze niedawno popularny był system CVS, który został wyparty przez SVN. Ostatnie lata to inwazja rozproszonych systemów kontroli wersji z Gitem na czele. Git pozwala każdemu programiście na posiadanie prywatnego repozytorium i korzystanie z jego dobrodziejstw bez wpływu na inne repozytoria. Jesteś ciekaw, jakie jeszcze zalety ma Git?

Jeżeli tak, trafiłeś na idealną książkę, dzięki której błyskawicznie wkroczysz w świat Gita. Na początek krok po kroku przejdziesz przez proces instalacji, a następnie dostosujesz środowisko do swoich potrzeb. W kolejnych rozdziałach poznasz dostępne polecenia oraz nauczysz się zarządzać plikami. Ponadto przekonasz się, jak łatwo można stworzyć odgałęzienia kodu oraz przeglądać różnice pomiędzy wersjami pliku. Git posiada zaawansowane narzędzia do łączenia kodu - będziesz mógł je dogłębnie poznać. Na koniec przeczytasz o zaawansowanych możliwościach systemu Git, takich jak współpraca z SVN. Ta książka jest doskonałym podręcznikiem dla każdego początkującego użytkownika systemu Git, zaawansowani również znajdą tu sporo przydatnych informacji. Wykorzystaj potencjał Gita!

Dzięki tej książce:

Wykorzystaj potencjał systemu kontroli wersji Git!

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Tytuł oryginału: Version Control with Git, Second Edition Tłumaczenie: Zdzisław Płoski ISBN: 978-83-246-8176-1 © 2014 Helion S.A. Authorized Polish translation of the English edition of Version Control with Git, 2nd Edition, ISBN 9781449316389 © 2012 Joe Loeliger. This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls all rights to publish and sell the same. All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from the Publisher. Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji. Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli. Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION nie ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce. Wydawnictwo HELION ul. Kościuszki 1c, 44-100 GLIWICE tel. 32 231 22 19, 32 230 98 63 e-mail: helion@helion.pl WWW: http://helion.pl (księgarnia internetowa, katalog książek) Drogi Czytelniku! Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://helion.pl/user/opinie/koweg2 Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję. Printed in Poland. • Kup książkę • Poleć książkę • Oceń książkę • Księgarnia internetowa • Lubię to! » Nasza społeczność Spis tre(cid:316)ci Przedmowa ..............................................................................................................................11 1. Wprowadzenie .............................................................................................................17 17 18 20 21 22 Podstawy Narodziny Gita Poprzednicy Na osi czasu Có(cid:276) to za nazwa? 2. Dystrybucje Debian lub Ubuntu Inne dystrybucje binarne Instalowanie Gita ........................................................................................................23 23 Zastosowanie binarnych dystrybucji Linuksa 23 24 25 26 27 28 29 Uzyskanie wydania (cid:274)ród(cid:228)owego Budowanie i instalowanie Instalowanie Gita w systemie Windows Instalowanie pakietu Git w systemie Cygwin Instalowanie wolno stoj(cid:241)cej wersji Gita (msysGit) Polecenie git Szybkie wprowadzenie do u(cid:276)ytkowania Gita 3. Na dobry pocz(cid:233)tek ....................................................................................................... 31 31 33 33 34 35 36 36 37 38 39 Tworzenie archiwum pocz(cid:241)tkowego Dodawanie pliku do Twojego archiwum Konfigurowanie autora zatwierdzenia Wykonanie kolejnego zatwierdzenia Przegl(cid:241)danie Twoich zatwierdze(cid:254) Przegl(cid:241)danie ró(cid:276)nic w zatwierdzeniach Usuwanie i przemianowywanie plików w Twoim archiwum Tworzenie kopii Twojego archiwum 3 Kup książkęPoleć książkę Pliki konfiguracyjne Konfigurowanie synonimu Zasi(cid:246)ganie j(cid:246)zyka 39 41 42 Poj(cid:246)cia podstawowe Archiwa Typy obiektów Gita Indeks Nazwy adresowane tre(cid:264)ci(cid:241) Git nadzoruje tre(cid:264)(cid:232) Nazwy (cid:264)cie(cid:276)ek a tre(cid:264)(cid:232) Pliki pakowane 4. Podstawowe koncepcje Gita .......................................................................................43 43 43 44 45 46 46 47 48 49 51 51 52 53 54 55 56 57 Zawarto(cid:264)(cid:232) katalogu .git Obiekty, haszowania i bloby Pliki i drzewa Uwaga o zastosowaniu w Gicie algorytmu SHA1 Hierarchie drzewiaste Zatwierdzenia Metki Obrazy magazynu obiektów Koncepcje Gita uwidocznione w dzia(cid:228)aniu Wszystko kr(cid:246)ci si(cid:246) wokó(cid:228) indeksu Klasyfikacje plików w Gicie U(cid:276)ycie polecenia git add Kilka uwag o stosowaniu polecenia git commit 5. Zarz(cid:233)dzanie plikami a indeks .....................................................................................59 59 60 62 64 64 65 65 67 68 69 71 U(cid:276)ycie polecenia git rm U(cid:276)ycie polecenia git mv Uwaga o (cid:264)ledzeniu przemianowa(cid:254) Plik .gitignore Szczegó(cid:228)owy przegl(cid:241)d modelu obiektowego i plików Gita U(cid:276)ycie polecenia git commit --all Zapisywanie komunikatów dziennika zatwierdze(cid:254) Niepodzielne zbiory zmian Identyfikowanie zatwierdze(cid:254) 6. Zatwierdzenia .............................................................................................................. 77 78 79 79 80 81 Bezwzgl(cid:246)dne nazwy zatwierdze(cid:254) Refy i symrefy Wzgl(cid:246)dne nazwy zatwierdze(cid:254) 4 (cid:95) Spis tre(cid:316)ci Kup książkęPoleć książkę Historia zatwierdze(cid:254) Przegl(cid:241)danie starych zatwierdze(cid:254) Grafy zatwierdze(cid:254) Przedzia(cid:228)y zatwierdze(cid:254) Znajdowanie zatwierdze(cid:254) U(cid:276)ycie polecenia git bisect U(cid:276)ycie polecenia git blame U(cid:276)ycie kilofa 83 83 85 89 93 93 97 98 Co u(cid:276)ywa(cid:232), a czego nie u(cid:276)ywa(cid:232) w nazwach odga(cid:228)(cid:246)zie(cid:254) Powody stosowania odga(cid:228)(cid:246)zie(cid:254) Nazwy odga(cid:228)(cid:246)zie(cid:254) Zastosowanie odga(cid:228)(cid:246)zie(cid:254) Tworzenie odga(cid:228)(cid:246)zie(cid:254) Sporz(cid:241)dzanie wykazów nazw odga(cid:228)(cid:246)zie(cid:254) Przegl(cid:241)danie odga(cid:228)(cid:246)zie(cid:254) Wyci(cid:241)ganie odga(cid:228)(cid:246)zie(cid:254) 7. Odga(cid:293)(cid:253)zienia ................................................................................................................99 99 100 101 101 103 104 104 106 107 107 109 111 111 112 Elementarny przyk(cid:228)ad wyci(cid:241)gania odga(cid:228)(cid:246)zienia Wyci(cid:241)ganie w wypadku niezatwierdzonych zmian (cid:227)(cid:241)czenie zmian w nowe odga(cid:228)(cid:246)zienie Tworzenie i wyci(cid:241)ganie nowego odga(cid:228)(cid:246)zienia Wyosobnione odga(cid:228)(cid:246)zienia HEAD Usuwanie odga(cid:228)(cid:246)zie(cid:254) 8. Ró(cid:348)nice ........................................................................................................................115 116 120 122 125 126 Postaci polecenia git diff Prosty przyk(cid:228)ad polecenia git diff Polecenie git diff i przedzia(cid:228)y zatwierdze(cid:254) Polecenie git diff z ograniczeniem (cid:264)cie(cid:276)ki Porównanie wyprowadzania ró(cid:276)nic w systemach Subversion i Git Przyk(cid:228)ady (cid:228)(cid:241)cze(cid:254) Przygotowanie do (cid:228)(cid:241)czenia (cid:227)(cid:241)czenie dwóch odga(cid:228)(cid:246)zie(cid:254) Konflikt w trakcie (cid:228)(cid:241)czenia 9. (cid:292)(cid:233)czenia ..................................................................................................................... 129 129 130 130 132 135 136 136 140 Lokalizowanie konfliktowych plików Badanie konfliktów W jaki sposób Git (cid:264)ledzi konflikty Post(cid:246)powanie z konfliktami (cid:228)(cid:241)czenia Spis tre(cid:316)ci (cid:95) 5 Kup książkęPoleć książkę Zako(cid:254)czenie rozwi(cid:241)zywania konfliktu Zaniechanie lub wznowienie (cid:228)(cid:241)czenia Strategie (cid:228)(cid:241)czenia (cid:227)(cid:241)czenia zdegenerowane (cid:227)(cid:241)czenia zwyk(cid:228)e (cid:227)(cid:241)czenia specjalne Stosowanie strategii (cid:228)(cid:241)czenia Sterowniki (cid:228)(cid:241)czenia Jak Git rozpatruje (cid:228)(cid:241)czenia (cid:227)(cid:241)czenia i model obiektowy Gita (cid:227)(cid:241)czenia zgniatane Czemu nie (cid:228)(cid:241)czy(cid:232) po prostu ka(cid:276)dej zmiany po kolei? 142 143 144 146 147 149 149 151 151 151 152 153 Uwaga dotycz(cid:241)ca zmieniania historii U(cid:276)ycie polecenia git reset U(cid:276)ycie polecenia git cherry-pick U(cid:276)ycie polecenia git revert Polecenia reset, revert i checkout Zmiana zatwierdzenia szczytowego Przebazowanie zatwierdze(cid:254) 10. Zmienianie zatwierdze(cid:295) ........................................................................................... 155 157 158 164 166 167 168 170 172 176 U(cid:276)ycie polecenia git rebase –i Operacja rebase a (cid:228)(cid:241)czenie 11. Skrytka stash i rejestr odniesie(cid:295) reflog .....................................................................181 181 189 Skrytka Rejestr odniesie(cid:254) Koncepcje archiwum Odwo(cid:228)ywanie si(cid:246) do innych archiwów Odwo(cid:228)ania do archiwów zdalnych Refspec — specyfikator odniesienia Przyk(cid:228)ad u(cid:276)ycia zdalnych archiwów Archiwa czyste i rozwojowe Klony archiwów Piloty Odga(cid:228)(cid:246)zienia nadzoruj(cid:241)ce 12. Archiwa zdalne .......................................................................................................... 193 194 194 195 196 197 198 198 200 202 203 204 206 206 Tworzenie archiwum wzorcowego Uczy(cid:254) swój w(cid:228)asny pocz(cid:241)tek zdalnym Prowadzenie prac we w(cid:228)asnym archiwum Wypychanie zmian 6 (cid:95) Spis tre(cid:316)ci Kup książkęPoleć książkę Dodawanie nowego wykonawcy Pobieranie uaktualnie(cid:254) archiwum Cykl rozwoju zdalnego archiwum w uj(cid:246)ciu rysunkowym Klonowanie archiwum Historie alternatywne Niespieszne wypychanie Pobieranie alternatywnej historii (cid:227)(cid:241)czenie historii Konflikty (cid:228)(cid:241)czenia Wypychanie po(cid:228)(cid:241)czonej historii Konfigurowanie zdalne U(cid:276)ycie polecenia git remote U(cid:276)ycie polecenia git config Obróbka r(cid:246)czna Dzia(cid:228)anie na odga(cid:228)(cid:246)zieniach nadzorowania Tworzenie ga(cid:228)(cid:246)zi nadzorowania Przed i za Dodawanie i usuwanie odga(cid:228)(cid:246)zie(cid:254) zdalnych Archiwa czyste i polecenie git push 207 209 214 214 215 216 217 218 218 219 219 220 221 222 222 222 225 226 227 S(cid:228)owo o serwerach Publikowanie archiwów Archiwa z kontrolowanym dost(cid:246)pem Archiwa z anonimowym dost(cid:246)pem do czytania Archiwa z anonimowym dost(cid:246)pem do pisania Publikowanie archiwum na koncie GitHub 13. Zarz(cid:233)dzanie archiwum ..............................................................................................229 229 230 230 231 235 235 236 237 237 238 239 241 241 242 242 243 244 244 245 246 Przep(cid:228)ywy w gór(cid:246) i w dó(cid:228) Role piel(cid:246)gnatora i budowniczego Wspó(cid:228)praca mi(cid:246)dzy piel(cid:246)gnatorem a budowniczym Dualno(cid:264)(cid:232) ról Zmienianie historii upublicznionej Rozdzielno(cid:264)(cid:232) kroków zatwierdze(cid:254) i publikowania Ani jednej historii prawdziwej Wskazówka dotycz(cid:241)ca publikowania archiwum Struktura archiwum Struktura archiwum dzielonego Struktura archiwum rozproszonego Przyk(cid:228)ady struktur archiwów Jak (cid:276)y(cid:232) w warunkach rozproszenia Znaj swoje miejsce Spis tre(cid:316)ci (cid:95) 7 Kup książkęPoleć książkę Praca z wieloma archiwami Twoja w(cid:228)asna przestrze(cid:254) robocza Gdzie rozpocz(cid:241)(cid:232) swoje archiwum Przekszta(cid:228)cenie w inne archiwum w górze U(cid:276)ywanie wielu górnych archiwów Rozwidlanie projektów 247 247 248 249 250 252 Dlaczego u(cid:276)ywamy (cid:228)at? Generowanie (cid:228)at 14. (cid:292)aty .............................................................................................................................255 256 257 264 264 267 273 273 Pocztowe ekspediowanie (cid:228)at Stosowanie (cid:228)at Z(cid:228)e (cid:228)aty (cid:227)atanie a (cid:228)(cid:241)czenie (cid:227)aty i sortowanie topologiczne Instalowanie doczepek Doczepki przyk(cid:228)adowe Utworzenie pierwszej doczepki 15. Doczepki .....................................................................................................................275 277 277 278 280 280 281 282 283 Doczepki powi(cid:241)zane z zatwierdzeniami Doczepki powi(cid:241)zane z (cid:228)atami Doczepki powi(cid:241)zane z wypychaniem Inne doczepki do lokalnego archiwum Dost(cid:246)pne doczepki Stare rozwi(cid:241)zanie: wyci(cid:241)gi cz(cid:246)(cid:264)ciowe Rozwi(cid:241)zanie oczywiste: zaimportuj kod do swojego projektu 16. Zestawianie projektów .............................................................................................285 286 287 289 289 293 Importowanie podprojektów przez kopiowanie Importowanie podprojektów poleceniem git pull –s subtree Kierowanie swoich zmian w gór(cid:246) Rozwi(cid:241)zanie zautomatyzowane: wyci(cid:241)ganie podprojektów z u(cid:276)yciem odpowiednich skryptów Rozwi(cid:241)zanie rodzime: gitlinki i git submodule Odsy(cid:228)acze gitlinks Polecenie git submodule 293 295 295 297 17. Najlepsze praktyki dotycz(cid:233)ce podmodu(cid:293)ów ............................................................ 301 301 302 303 304 Polecenia podmodu(cid:228)owe Dlaczego podmodu(cid:228)y? Przygotowywanie podmodu(cid:228)ów Dlaczego tylko do czytania? 8 (cid:95) Spis tre(cid:316)ci Kup książkęPoleć książkę Dlaczego nie tylko do czytania? Sprawdzanie haszowa(cid:254) zatwierdze(cid:254) podmodu(cid:228)ów Ponowne wykorzystanie pe(cid:228)nomocnictw Przypadki u(cid:276)ycia Wielopoziomowe zagnie(cid:276)d(cid:276)anie archiwów Podmodu(cid:228)y na horyzoncie 304 305 305 306 307 307 Przyk(cid:228)ad: p(cid:228)ytki klon jednego odga(cid:228)(cid:246)zienia Wypychanie, ci(cid:241)gni(cid:246)cie, rozga(cid:228)(cid:246)zianie i (cid:228)(cid:241)czenie za pomoc(cid:241) git svn Pora na wykonywanie zmian w Gicie Pobranie przed zatwierdzeniem Zatwierdzanie za pomoc(cid:241) git svn rebase 18. Zastosowanie Gita do archiwów systemu Subversion ............................................309 309 312 313 314 315 316 317 319 320 321 321 322 Utrzymywanie prostoty identyfikatorów zatwierdze(cid:254) Klonowanie wszystkich ga(cid:228)(cid:246)zi Dzielenie Twojego archiwum Ponowne w(cid:228)(cid:241)czanie do Subversion Cecha svn:ignore a plik .gitignore Rekonstruowanie pami(cid:246)ci podr(cid:246)cznej git-svn Inne uwagi o pracy z systemem Subversion U(cid:276)ycie polecenia git filter-branch Jak pokocha(cid:228)em polecenie git rev-list Przyk(cid:228)ady u(cid:276)ycia polecenia git filter-branch Pu(cid:228)apki filter-branch 19. Dzia(cid:293)ania zaawansowane .........................................................................................323 323 325 330 330 331 333 335 345 345 349 Polecenie git fsck Ponowne przy(cid:228)(cid:241)czenie utraconego zatwierdzenia Interaktywne wystawianie kawa(cid:228)ków Rekonstruowanie utraconego zatwierdzenia Wyci(cid:241)ganie wed(cid:228)ug daty Odzyskiwanie starej wersji pliku Interaktywne przebazowanie z zabrudzonym katalogiem roboczym Usuwanie zb(cid:246)dnych plików edytora (cid:227)(cid:241)czenie nieu(cid:276)ytków Podzia(cid:228) archiwum Sposoby rekonstruowania zatwierdze(cid:254) Rady dotycz(cid:241)ce konwersji Subversion 20. Rady, chwyty i sposoby ............................................................................................. 351 351 352 352 354 355 356 356 356 357 Ogólne zalecenia Usuwanie trzonu po zaimportowaniu SVN Usuwanie identyfikatorów zatwierdze(cid:254) SVN Spis tre(cid:316)ci (cid:95) 9 Kup książkęPoleć książkę Manipulowanie odga(cid:228)(cid:246)zieniami pochodz(cid:241)cymi z dwu archiwów Odzyskiwanie z przebazowania w górze Tworzenie w(cid:228)asnych polece(cid:254) w Gicie Szybki przegl(cid:241)d zmian Czyszczenie U(cid:276)ycie polecenia git-grep do przeszukiwania archiwum Aktualizowanie i usuwanie refów Post(cid:246)powanie za przemieszczonymi plikami Zachowaj ten plik, lecz go nie nadzoruj By(cid:228)e(cid:264) tu ju(cid:276) wcze(cid:264)niej? 357 358 359 360 361 361 363 364 365 366 21. Git i GitHub ................................................................................................................367 367 369 372 373 373 374 376 377 379 382 383 384 386 388 389 390 390 391 392 393 395 396 Archiwum kodu powszechnie dost(cid:246)pnego Tworzenie archiwum w GitHubie Kodowanie spo(cid:228)eczne na otwartych (cid:274)ród(cid:228)ach Obserwatorzy Kana(cid:228) informacyjny Rozwidlenia Przygotowywanie zamówie(cid:254) ci(cid:241)gni(cid:246)cia Obs(cid:228)ugiwanie zamówie(cid:254) ci(cid:241)gni(cid:246)cia Powiadomienia Odnajdywanie u(cid:276)ytkowników, projektów i kodu Wikisy Strony GitHuba (Git do witryn) Edytor kodu wprost ze strony Most do systemu Subversion Metki automatycznie zamieniane na pliki archiwalne Organizacje Interfejs REST API Kodowanie spo(cid:228)eczne oparte na (cid:274)ród(cid:228)ach zamkni(cid:246)tych Docelowe czerpanie z otwartych (cid:274)róde(cid:228) Modele kodowania GitHub jako inicjatywa gospodarcza GitHub — podsumowanie Skorowidz .............................................................................................................................397 10 (cid:95) Spis tre(cid:316)ci Kup książkęPoleć książkę ROZDZIA(cid:292) 4. Podstawowe koncepcje Gita Poj(cid:253)cia podstawowe W poprzednich rozdzia(cid:228)ach przedstawili(cid:264)my typowe zastosowanie Gita, co prawdopodobnie rozwi(cid:241)za(cid:228)o tylko worek z pytaniami. Czy Git przechowuje ca(cid:228)y plik przy ka(cid:276)dym zatwier- dzeniu? Do czego s(cid:228)u(cid:276)y katalog .git? Dlaczego identyfikator zatwierdzenia przypomina jaki(cid:264) be(cid:228)kot? Czy mam go sobie zapisywa(cid:232)? Je(cid:264)li u(cid:276)ywa(cid:228)e(cid:264) jakiego(cid:264) innego systemu kontroli wersji, jak SVN lub CVS, to by(cid:232) mo(cid:276)e pole- cenia w poprzednim rozdziale wygl(cid:241)da(cid:228)y znajomo. Rzeczywi(cid:264)cie, Git s(cid:228)u(cid:276)y do tego samego i zawiera wszystkie operacje, których oczekujesz od nowoczesnego systemu kontroli wersji. Git jednak ró(cid:276)ni si(cid:246) od innych tego typu systemów w pewien zasadniczy i zaskakuj(cid:241)cy sposób. W tym rozdziale zastanowimy si(cid:246), dlaczego i w jaki sposób Git si(cid:246) ró(cid:276)ni, analizuj(cid:241)c kluczowe komponenty jego architektury i pewne wa(cid:276)ne koncepcje. Skupiamy si(cid:246) tutaj na sprawach podstawowych i pokazujemy, jak wspó(cid:228)pracowa(cid:232) z jednym archiwum. W rozdziale 12 wyja- (cid:264)niamy, jak pracowa(cid:232) z wieloma po(cid:228)(cid:241)czonymi archiwami. Nadzorowanie wielu archiwów mo(cid:276)e wydawa(cid:232) si(cid:246) zniech(cid:246)caj(cid:241)c(cid:241) perspektyw(cid:241), lecz kwestie elementarne, które poznasz w tym rozdziale, przenosz(cid:241) si(cid:246) na tamte obszary bez zmian. Archiwa Archiwum Gita (skarbiec, ang. repository1) jest po prostu baz(cid:241) danych, zawieraj(cid:241)c(cid:241) wszystkie informacje potrzebne do przechowywania wersji projektu i jego historii oraz zarz(cid:241)dzania nimi. W Gicie, jak w wi(cid:246)kszo(cid:264)ci systemów kontroli wersji, archiwum przechowuje kom- pletn(cid:241) kopi(cid:246) ca(cid:228)ego przedsi(cid:246)wzi(cid:246)cia w trakcie jego istnienia. Jednak(cid:276)e — w odró(cid:276)nieniu od innych systemów VCS — archiwum Gita dostarcza nie tylko kompletnej, dzia(cid:228)aj(cid:241)cej kopii wszystkich przechowywanych w nim plików, lecz tak(cid:276)e s(cid:228)u(cid:276)y kopi(cid:241) samego siebie, na której mo(cid:276)na dzia(cid:228)a(cid:232). 1 Nie chcemy u(cid:276)ywa(cid:232) okre(cid:264)lenia repozytorium z dwóch powodów: (1) kojarzy si(cid:246) z zetla(cid:228)ymi aktami i (2) jest d(cid:228)ugie — przyp. t(cid:228)um. 43 Kup książkęPoleć książkę Git utrzymuje w ka(cid:276)dym archiwum zbiór warto(cid:264)ci konfiguracyjnych. W poprzednim roz- dziale widzia(cid:228)e(cid:264) niektóre z nich, takie jak nazwisko (nazwa) u(cid:276)ytkownika archiwum i adres jego poczty elektronicznej. W odró(cid:276)nieniu od danych plikowych i innych metadanych, usta- wienia konfiguracji nie s(cid:241) przenoszone mi(cid:246)dzy archiwami podczas operacji klonowania, czyli powielania. Zamiast tego Git zarz(cid:241)dza konfiguracj(cid:241) oraz ustawialnymi informacjami i nadzo- ruje je na szczeblu stanowiska (maszyny), u(cid:276)ytkownika i archiwum. Wewn(cid:241)trz archiwum Git utrzymuje dwie podstawowe struktury danych: magazyn obiektów (ang. object store) i indeks. Wszystkie te dane z archiwum s(cid:241) przechowywane u korzenia Twojego katalogu roboczego2, w ukrytym podkatalogu o nazwie .git. Magazyn obiektów jest zaprojektowany tak, aby mo(cid:276)na go by(cid:228)o sprawnie kopiowa(cid:232) w czasie wykonywania operacji klonowania jako cz(cid:246)(cid:264)(cid:232) mechanizmu wspomagaj(cid:241)cego w pe(cid:228)ni rozpro- szony system VCS. Indeks stanowi informacj(cid:246) przej(cid:264)ciow(cid:241), dotyczy indywidualnego archi- wum i mo(cid:276)e by(cid:232) tworzony lub modyfikowany na (cid:276)yczenie — stosownie do potrzeb. W nast(cid:246)pnych dwóch podrozdzia(cid:228)ach opisano magazyn obiektów i indeks bardziej szcze- gó(cid:228)owo. Typy obiektów Gita Magazyn obiektów stanowi centralny element implementacji archiwum Gita. Zawiera Twoje oryginalne pliki danych i wszystkie komunikaty dziennika, informacje autorskie, daty i inne informacje niezb(cid:246)dne do odbudowania dowolnej wersji lub odga(cid:228)(cid:246)zienia projektu. Git lokuje w magazynie obiektów tylko cztery ich typy: bloby (ang. blobs), drzewa (ang. trees), zatwierdzenia (ang. commits) i metki (ang. tags). Te cztery elementarne (niepodzielne) obiekty tworz(cid:241) podstaw(cid:246) gitowych struktur danych wy(cid:276)szego poziomu. Bloby Ka(cid:276)da wersja pliku jest reprezentowana w postaci blobu. Blob3, jako skrót od binary large object (z ang. du(cid:276)y obiekt binarny), jest terminem powszechnie u(cid:276)ywanym w technice obli- czeniowej na okre(cid:264)lenie pewnej zmiennej lub pliku, które mog(cid:241) zawiera(cid:232) dowolne dane i których wewn(cid:246)trzna struktura jest ignorowana przez program. Blob jest traktowany jako co(cid:264) nieprzeniknionego. Blob przechowuje dane pliku, lecz nie zawiera (cid:276)adnych me- tadanych dotycz(cid:241)cych pliku — nawet jego nazwy. Drzewa Obiekt drzewa reprezentuje jeden poziom informacji katalogowej. Zapisane s(cid:241) w nim identyfikatory blobów, nazwy (cid:264)cie(cid:276)ek i troch(cid:246) metadanych dotycz(cid:241)cych wszystkich pli- ków w jednym katalogu. Mo(cid:276)e on równie(cid:276) zawiera(cid:232) rekurencyjne odniesienia do innych obiektów (pod)drzew, wskutek czego tworzy pe(cid:228)n(cid:241) hierarchi(cid:246) plików i podkatalogów. 2 W oryginale: at the root of your working directory, okre(cid:264)lenie jest troch(cid:246) niejasne w swej skrótowo(cid:264)ci; chodzi o korze(cid:254) poddrzewa katalogów, w którym u(cid:276)ytkownik za(cid:228)o(cid:276)y(cid:228) archiwum — przyp. t(cid:228)um. 3 Nazwa jest o tyle zabawna, (cid:276)e po angielsku blob oznacza m.in. kleks lub plam(cid:246) — przyp. t(cid:228)um. 44 (cid:95) Rozdzia(cid:293) 4. Podstawowe koncepcje Gita Kup książkęPoleć książkę Zatwierdzenia Obiekt zatwierdzenia zawiera metadane dotycz(cid:241)ce ka(cid:276)dej zmiany wprowadzonej w ar- chiwum, w tym autora, zatwierdzaj(cid:241)cego (ang. committer), dat(cid:246) i komunikat dziennika. Ka(cid:276)de zatwierdzenie wskazuje na obiekt drzewa, który w jednym, migawkowym i ca(cid:228)o- (cid:264)ciowym uj(cid:246)ciu obejmuje stan archiwum z chwili wykonywania zatwierdzenia. Pocz(cid:241)t- kowe zatwierdzenie, czyli zatwierdzenie korzeniowe, nie ma przodka. Wi(cid:246)kszo(cid:264)(cid:232) zatwier- dzonych zapisów ma jednego przodka zatwierdzenia, przy czym w dalszej cz(cid:246)(cid:264)ci ksi(cid:241)(cid:276)ki (w rozdziale 9) wyja(cid:264)niamy, w jaki sposób zatwierdzenie mo(cid:276)e mie(cid:232) odniesienia do wi(cid:246)cej ni(cid:276) jednego przodka. Metki Obiekt metki przypisuje danemu obiektowi (zwykle obiektowi zatwierdzenia) dowoln(cid:241) nazw(cid:246), tak(cid:241) jednak, która przypuszczalnie jest czytelna dla cz(cid:228)owieka. Cho(cid:232) 9da581d910c (cid:180)9c4ac93557ca4859e767f5caf5169 odnosi si(cid:246) do dok(cid:228)adnie i dobrze okre(cid:264)lonego zatwierdzenia, sensowniejsz(cid:241) dla cz(cid:228)owieka i wi(cid:246)cej mówi(cid:241)c(cid:241) b(cid:246)dzie metka w stylu Ver-1.0-Alpha. Z biegiem czasu w magazynie obiektów przybywa coraz to nowych informacji odzwiercie- dlaj(cid:241)cych i odwzorowuj(cid:241)cych redakcje, uzupe(cid:228)nienia i usuni(cid:246)cia dokonywane w Twoim zadaniu. Aby oszcz(cid:246)dza(cid:232) przestrze(cid:254) dyskow(cid:241) i przep(cid:228)ywno(cid:264)(cid:232) sieci, Git kompresuje i prze- chowuje obiekty w plikach pakowanych (ang. pack files4), które równie(cid:276) s(cid:241) umieszczane w ma- gazynie obiektów. Indeks Indeks jest tymczasowym i dynamicznym plikiem binarnym, opisuj(cid:241)cym struktur(cid:246) ca(cid:228)ego ar- chiwum. Dok(cid:228)adniej mówi(cid:241)c, indeks wyra(cid:276)a wersj(cid:246) ogólnej struktury projektu w danej chwili. Stan projektu mo(cid:276)na reprezentowa(cid:232) za pomoc(cid:241) zatwierdzenia i drzewa, wychodz(cid:241)c od do- wolnego punktu w historii projektu; mo(cid:276)e to by(cid:232) równie(cid:276) stan przysz(cid:228)y, ku któremu czynnie pod(cid:241)(cid:276)asz. Jedn(cid:241) z wyró(cid:276)niaj(cid:241)cych cech Gita jest mo(cid:276)liwo(cid:264)(cid:232) zmieniania zawarto(cid:264)ci indeksu w meto- dycznych, dobrze okre(cid:264)lonych krokach. Indeks pozwala na rozdzia(cid:228) mi(cid:246)dzy przyrostowymi krokami rozwojowymi a zatwierdzaniem tych zmian. Dzia(cid:228)a to nast(cid:246)puj(cid:241)co. Jako budowniczy wykonujesz polecenia Gita maj(cid:241)ce na celu wybranie (wystawienie, ang. stage) zmian do wykonania, co jest odnotowywane w indeksie. Zmiany polegaj(cid:241) zazwyczaj na dodaniu, usuni(cid:246)ciu lub przeredagowaniu jakiego(cid:264) pliku lub zbioru plików. Indeks zapisuje i zachowuje te zmiany, utrzymuj(cid:241)c je bezpiecznie do czasu, a(cid:276) b(cid:246)- dziesz gotowy do ich zatwierdzenia. Zmiany mo(cid:276)esz równie(cid:276) z indeksu usun(cid:241)(cid:232) lub zast(cid:241)pi(cid:232) innymi. Indeks umo(cid:276)liwia Ci zatem stopniowe przej(cid:264)cie, zazwyczaj zale(cid:276)ne od Ciebie, od jednego kompleksowego stanu archiwum do drugiego, z za(cid:228)o(cid:276)enia — lepszego. Jak zobaczysz w rozdziale 9, indeks odgrywa wa(cid:276)n(cid:241) rol(cid:246) w operacjach (cid:228)(cid:241)czenia, umo(cid:276)liwiaj(cid:241)c jednoczesne zarz(cid:241)dzanie, nadzorowanie i manipulowanie wieloma wersjami tego samego pliku. 4 To samo poj(cid:246)cie jest równie(cid:276) okre(cid:264)lane w oryginale nazw(cid:241) packed file; pozostajemy przy jednej — przyp. t(cid:228)um. Archiwa (cid:95) 45 Kup książkęPoleć książkę Identyfikatory globalnie jednoznaczne Wa(cid:276)n(cid:241) cech(cid:241) obliczenia haszowania SHA1 jest to, (cid:276)e zawsze powoduje ono wytworzenie tego samego identyfikatora dla danej tre(cid:264)ci, niezale(cid:276)nie od tego gdzie ta tre(cid:264)(cid:232) si(cid:246) znajduje. Innymi s(cid:228)owy, ta sama tre(cid:264)(cid:232) pliku w ró(cid:276)nych katalogach, a nawet na ró(cid:276)nych maszynach, prowadzi do powstania dok(cid:228)adnie tego samego identyfikatora haszowego SHA1. Tak wi(cid:246)c haszowanie SHA1 pliku wytwarza identyfikator efektywny i globalnie jednoznaczny (unikatowy). Istotn(cid:241) konsekwencj(cid:241) tego faktu jest mo(cid:276)liwo(cid:264)(cid:232) sprawdzania w ca(cid:228)ym Internecie równo(cid:264)ci plików lub blobów dowolnego rozmiaru po prostu za pomoc(cid:241) porównania ich identyfikato- rów SHA1. Nazwy adresowane tre(cid:316)ci(cid:233) Magazyn obiektów Gita jest zorganizowany i zrealizowany w postaci systemu pami(cid:246)ci adre- sowanej tre(cid:264)ci(cid:241). W szczególno(cid:264)ci ka(cid:276)dy obiekt w magazynie obiektów ma niepowtarzaln(cid:241) nazw(cid:246) wytworzon(cid:241) przez potraktowanie tre(cid:264)ci obiektu algorytmem SHA1; w rezultacie powstaje warto(cid:264)(cid:232) haszowania SHA1. Poniewa(cid:276) do wytworzenia warto(cid:264)ci haszowania jest u(cid:276)y- wana ca(cid:228)a tre(cid:264)(cid:232) obiektu i mo(cid:276)na z du(cid:276)ym prawdopodobie(cid:254)stwem przyj(cid:241)(cid:232), (cid:276)e jest ona unika- towa dla tej konkretnej tre(cid:264)ci — warto(cid:264)(cid:232) haszowania SHA1 starczy za indeks, tj. nazw(cid:246) danego obiektu w bazie danych obiektów. Najmniejsza zmiana pliku powoduje zmian(cid:246) warto(cid:264)ci ha- szowania SHA1, powoduj(cid:241)c osobne zaindeksowanie nowej wersji pliku. Warto(cid:264)ci SHA1 s(cid:241) 160-bitowe i zwykle s(cid:241) reprezentowane w postaci 40-cyfrowej liczby szes- nastkowej, jak np. 9da581d910c9c4ac93557ca4859e767f5caf5169. Niekiedy, podczas wy- (cid:264)wietlania, warto(cid:264)ci SHA1 s(cid:241) skracane do mniejszego, jednoznacznego przedrostka. U(cid:276)ytkow- nicy Gita zwykli zamiennie u(cid:276)ywa(cid:232) okre(cid:264)le(cid:254) SHA1, kod haszowania (ang. hash code), a czasami ID obiektu5. Git nadzoruje tre(cid:316)(cid:235) Warto dojrze(cid:232) w Gicie co(cid:264) wi(cid:246)cej ni(cid:276) tylko system kontroli wersji. Git jest systemem nadzoro- wania tre(cid:264)ci (ang. content tracking system). Rozró(cid:276)nienie to, aczkolwiek subtelne, wywar(cid:228)o du- (cid:276)y wp(cid:228)yw na projekt Gita i niewykluczone, (cid:276)e w g(cid:228)ównej mierze przyczyni(cid:228)o si(cid:246) do tego, (cid:276)e mo(cid:276)e on stosunkowo (cid:228)atwo dokonywa(cid:232) manipulacji na wewn(cid:246)trznych danych. To równie(cid:276) jest by(cid:232) mo(cid:276)e jedn(cid:241) z najtrudniejszych koncepcji do opanowania przez nowych u(cid:276)ytkowników Gita, warto wi(cid:246)c po(cid:264)wi(cid:246)ci(cid:232) jej troch(cid:246) czasu. Gitowe (cid:264)ledzenie tre(cid:264)ci przejawia si(cid:246) na dwa zasadnicze sposoby, co stanowi podstawow(cid:241) ró(cid:276)nic(cid:246) w stosunku do prawie wszystkich innych6 systemów kontroli uaktualnie(cid:254). Po pierwsze, magazyn obiektów Gita jest oparty na haszowaniu tre(cid:264)ci jego obiektów, a nie na nazwach plików lub katalogów, takich, jakimi je ogl(cid:241)da u(cid:276)ytkownik. Kiedy wi(cid:246)c Git umieszcza plik w magazynie obiektów, robi to, wykorzystuj(cid:241)c haszowanie danych, a nie nazw(cid:246) pliku. 5 W innych tekstach produkt podobnych algorytmów haszuj(cid:241)cych zwyk(cid:228) by(cid:232) nazywany skrótem lub streszcze- niem komunikatu (ang. message digest); przewaga liczebna nazw nad bytami jest w informatyce powszechna — przyp. t(cid:228)um. 6 Chwalebnymi wyj(cid:241)tkami s(cid:241) tu systemy Monotone, Mercurial, OpenCMS i Venti. 46 (cid:95) Rozdzia(cid:293) 4. Podstawowe koncepcje Gita Kup książkęPoleć książkę Git w rzeczywisto(cid:264)ci nie (cid:264)ledzi nazw plików lub katalogów, s(cid:241) kojarzone z plikami drugo- rz(cid:246)dnie. Powtórzmy: Git nadzoruje tre(cid:264)(cid:232), a nie pliki. Je(cid:264)li dwa pliki maj(cid:241) t(cid:246) sam(cid:241) tre(cid:264)(cid:232) — wszystko jedno, czy wyst(cid:246)puj(cid:241) w tym samym, czy w ró(cid:276)- nych katalogach — to Git przechowuje w magazynie obiektów jedn(cid:241) kopi(cid:246) tej tre(cid:264)ci w posta- ci blobu. Git oblicza kod haszowy ka(cid:276)dego pliku, polegaj(cid:241)c wy(cid:228)(cid:241)cznie na jego tre(cid:264)ci, ustala, (cid:276)e pliki maj(cid:241) t(cid:246) sam(cid:241) warto(cid:264)(cid:232) SHA1, a wi(cid:246)c i t(cid:246) sam(cid:241) zawarto(cid:264)(cid:232), i umieszcza obiekt blobu w magazynie obiektów zaindeksowany t(cid:241) warto(cid:264)ci(cid:241) SHA1. Obu plikom w projekcie, nieza- le(cid:276)nie od ich usytuowania w strukturze katalogowej u(cid:276)ytkownika, odpowiada ten sam obiekt ich tre(cid:264)ci. Je(cid:264)li jeden z tych plików zostanie zmieniony, Git oblicza dla niego now(cid:241) warto(cid:264)(cid:232) SHA1, ustala, (cid:276)e jest on teraz innym obiektem blobu, i dodaje nowy blob do magazynu obiektów. Pierwotny blob pozostaje w magazynie obiektów na wypadek u(cid:276)ycia niezmienionego pliku. Po drugie, wewn(cid:246)trzna baza danych Gita efektywnie przechowuje ka(cid:276)d(cid:241) wersj(cid:246) ka(cid:276)dego pliku — nie ich ró(cid:276)nice7 — w miar(cid:246) powstawania kolejnych wyda(cid:254) pliku. Poniewa(cid:276) Git u(cid:276)ywa ha- szowania ca(cid:228)ej tre(cid:264)ci jako nazwy danego pliku, musi zawsze dzia(cid:228)a(cid:232) na kompletnej kopii pliku. Nie mo(cid:276)e opiera(cid:232) swej pracy ani wpisów w magazynie obiektów wy(cid:228)(cid:241)cznie na fragmencie zawarto(cid:264)ci pliku ani na ró(cid:276)nicach mi(cid:246)dzy dwoma jego wersjami. Z punktu widzenia u(cid:276)ytkownika pliku rzeczy zazwyczaj maj(cid:241) si(cid:246) tak, (cid:276)e plik ma kolejne uaktualnienia, pozostaj(cid:241)c jednym przedmiotem. Git oblicza histori(cid:246) tych uaktualnie(cid:254) jako zbiór zmian mi(cid:246)dzy poszczególnymi blobami o ró(cid:276)nych haszowaniach, nie zapami(cid:246)tuje natomiast nazwy pliku i zbioru zmian w sposób bezpo(cid:264)redni. Mo(cid:276)e to si(cid:246) wydawa(cid:232) osobliwe, lecz ta w(cid:228)a(cid:264)ciwo(cid:264)(cid:232) umo(cid:276)liwia Gitowi (cid:228)atwe wykonywanie pewnych zada(cid:254). Nazwy (cid:316)cie(cid:348)ek a tre(cid:316)(cid:235) Podobnie jak wiele innych VCS-ów, Git musi utrzymywa(cid:232) jawn(cid:241) list(cid:246) plików zawartych w ar- chiwum. Konieczno(cid:264)(cid:232) ta nie wymaga jednak, aby manifest8 Gita opiera(cid:228) si(cid:246) na nazwach plików. Git traktuje nazw(cid:246) pliku jako cz(cid:246)(cid:264)(cid:232) danych odr(cid:246)bn(cid:241) od tre(cid:264)ci pliku. W ten sposób oddziela indeks od danych w tradycyjnym rozumieniu bazy danych. Rzut oka na tabel(cid:246) 4.1, w której z grubsza porównano Gita z innymi znanymi systemami, mo(cid:276)e si(cid:246) tu okaza(cid:232) pomocny. Tabela 4.1. Porównanie baz danych System Tradycyjna baza danych Uniksowy system plików Git Mechanizm indeksowania Metoda indeksowanego dost(cid:253)pu sekwencyjnego (ISAM) Katalogi (/(cid:316)cie(cid:348)ka/do/pliku) .git/objects/hash, tre(cid:316)ci obiektów drzew Pami(cid:253)(cid:235) danych Rekordy danych Bloki danych Obiekty blobów, obiekty drzew Nazwy plików i katalogów pochodz(cid:241) z bie(cid:276)(cid:241)cego systemu plików, lecz dla Gita nie maj(cid:241) one w istocie znaczenia. Git zapisuje po prostu ka(cid:276)d(cid:241) nazw(cid:246) (cid:264)cie(cid:276)ki i zapewnia mo(cid:276)liwo(cid:264)(cid:232) do- k(cid:228)adnego odtworzenia plików i katalogów na podstawie jej tre(cid:264)ci, indeksowanej warto(cid:264)ci(cid:241) haszowania. 7 W oryginale: not their differences, porównaj jednak uwag(cid:246) o deltach w punkcie „Pliki pakowane” w tym pod- rozdziale — przyp. t(cid:228)um. 8 Tu: wykaz plików w bazie — przyp. t(cid:228)um. Archiwa (cid:95) 47 Kup książkęPoleć książkę Fizyczny wygl(cid:241)d danych Gita nie odzwierciedla struktury katalogowej plików u(cid:276)ytkownika. Pos(cid:228)uguje si(cid:246) on natomiast zupe(cid:228)nie inn(cid:241) struktur(cid:241), na podstawie której mo(cid:276)na jednak od- tworzy(cid:232) oryginaln(cid:241) posta(cid:232), widzian(cid:241) przez u(cid:276)ytkownika. Wewn(cid:246)trzna struktura danych Gita lepiej nadaje si(cid:246) do jego wewn(cid:246)trznych operacji i rozwi(cid:241)za(cid:254) pami(cid:246)ciowych. Kiedy Git chce utworzy(cid:232) katalog roboczy, mówi systemowi plików: „Hej, mam tu do umiesz- czenia du(cid:276)ego bloba, do którego prowadzi (cid:264)cie(cid:276)ka droga/do/katalogu/plik. Pojmujesz?”. System plików odpowiada: „O tak, rozpoznaj(cid:246) ten napis jako zestaw nazw podkatalogów i wiem, gdzie umie(cid:264)ci(cid:232) twój blob danych. Dzi(cid:246)kuj(cid:246)!”. Pliki pakowane Bystry czytelnik móg(cid:228)by sformu(cid:228)owa(cid:232) narzucaj(cid:241)ce si(cid:246) pytania o model danych Gita i sposób przechowywania poszczególnych plików: „Czy to nie jest skrajnie nieefektywne, aby ka(cid:276)d(cid:241) wersj(cid:246) ka(cid:276)dego pliku zapami(cid:246)tywa(cid:232) bezpo(cid:264)rednio? Nawet je(cid:264)li si(cid:246) go skompresuje, czy(cid:276) nie jest brakiem oszcz(cid:246)dno(cid:264)ci utrzymywanie pe(cid:228)nej tre(cid:264)ci ró(cid:276)nych wersji tego samego pliku? A je(cid:264)li, dajmy na to, dodasz do pliku tylko jeden wiersz, to Git b(cid:246)dzie przechowywa(cid:228) tre(cid:264)(cid:232) obu wersji w ca(cid:228)o(cid:264)ci?”. Na szcz(cid:246)(cid:264)cie odpowied(cid:274) brzmi: „Nie, naprawd(cid:246) nie!”. Git stosuje efektywniejszy mechanizm zapami(cid:246)tywania, zwany plikiem pakowanym. Aby utwo- rzy(cid:232) plik pakowany, Git wynajduje pliki o bardzo zbli(cid:276)onej tre(cid:264)ci i zapami(cid:246)tuje ca(cid:228)(cid:241) tre(cid:264)(cid:232) jed- nego z nich. Nast(cid:246)pnie oblicza ró(cid:276)nice, czyli delty, mi(cid:246)dzy podobnymi plikami i zapami(cid:246)tuje tylko te ró(cid:276)nice. Na przyk(cid:228)ad, gdyby(cid:264) zmieni(cid:228) tylko jeden wiersz pliku, to Git móg(cid:228)by zapa- mi(cid:246)ta(cid:232) w ca(cid:228)o(cid:264)ci nowsz(cid:241) wersj(cid:246), odnotowa(cid:232) t(cid:246) jednowierszow(cid:241) zmian(cid:246) jako delt(cid:246) i równie(cid:276) zapami(cid:246)ta(cid:232) j(cid:241) w paczce. Przechowywanie kompletnej wersji pliku oraz delt potrzebnych do skonstruowania innych wersji podobnych plików nie jest niczym nowym. Ten sam mechanizm jest od dziesi(cid:246)cioleci u(cid:276)ywany w innych VCS-ach, na przyk(cid:228)ad w systemie RCS9. Trzeba przyzna(cid:232), (cid:276)e Git wykonuje to pakowanie bardzo sprytnie. Poniewa(cid:276) Git jest sterowany tre(cid:264)ci(cid:241), zupe(cid:228)nie nie dba o to, czy delty, które oblicza jako ró(cid:276)nice mi(cid:246)dzy dwoma plikami, faktycznie odnosz(cid:241) si(cid:246) do dwóch wersji tego samego pliku, czy nie. To znaczy Git mo(cid:276)e wzi(cid:241)(cid:232) dowolne dwa pliki z dowolnego miejsca archiwum i obliczy(cid:232) delty mi(cid:246)dzy nimi, je(cid:264)li uwa(cid:276)a, (cid:276)e s(cid:241) dostatecznie podobne, aby zapewni(cid:232) dobr(cid:241) kompresj(cid:246). Git operuje zatem dobrze do- pracowanym algorytmem lokalizacji i dopasowywania potencjalnych kandydatów na delty globalnie, wskro(cid:264) ca(cid:228)ego archiwum. Co wi(cid:246)cej, Git potrafi konstruowa(cid:232) ci(cid:241)gi delt z jednej wersji pliku do drugiej, trzeciej itd. Dla ka(cid:276)dego kompletnego pliku w pakowanej reprezentacji Git utrzymuje równie(cid:276) wiedz(cid:246) o pierwotnym kodzie SHA1 blobu (stosuje si(cid:246) albo pe(cid:228)n(cid:241) tre(cid:264)(cid:232), albo rekonstrukcj(cid:246) wed(cid:228)ug delt). Stanowi to podstawowy mechanizm indeksu, umo(cid:276)liwiaj(cid:241)cy odnajdywanie obiektów w paczce. Pliki pakowane s(cid:241) przechowywane w magazynie obiektów wraz z innymi obiektami. U(cid:276)ywa si(cid:246) ich równie(cid:276) do sprawnego przesy(cid:228)ania archiwów przez sie(cid:232). 9 A jego pocz(cid:241)tków mo(cid:276)na szuka(cid:232) jeszcze dawniej, w pocz(cid:241)tku lat 70. XX wieku, kiedy to np. w systemie ope- racyjnym GEORGE 3 (ICL) istnia(cid:228) programowalny edytor tekstu: wszystkie zmiany w plikach by(cid:228)y wyra(cid:276)ane w postaci ci(cid:241)gu jego instrukcji; przechowuj(cid:241)c plik pocz(cid:241)tkowy i (ma(cid:228)e) pliki z instrukcjami dla edytora, mo(cid:276)na by(cid:228)o, w drodze kolejnych przetworze(cid:254) edytorem, uzyska(cid:232) ka(cid:276)d(cid:241) wersj(cid:246) pliku — przyp. t(cid:228)um. 48 (cid:95) Rozdzia(cid:293) 4. Podstawowe koncepcje Gita Kup książkęPoleć książkę Obrazy magazynu obiektów Spójrzmy, jak obiekty Gita przystaj(cid:241) do siebie i wspó(cid:228)pracuj(cid:241), tworz(cid:241)c kompletny system. Obiekt blobu znajduje si(cid:246) „na dnie” struktury danych; nie wskazuje niczego, a odniesienia do niego pochodz(cid:241) wy(cid:228)(cid:241)cznie z obiektów drzewa. Na poni(cid:276)szych rysunkach ka(cid:276)dy blob jest przedstawiony w postaci prostok(cid:241)ta. Obiekty drzew wskazuj(cid:241) na bloby i by(cid:232) mo(cid:276)e na inne drzewa. Dowolny obiekt drzewa mo(cid:276)e by(cid:232) wskazywany przez wiele ró(cid:276)nych obiektów zatwierdze(cid:254). Ka(cid:276)de drzewo jest reprezento- wane przez trójk(cid:241)t. Rysunek 4.1. Obiekty Gita Kó(cid:228)ko reprezentuje zatwierdzenie. Zatwierdzenie wskazuje na konkretne drzewo, wprowa- dzone do archiwum wskutek zatwierdzenia. Ka(cid:276)da metka (ang. tag) jest reprezentowana za pomoc(cid:241) równoleg(cid:228)oboku. Metka mo(cid:276)e wska- zywa(cid:232) najwy(cid:276)ej jedno zatwierdzenie. Odga(cid:228)(cid:246)zienie (ga(cid:228)(cid:241)(cid:274)) nie jest podstawowym obiektem Gita, lecz odgrywa zasadnicz(cid:241) rol(cid:246) w nazywaniu zatwierdze(cid:254). Ka(cid:276)de odga(cid:228)(cid:246)zienie jest rysowane w postaci prostok(cid:241)ta z zaokr(cid:241)- glonymi wierzcho(cid:228)kami. Na rysunku 4.1 pokazano, jak te wszystkie elementy maj(cid:241) si(cid:246) do siebie. Rysunek przedstawia stan archiwum po jednym, pocz(cid:241)tkowym zatwierdzeniu, w którym dodano dwa pliki. Oba pliki znajduj(cid:241) si(cid:246) w szczytowym katalogu. Zarówno odga(cid:228)(cid:246)zienie master, jak i metka V1.0 wskazuj(cid:241) na zatwierdzenie z identyfikatorem 1492. Skomplikujmy wi(cid:246)c nieco sprawy. Pozostawmy dwa oryginalne pliki bez zmian i dodajmy nowy podkatalog z jednym plikiem. Wynikowy magazyn obiektów b(cid:246)dzie wygl(cid:241)da(cid:228) jak na rysunku 4.2. Obrazy magazynu obiektów (cid:95) 49 Kup książkęPoleć książkę Jak na poprzednim rysunku, nowe zatwierdzenie powoduje dodanie jednego, skojarzonego z nim obiektu drzewa do reprezentowania ogólnego stanu struktury katalogowej i plików. W tym przypadku jest to obiekt drzewa z identyfikatorem cafed00d. Poniewa(cid:276) szczytowy katalog uleg(cid:228) zmianie przez dodanie nowego podkatalogu, zmieni(cid:228)a si(cid:246) równie(cid:276) tre(cid:264)(cid:232) szczytowego obiektu drzewa, tote(cid:276) Git wprowadzi(cid:228) nowe drzewo: cafed00d. Rysunek 4.2. Obiekty Gita po drugim zatwierdzeniu Bloby dead23 i feeb1e nie zmieni(cid:228)y si(cid:246) jednak mi(cid:246)dzy pierwszym a drugim zatwierdzeniem. Git jest (cid:264)wiadom, (cid:276)e ich identyfikatory nie uleg(cid:228)y zmianie, mo(cid:276)na si(cid:246) wi(cid:246)c do nich odwo(cid:228)ywa(cid:232) bezpo(cid:264)rednio i dzieli(cid:232) je w nowym drzewie cafed00d. Zwró(cid:232) uwag(cid:246) na kierunek strza(cid:228)ek mi(cid:246)dzy zatwierdzeniami. Zatwierdzenie rodzicielskie (lub wi(cid:246)cej takich zatwierdze(cid:254)) wyst(cid:241)pi(cid:228)o wcze(cid:264)niej. Dlatego w implementacji Gita ka(cid:276)de zatwier- dzenie wskazuje na swojego przodka lub przodków. Wielu osobom to si(cid:246) myli, poniewa(cid:276) stan archiwum jest na zasadzie umowy przedstawiany w odwrotnym kierunku: jako przep(cid:228)yw danych od zatwierdzenia rodzicielskiego do zatwierdze(cid:254) potomnych. W rozdziale 6 poszerzamy te obrazy, aby pokaza(cid:232), na czym polega budowanie historii ar- chiwum i manipulowanie ni(cid:241) za pomoc(cid:241) ró(cid:276)nych polece(cid:254). 50 (cid:95) Rozdzia(cid:293) 4. Podstawowe koncepcje Gita Kup książkęPoleć książkę Koncepcje Gita uwidocznione w dzia(cid:293)aniu Maj(cid:241)c za sob(cid:241) omówienie ogólnych pomys(cid:228)ów, zobaczmy, jakie znajduj(cid:241) one (i odpowiednie komponenty) odzwierciedlenie w samym archiwum. Utwórzmy nowe archiwum i przyjrzyjmy si(cid:246) nieco dok(cid:228)adniej jego wewn(cid:246)trznym plikom i magazynowi obiektów. Zawarto(cid:316)(cid:235) katalogu .git Zacznijmy od zainicjowania pustego archiwum za pomoc(cid:241) polecenia git init, po czym wy- konajmy polecenie find, aby zobaczy(cid:232), co powsta(cid:228)o. $ mkdir /tmp/hello $ cd /tmp/hello $ git init Initialized empty Git repository in /tmp/hello/.git/ # Sporz(cid:238)d(cid:351) wykaz wszystkich plików bie(cid:353)(cid:238)cego katalogu $ find . . ./.git ./.git/hooks ./.git/hooks/commit-msg.sample ./.git/hooks/applypatch-msg.sample ./.git/hooks/pre-applypatch.sample ./.git/hooks/post-commit.sample ./.git/hooks/pre-rebase.sample ./.git/hooks/post-receive.sample ./.git/hooks/prepare-commit-msg.sample ./.git/hooks/post-update.sample ./.git/hooks/pre-commit.sample ./.git/hooks/update.sample ./.git/refs ./.git/refs/heads ./.git/refs/tags ./.git/config ./.git/objects ./.git/objects/pack ./.git/objects/info ./.git/description ./.git/HEAD ./.git/branches ./.git/info ./.git/info/exclude Jak (cid:228)atwo zauwa(cid:276)y(cid:232), katalog .git zawiera niema(cid:228)o. Pliki s(cid:241) wy(cid:264)wietlane wed(cid:228)ug wzorcowego katalogu w uk(cid:228)adzie, który mo(cid:276)esz w razie potrzeby zmieni(cid:232). Zale(cid:276)nie od u(cid:276)ywanej przez Ciebie wersji Gita, to, co naprawd(cid:246) ujrzysz, mo(cid:276)e prezentowa(cid:232) si(cid:246) nieco inaczej. Na przyk(cid:228)ad w starszych wersjach Gita nie jest stosowany przyrostek .sample w plikach katalogu .git/hooks. Ogólnie bior(cid:241)c, nie musisz zagl(cid:241)da(cid:232) do plików w .git ani nimi manipulowa(cid:232). Te „ukryte” pliki s(cid:241) uwa(cid:276)ane za cz(cid:246)(cid:264)(cid:232) instalacji Gita, czyli jego konfiguracji. Git ma niewielki zbiór polece(cid:254) in- stalatorskich (ang. plumbing) do dzia(cid:228)ania na tych ukrytych plikach, lecz korzysta(cid:232) z nich b(cid:246)- dziesz rzadko. Na pocz(cid:241)tku katalog .gitobjects (katalog przeznaczony na wszystkie obiekty Gita) jest pusty, wyj(cid:241)wszy kilka wype(cid:228)niaczy. Koncepcje Gita uwidocznione w dzia(cid:293)aniu (cid:95) 51 Kup książkęPoleć książkę $ find .git/object .git/objects .git/objects/pack .git/objects/info Utwórzmy teraz starannie prosty obiekt: $ echo hello world hello.txt $ git add hello.txt Je(cid:264)li wpisa(cid:228)e(cid:264) hello world dok(cid:228)adnie tak, jak tu podano (nie zmieniaj(cid:241)c spacjowania ani wielko(cid:264)ci liter), to Twój katalog obiektów powinien obecnie wygl(cid:241)da(cid:232) tak: $ find .git/objects .git/objects .git/objects/pack .git/objects/3b .git/objects/3b/18e512dba79e4c8300dd08aeb37f8e728b8dad .git/objects/info Wszystko to wygl(cid:241)da do(cid:264)(cid:232) tajemniczo, lecz tylko na pozór, co wyja(cid:264)niamy w nast(cid:246)pnych podrozdzia(cid:228)ach. Obiekty, haszowania i bloby Tworz(cid:241)c obiekt dla hello.txt, Git nie dba o to, (cid:276)e nazw(cid:241) pliku jest hello.txt. Interesuje go tylko zawarto(cid:264)(cid:232) tego pliku: ci(cid:241)g 12 bajtów stanowi(cid:241)cych napis „hello world” wraz z ko(cid:254)cz(cid:241)cym go znakiem zmiany wiersza (sam blob, utworzony wcze(cid:264)niej). Git wykonuje na tym blobie kilka operacji, oblicza jego haszowanie SHA1 i wprowadza go do magazynu obiektów jako plik nazwany wed(cid:228)ug szesnastkowej reprezentacji haszowania. Sk(cid:233)d wiemy, (cid:348)e haszowanie SHA1 jest jednoznaczne? Istnieje nader ma(cid:228)a szansa, (cid:276)e dwa ró(cid:276)ne bloby wytworz(cid:241) to samo haszowanie SHA1. Je(cid:264)li tak si(cid:246) zdarzy, nazywamy to kolizj(cid:241). Kolizja SHA1 jest jednak tak ma(cid:228)o prawdopodobna, (cid:276)e mo(cid:276)esz bezpiecznie przyjmowa(cid:232), (cid:276)e nigdy nie zak(cid:228)óci ona naszego u(cid:276)ytkowania Gita. SHA1 jest „haszowaniem kryptograficznie bezpiecznym”. Do niedawna nie znano (cid:276)adnego sposobu (lepszego ni(cid:276) zdanie si(cid:246) na (cid:264)lepy los) spowodowania przez u(cid:276)ytkownika kolizji na (cid:276)yczenie. Czy jednak kolizja mog(cid:228)aby si(cid:246) zdarzy(cid:232) losowo? Zobaczmy! Maj(cid:241)c 160 bitów, dysponujesz 2160, czyli oko(cid:228)o 1048 (jedynka z 48 zerami po niej) mo(cid:276)liwymi haszowaniami SHA1. Jest to liczba niewyobra(cid:276)alnie wielka. Nawet gdyby(cid:264) wynaj(cid:241)(cid:228) bilion ludzi do produkowania biliona nowych blobów na sekund(cid:246) przez bilion lat, otrzyma(cid:228)by(cid:264) dopiero oko(cid:228)o 1043 blobów. Gdyby(cid:264) pohaszowa(cid:228) 280 losowych blobów, móg(cid:228)by(cid:264) znale(cid:274)(cid:232) kolizj(cid:246). Nie wierz nam. Poczytaj Bruce’a Schneiera10. 10 Zobacz: Bruce Schneier, Kryptografia dla praktyków. Protoko(cid:228)y, algorytmy i programy (cid:274)ród(cid:228)owe w j(cid:246)zyku C. Wydaw- nictwa Naukowo-Techniczne, Warszawa 2002 — przyp. t(cid:228)um. 52 (cid:95) Rozdzia(cid:293) 4. Podstawowe koncepcje Gita Kup książkęPoleć książkę Haszowaniem w tym wypadku jest 3b18e512dba79e4c8300dd08aeb37f8e728b8dad. 160 bitów haszowania SHA1 odpowiada 20 bajtom, do wy(cid:264)wietlenia których w kodzie szesnastkowym trzeba 40 bajtów, tre(cid:264)(cid:232) ta jest zatem zapami(cid:246)tana jako .git/objects/3b/18e512dba79e4c8300dd08aeb37f8e728b8dad. Git wstawia znak / po pierwszych dwóch cyfrach, aby polepszy(cid:232) efektywno(cid:264)(cid:232) systemu plików. (Niektóre systemy plików zwalniaj(cid:241), je(cid:264)li umie(cid:264)cisz zbyt wiele plików w tym samym katalogu; zrobienie z pierwszego bajta SHA1 nazwy katalogu jest prostym sposobem utworzenia sta(cid:228)ego, 256-dro(cid:276)nego podzia(cid:228)u przestrzeni nazw wszystkich mo(cid:276)liwych obiektów z równomiernym rozk(cid:228)adem). Aby pokaza(cid:232), (cid:276)e Git naprawd(cid:246) niewiele zrobi(cid:228) z tre(cid:264)ci(cid:241) pliku (jest ni(cid:241) wci(cid:241)(cid:276) podnosz(cid:241)ce na duchu „hello world”), mo(cid:276)esz pos(cid:228)u(cid:276)y(cid:232) si(cid:246) tym haszowaniem do wydobycia jej z magazynu obiektów, kiedy tylko zechcesz: $ git cat-file -p 3b18e512dba79e4c8300dd08aeb37f8e728b8dad hello world Git wie równie(cid:276), (cid:276)e r(cid:246)czne wpisywanie 40 znaków jest nieco ryzykowne, udost(cid:246)pnia wi(cid:246)c polecenie do poszukiwania obiektów za pomoc(cid:241) jednoznacznego przedrostka haszowania obiektu: $ git rev-parse 3b18e512d 3b18e512dba79e4c8300dd08aeb37f8e728b8dad Pliki i drzewa Kiedy ju(cid:276) blob „hello world” zosta(cid:228) bezpiecznie rozlokowany w magazynie obiektów, co sta(cid:228)o si(cid:246) z jego nazw(cid:241) pliku? Niewiele by(cid:228)oby po(cid:276)ytku z Gita, gdyby nie potrafi(cid:228) znajdowa(cid:232) plików na podstawie ich nazw. Wspomnieli(cid:264)my, (cid:276)e Git (cid:264)ledzi nazwy (cid:264)cie(cid:276)ek plików za pomoc(cid:241) obiektu innego rodzaju, na- zywanego drzewem. Gdy u(cid:276)ywasz git add, Git tworzy obiekt tre(cid:264)ci ka(cid:276)dego dodawanego przez Ciebie pliku, lecz nie od razu tworzy obiekt Twojego drzewa. Zamiast tego uaktualnia indeks. Indeks znajduje si(cid:246) w .git/index i rejestruje nazwy (cid:264)cie(cid:276)ek plików i odpowiednich blobów. Ilekro(cid:232) wydajesz polecenie w rodzaju git add, git rm, git mv, Git aktualizuje indeks, u(cid:276)y- waj(cid:241)c nowych (cid:264)cie(cid:276)ek i informacji blobowej. Kiedy tylko zechcesz, mo(cid:276)esz utworzy(cid:232) obiekt drzewa na podstawie bie(cid:276)(cid:241)cego indeksu, two- rz(cid:241)c migawkowe uj(cid:246)cie jego bie(cid:276)(cid:241)cej informacji za pomoc(cid:241) niskopoziomowego polecenia git write-tree. W danej sytuacji indeks zawiera tylko jeden plik: hello.txt. $ git ls-files -s 100644 3b18e512dba79e4c8300dd08aeb37f8e728b8dad 0 hello.txt Mo(cid:276)esz tu zaobserwowa(cid:232) powi(cid:241)zanie pliku hello.txt z blobem 3b18e5... Uchwy(cid:232)my teraz stan indeksu i przechowajmy go w obiekcie drzewa: $ git write-tree 68aba62e560c0ebc3396e8ae9335232cd93a3f60 $ find .git/objects .git/objects .git/objects/68 .git/objects/68/aba62e560c0ebc3396e8ae9335232cd93a3f60 Koncepcje Gita uwidocznione w dzia(cid:293)aniu (cid:95) 53 Kup książkęPoleć książkę .git/objects/pack .git/objects/3b .git/objects/3b/18e512dba79e4c8300dd08aeb37f8e728b8dad .git/objects/info Istniej(cid:241) obecnie dwa obiekty: „hello world” w 3b18e5 i nowy — obiekt drzewa w 68aba6. Jak wida(cid:232), nazwa SHA1 obiektu odpowiada dok(cid:228)adnie podkatalogowi i plikowi w .git/objects. Ale jak wygl(cid:241)da drzewo? Poniewa(cid:276) jest obiektem, podobnie jak blob, mo(cid:276)esz do jego obejrzenia u(cid:276)y(cid:232) tego samego niskopoziomowego polecenia. $ git cat-file -p 68aba6 100644 blob 3b18e512dba79e4c8300dd08aeb37f8e728b8dad hello.txt Zawarto(cid:264)(cid:232) tego obiektu powinna by(cid:232) (cid:228)atwa do zinterpretowania. Pierwsza liczba, 100644, re- prezentuje ósemkowo atrybuty pliku, co powinno by(cid:232) znane ka(cid:276)demu, kto u(cid:276)ywa(cid:228) uniksowego polecenia chmod. Z kolei 3b18e5 jest nazw(cid:241) obiektu blobu hello world, a hello.txt jest nazw(cid:241) stowarzyszon(cid:241) z tym blobem. (cid:227)atwo teraz zauwa(cid:276)y(cid:232), (cid:276)e obiekt drzewa ujmuje informacje, które by(cid:228)y w indeksie, gdy wy- konywa(cid:228)e(cid:264) polecenie git ls-files -s. Uwaga o zastosowaniu w Gicie algorytmu SHA1 Nim przyjrzymy si(cid:246) dok(cid:228)adniej obiektowi drzewa, zwró(cid:232)my uwag(cid:246) na wa(cid:276)n(cid:241) cech(cid:246) haszo- wa(cid:254) SHA1: $ git write-tree 68aba62e560c0ebc3396e8ae9335232cd93a3f60 $ git write-tree 68aba62e560c0ebc3396e8ae9335232cd93a3f60 $ git write-tree 68aba62e560c0ebc3396e8ae9335232cd93a3f60 Ka(cid:276)dorazowo, gdy obliczasz kolejny obiekt drzewa wed(cid:228)ug tego samego indeksu, haszowanie SHA1 pozostaje bez zmian. Git nie musi odtwarza(cid:232) nowego obiektu drzewa. Je(cid:264)li wykonasz powy(cid:276)sze kroki na komputerze, powiniene(cid:264) zobaczy(cid:232) dok(cid:228)adnie te same haszowania SHA1 co wydrukowane w ksi(cid:241)(cid:276)ce. W tym sensie haszowanie jest prawdziw(cid:241) funkcj(cid:241) w rozumieniu matematycznym: dla danej warto(cid:264)ci wej(cid:264)ciowej zawsze wytwarza ten sam wynik. Funkcja taka bywa czasami nazywana streszczeniem (ang. digest), aby podkre(cid:264)li(cid:232), (cid:276)e s(cid:228)u(cid:276)y jako pewien sposób uzwi(cid:246)(cid:274)lenia haszowa- nego obiektu. Oczywi(cid:264)cie ka(cid:276)da funkcja haszuj(cid:241)ca, nawet skromniutki bit parzysto(cid:264)ci, ma t(cid:246) w(cid:228)a(cid:264)ciwo(cid:264)(cid:232). Jest to nies(cid:228)ychanie wa(cid:276)ne. Je(cid:264)li na przyk(cid:228)ad utworzysz tak(cid:241) sam(cid:241) tre(cid:264)(cid:232) jak inny budowniczy, to niezale(cid:276)nie od tego kiedy lub jak obaj (lub oboje) pracowali(cid:264)cie, jednakowe haszowanie dowodzi w stopniu wystarczaj(cid:241)cym, (cid:276)e równie(cid:276) obie (i ca(cid:228)e) tre(cid:264)ci s(cid:241) identyczne. I rzeczywi- (cid:264)cie, Git b(cid:246)dzie je uwa(cid:276)a(cid:228) za jednakowe. Przejd(cid:274)my jednak do drugiego — przecie(cid:276) haszowania SHA1 mia(cid:228)y by(cid:232) unikatowe! Jak to jest z tym bilionem ludzi i ich bilionem blobów na sekund(cid:246), którzy nigdy nie wyprodukuj(cid:241) ani jednej kolizji? Jest to typowe (cid:274)ród(cid:228)o nieporozumie(cid:254) w(cid:264)ród nowych u(cid:276)ytkowników Gita. Czytaj wi(cid:246)c dalej uwa(cid:276)nie, bo je(cid:264)li zrozumiesz t(cid:246) ró(cid:276)nic(cid:246), to ca(cid:228)a reszta w tym rozdziale b(cid:246)dzie (cid:228)atwa. 54 (cid:95) Rozdzia(cid:293) 4. Podstawowe koncepcje Gita Kup książkęPoleć książkę Identyczne w danym wypadku haszowania SHA1 nie stanowi(cid:241) kolizji. Do kolizji dosz(cid:228)oby tylko wówczas, gdyby dwa ró(cid:276)ne obiekty da(cid:228)y w wyniku to samo haszowanie. Tutaj utworzy(cid:228)e(cid:264) dwa egzemplarze tej samej tre(cid:264)ci, a ta sama tre(cid:264)(cid:232) ma zawsze to samo haszowanie. Git opiera si(cid:246) na jeszcze innej konsekwencji funkcji haszowania SHA1: niewa(cid:276)ne, jak otrzy- ma(cid:228)e(cid:264) drzewo o nazwie 68aba62e560c0ebc3396e8ae9335232cd93a3f60. Je(cid:264)li je masz, mo(cid:276)esz by(cid:232) ponad wszelk(cid:241) w(cid:241)tpliwo(cid:264)(cid:232) pewny, (cid:276)e jest to ten sam obiekt drzewa co ten, który ma — dajmy na to — inny czytelnik tej ksi(cid:241)(cid:276)ki. Benek móg(cid:228) utworzy(cid:232) drzewo z kombinacji zatwier- dze(cid:254) A i B od Janki i zatwierdzenia C od Sergiusza, a Ty na podstawie zatwierdzenia A od Zuzi i uaktualnienia od Lakshmi, która po(cid:228)(cid:241)czy(cid:228)a zatwierdzenia B i C. Wyniki s(cid:241) takie same, a to umo(cid:276)liwia prowadzenie prac w rozproszeniu. Je(cid:264)li zostaniesz poproszony o wgl(cid:241)d w obiekt 68aba62e560c0ebc3396e8ae9335232cd93a3f60 i zdo(cid:228)asz taki obiekt znale(cid:274)(cid:232), to na mocy tego, (cid:276)e SHA1 jest haszowaniem kryptograficznym, mo(cid:276)esz by(cid:232) pewny, (cid:276)e patrzysz na te same dane, z których utworzono to haszowanie. Odwrotno(cid:264)(cid:232) jest równie(cid:276) prawdziwa: je(cid:264)li nie znajdziesz w swoim magazynie obiektu o da- nym haszowaniu, to mo(cid:276)esz mie(cid:232) pewno(cid:264)(cid:232), (cid:276)e nie dysponujesz kopi(cid:241) tego w(cid:228)a(cid:264)nie obiektu. Podsumujmy: mo(cid:276)esz okre(cid:264)li(cid:232), czy magazyn obiektów zawiera konkretny obiekt, czy nie, na- wet wówczas, gdy nie wiesz nic o jego (by(cid:232) mo(cid:276)e bardzo obszernej) tre(cid:264)ci. Haszowanie s(cid:228)u(cid:276)y wi(cid:246)c jako niezawodna etykieta lub nazwa obiektu. Git jednak polega jeszcze na czym(cid:264) mocniejszym ni(cid:276) powy(cid:276)sza konkluzja. Rozwa(cid:276)my naj- nowsze zatwierdzenie (lub skojarzony z nim obiekt drzewa). Poniewa(cid:276) jako cz(cid:246)(cid:264)(cid:232) tre(cid:264)ci zawie- ra ono haszowanie zatwierdze(cid:254) rodzicielskich i jego drzewa, a to z kolei zawiera haszowanie wszystkich jego poddrzew i blobów — rekurencyjnie wskro(cid:264) ca(cid:228)ej struktury danych, przez indukcj(cid:246) wynika z tego, (cid:276)e haszowanie oryginalnego zatwierdzenia jednoznacznie identyfikuje stan ca(cid:228)ej struktury danych ukorzenionej w danym zatwierdzeniu. Implikacje naszego stwierdzenia z poprzedniego akapitu prowadz(cid:241) na koniec do mocnego za- stosowania funkcji haszowania: stanowi ona efektywny (cid:264)rodek porównywania dwóch obiektów, w tym nawet bardzo du(cid:276)ych i z(cid:228)o(cid:276)onych struktur danych11, bez przekazywania (cid:276)adnej z nich w ca(cid:228)o(cid:264)ci. Hierarchie drzewiaste Dobrze jest mie(cid:232) informacje dotycz(cid:241)ce pojedynczego pliku, jak pokazali(cid:264)my w poprzednim podrozdziale, lecz przedsi(cid:246)wzi(cid:246)cia s(cid:241) z(cid:228)o(cid:276)one z g(cid:228)(cid:246)boko zagnie(cid:276)d(cid:276)anych katalogów, refakto- ryzowanych i przemieszczanych z biegiem czasu. Zobaczmy, jak Git radzi sobie z tym, two- rz(cid:241)c nowy podkatalog, który b(cid:246)dzie zawiera(cid:228) identyczn(cid:241) kopi(cid:246) pliku hello.txt. $ pwd /tmp/hello $ mkdir subdir $ cp hello.txt subdir/ $ git add subdir/hello.txt $ git write-tree 492413269336d21fac079d4a4672e55d5d2147ac $ git cat-file -p 4924132693 100644 blob 3b18e512dba79e4c8300dd08aeb37f8e728b8dad hello.txt 040000 tree 68aba62e560c0ebc3396e8ae9335232cd93a3f60 subdir 11 O tej strukturze danych mówimy wi(cid:246)cej w podrozdziale „Grafy zatwierdze(cid:254)” na stronie 74 rozdzia(cid:228)u 6. Koncepcje Gita uwidocznione w dzia(cid:293)aniu (cid:95) 55 Kup książkęPoleć książkę Nowe drzewo szczytowego poziomu zawiera dwa elementy: oryginalny plik hello.txt i nowy katalog subdir, który jest typu drzewo, a nie blob. Czy zauwa(cid:276)amy co(cid:264) niezwyk(cid:228)ego? Przypatrzmy si(cid:246) uwa(cid:276)niej nazwie obiektu subdir. To Twoja stara znajoma, 68aba62e560c0ebc3396e8ae9335232cd93a3f60! Co si(cid:246) sta(cid:228)o? Nowe drzewo dla subdir zawiera tylko jeden plik, hello.txt, a ten plik zawiera t(cid:246) sam(cid:241) co poprzednio tre(cid:264)(cid:232) „hello world”. Wobec tego drzewo subdir jest identyczne z po- przednim drzewem szczytowego poziomu! I oczywi(cid:264)cie ma t(cid:246) sam(cid:241) nazw(cid:246) SHA1 obiektu co przedtem. Spójrzmy na katalog .git/objects i zobaczmy, co spowodowa(cid:228)a ostatnia zmiana: $ find .git/objects .git/objects .git/objects/49 .git/objects/49/2413269336d21fac079d4a4672e55d5d2147ac .git/objects/68 .git/objects/68/aba62e560c0ebc3396e8ae9335232cd93a3f60 .git/objects/pack .git/objects/3b .git/objects/3b/18e512dba79e4c8300dd08aeb37f8e728b8dad .git/objects/info Nadal s(cid:241) w nim tylko trzy unikatowe obiekty: blob zawieraj(cid:241)cy „hello world”, drzewo zawie- raj(cid:241)ce plik hello.txt, który zawiera tekst „hello world” i zmian(cid:246) wiersza, oraz drugie drzewo, zawieraj(cid:241)ce drugie odniesienie do hello.txt, wraz z pierwszym drzewem. Zatwierdzenia Nast(cid:246)pnym obiektem do omówienia jest zatwierdzenie (ang. commit). Obecnie, po dodaniu hello.txt za pomoc(cid:241) git add i wyprodukowaniu za pomoc(cid:241) git write-tree obiektu drzewa, mo(cid:276)esz utworzy(cid:232) obiekt zatwierdzenia, korzystaj(cid:241)c z polecenia niskiego poziomu, na przyk(cid:228)ad tak: $ echo -n Zatwierdzenie pliku z powitaniem\n \ | git commit-tree 492413269336d21fac079d4a4672e55d5d2147ac 3ede4622cc241bcb09683af36360e7413b9ddf6c Wynik przybierze posta(cid:232) mniej wi(cid:246)cej tak(cid:241): $ git cat-file -p 3ede462 tree 492413269336d21fac079d4a4672e55d5d2147ac author Jon Loeliger jdl@example.com 1220233277 -0500 committer Jon Loeliger jdl@example.com 1220233277 -0500 Zatwierdzenie pliku z powitaniem Je(cid:264)li dorównujesz nam kroku na swoim komputerze, prawdopodobnie zauwa(cid:276)ysz, (cid:276)e wyge- nerowany przez Ciebie obiekt zatwierdzenia nie ma tej samej nazwy co w ksi(cid:241)(cid:276)ce. Je(cid:276)eli zro- zumia(cid:228)e(cid:264) wszystko do tej pory, przyczyna b(cid:246)dzie oczywista — to nie jest to samo zatwier- dzenie. Twoje zatwierdzenie zawiera Twoje nazwisko i czas, w którym go dokona(cid:228)e(cid:264), ró(cid:276)ni si(cid:246) zatem, cho(cid:232) jest to ró(cid:276)nica niewielka. Z drugiej strony, w Twoim zatwierdzeniu wyst(cid:246)puje to samo drzewo. To w(cid:228)a(cid:264)nie powoduje odr(cid:246)bno(cid:264)(cid:232) obiektów zatwierdze(cid:254) od ich obiektów drzew: ró(cid:276)ne zatwierdzenia cz(cid:246)sto odnosz(cid:241) si(cid:246) do tego samego drzewa. Kiedy si(cid:246) tak zdarzy, Git wykazuje na tyle inteligencji, aby przekazywa(cid:232) dalej tylko nowy obiekt zatwierdzenia, który jest malutki, a nie obiekty drzew i blobów, które s(cid:241) zapewne znacznie wi(cid:246)ksze. 56 (cid:95) Rozdzia(cid:293) 4. Podstawowe koncepcje Gita Kup książkęPoleć książkę W praktyce mo(cid:276)esz (a nawet powiniene(cid:264)!) omija(cid:232) niskopoziomowe kroki git write-tree i git commit-tree i u(cid:276)ywa(cid:232) po prostu polecenia git commit. Nie musisz pami(cid:246)ta(cid:232) wszystkich tych instalatorskich polece(cid:254), (cid:276)eby by(cid:232) (cid:264)wietnym u(cid:276)ytkownikiem Gita. Podstawowy obiekt zatwierdzenia jest do(cid:264)(cid:232) prosty i jest ostatnim sk(cid:228)adnikiem wymaganym w prawdziwym systemie kontroli uaktualnie(cid:254). Pokazany w(cid:228)a(cid:264)nie obiekt zatwierdzenia jest najprostszym z mo(cid:276)liwych i zawiera: (cid:120) nazw(cid:246) obiektu drzewa, która faktycznie identyfikuje stowarzyszone pliki; (cid:120) nazwisko osoby, która utworzy(cid:228)a now(cid:241) wersj(cid:246) (autora) i czas utworzenia; (cid:120) nazwisko osoby, która
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Kontrola wersji z systemem Git. Narzędzia i techniki programistów. Wydanie II
Autor:
,

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: