W tym artykule zajrzymy w zakamarki Gita, kt\u00f3re s\u0105 ukryte dla u\u017cytkownik\u00f3w, dop\u00f3ki ci nie wyka\u017c\u0105 zainteresowania nimi. Dzi\u0119ki temu dowiemy si\u0119, w jaki spos\u00f3b Git przechowuje informacje i jak nimi manipuluje<\/strong>.<\/p>\n\n\n\n \u017beby zrozumie\u0107 tre\u015bci zawarte w dalszej cz\u0119\u015bci artyku\u0142u, potrzebna b\u0119dzie przynajmniej podstawowa znajomo\u015b\u0107 Gita, bo skupimy si\u0119 na bardziej zaawansowanych kwestiach.<\/p>\n\n\n\n Nie jest trudno domy\u015bli\u0107 si\u0119, sk\u0105d Git wie, \u017ce jaki\u015b folder na dysku jest repozytorium lokalnym. Znakiem rozpoznawczym jest podfolder o nazwie .git<\/strong>, kt\u00f3ry znajduje si\u0119 w ka\u017cdym repozytorium. Jego zadaniem jest przechowywanie wszystkich danych, kt\u00f3re powstaj\u0105 podczas pracy z Gitem. Znajduje si\u0119 tam m. in. historia projektu.<\/p>\n\n\n\n Folder b\u0119d\u0105cy repozytorium lokalnym jest r\u00f3wnocze\u015bnie katalogiem roboczym. To znaczy, \u017ce zawiera pliki projektu, na kt\u00f3rych pracujemy i kt\u00f3re modyfikujemy. Po\u015br\u00f3d nich znajduje si\u0119 wcze\u015bniej wspomniany folder .git. Mo\u017cna bez przeszk\u00f3d zajrze\u0107 do jego wn\u0119trza (co zreszt\u0105 zrobimy w jednym z kolejnych akapit\u00f3w). Pozwoli nam to lepiej zrozumie\u0107 specyfik\u0119 dzia\u0142ania Gita. Nie ma jednak potrzeby wykonywa\u0107 manualnie jakichkolwiek operacji na tym specjalnym folderze. S\u0142u\u017cy on Gitowi i to Git powinien zajmowa\u0107 si\u0119 jego zarz\u0105dzaniem. Jako u\u017cytkownicy dostajemy od Gita szerok\u0105 gam\u0119 narz\u0119dzi<\/strong>, kt\u00f3re pokrywaj\u0105 wi\u0119kszo\u015b\u0107 naszych potrzeb. Dzi\u0119ki temu nie musimy ingerowa\u0107 w wewn\u0119trzne struktury Gita.<\/p>\n\n\n\n Istotn\u0105 informacj\u0105 jest dla nas fakt, \u017ce Git przechowuje histori\u0119 zmian plik\u00f3w projektu za pomoc\u0105 ich kopii. Oznacza to, \u017ce kiedy dokonamy jakich\u015b zmian w pliku i utworzymy commit, Git automatycznie utworzy sobie kopi\u0119 tego pliku. B\u0119dzie ona dok\u0142adnym odwzorowaniem pliku z katalogu roboczego. Nast\u0119pnie zostanie umieszczona w folderze .git i pozostanie w nim ju\u017c niezmieniona.<\/p>\n\n\n\n W repozytorium istnieje wiele wersji jednego pliku, kt\u00f3re nieco si\u0119 od siebie r\u00f3\u017cni\u0105. S\u0105 to r\u00f3\u017cnice wynikaj\u0105ce z wykonywanych zmian podczas pracy nad projektem. Jedn\u0105 wersj\u0119 pliku znajdziemy przede wszystkim w katalogu roboczym. To j\u0105 modyfikujemy, pracuj\u0105c nad projektem. Je\u017celi dodamy plik do przechowalni (ang. staging area<\/em>) za pomoc\u0105 W innych systemach kontroli wersji, gdy chcemy cofn\u0105\u0107 si\u0119 do odleg\u0142ego commita z przesz\u0142o\u015bci, konieczne jest przej\u015bcie po wszystkich nowszych od niego commitach. Po drodze odczytywane s\u0105 kolejne zmiany, jakie by\u0142y wykonane na pliku, a\u017c do momentu, gdy zostanie przywr\u00f3cona po\u017c\u0105dana wersja. W Gicie ten proces jest znacznie prostszy, gdy\u017c posiada on zapisan\u0105 wersj\u0119 pliku dla interesuj\u0105cego nas commita. Prze\u0142\u0105czaj\u0105c si\u0119 na ten commit, wystarczy w folderze .git znale\u017a\u0107 plik z t\u0105 wersj\u0105. Jest to znacznie szybsze ni\u017c w innych systemach kontroli wersji.<\/p>\n\n\n\n Do pracy na lokalnym repozytorium niepotrzebne jest aktywne po\u0142\u0105czenie internetowe z repozytorium zdalnym. Jest ono wymagane tylko podczas pobierania i wysy\u0142ania zmian. Ponadto, nie jest nawet konieczne, \u017ceby repozytorium zdalne istnia\u0142o, mo\u017cliwa jest praca jedynie na repozytorium lokalnym. Nie ma \u017cadnych przeciwwskaza\u0144, \u017ceby utworzy\u0107 repozytorium zdalne p\u00f3\u017aniej i wtedy po\u0142\u0105czy\u0107 je z lokalnym, a co wi\u0119cej, mo\u017cliwe jest te\u017c po\u0142\u0105czenie z wi\u0119cej ni\u017c jednym repozytorium zdalnym. Taki mechanizm<\/a> wykorzystuj\u0105 m.in. Github czy GitLab by udost\u0119pni\u0107 funkcj\u0119 fork.<\/p>\n\n\n\n Git przechowuje commity w postaci plik\u00f3w o niewielkich rozmiarach. Ka\u017cdy commit zawiera ustalony z g\u00f3ry zestaw informacji. S\u0105 to:<\/p>\n\n\n\n Ka\u017cdy commit posiada r\u00f3wnie\u017c unikalny identyfikator, kt\u00f3ry nazywany jest te\u017c skr\u00f3tem. Jest to ci\u0105g 40 liczb szesnastkowych. Skr\u00f3t wyliczany jest za pomoc\u0105 algorytmu SHA-1 na podstawie zawarto\u015bci, jaka znajduje si\u0119 w pliku commita. Ka\u017cdy skr\u00f3t jest inny, poniewa\u017c ka\u017cdy commit b\u0119dzie zawiera\u0142 nieco inne dane. Skr\u00f3t przypisany commitowi nie b\u0119dzie si\u0119 te\u017c nigdy zmienia\u0142, gdy\u017c commity s\u0105 niemodyfikowalne \u2013 nie jeste\u015bmy w stanie \u017cadnym poleceniem Gita zmieni\u0107 istniej\u0105cego commita.<\/p>\n\n\n\n Niekt\u00f3re polecenia, jak np. Otrzymujemy nowy commit w miejsce starego, kt\u00f3ry jednak nie przepada bezpowrotnie i zawsze mo\u017cemy go odzyska\u0107, je\u015bli zajdzie taka potrzeba. Efekt wykonania polecenia Wi\u0119kszo\u015b\u0107 commit\u00f3w posiada odniesienie do swoich commit\u00f3w-rodzic\u00f3w<\/strong>, bo w ten spos\u00f3b Git buduje histori\u0119 \u2013 jako ci\u0105g nast\u0119puj\u0105cych po sobie commit\u00f3w. Istniej\u0105 tak\u017ce commity bez rodzica<\/strong>. Najcz\u0119stszym takim przypadkiem jest po prostu pierwszy commit w historii repozytorium, kt\u00f3ry nie ma swojego poprzednika. Mo\u017cliwe jest r\u00f3wnie\u017c samodzielne utworzenie takiego commita, kt\u00f3ry nie posiada rodzica<\/a>.<\/p>\n\n\n\n Cz\u0119sto natomiast commity miewaj\u0105 dwoje rodzic\u00f3w. S\u0105 to merge-commity<\/strong>, powsta\u0142e w wyniku \u0142\u0105czenia (ang. merging<\/em>) dw\u00f3ch ga\u0142\u0119zi. W\u0142a\u015bciwie od standardowych commit\u00f3w r\u00f3\u017cni\u0105 si\u0119 jedynie posiadaniem drugiego rodzica. Poza tym plik merge-commita posiada dok\u0142adnie taki sam zestaw informacji jak zwyk\u0142y commit.<\/p>\n\n\n\n Wiemy ju\u017c, jakie informacje wchodz\u0105 w sk\u0142ad pliku commita. Na tej podstawie mo\u017cemy stwierdzi\u0107, \u017ce jego rozmiar nie zale\u017cy od ilo\u015bci zmian w projekcie jakie zawiera. W takim razie sk\u0105d Git w\u0142a\u015bciwie wie, jakie zmiany zosta\u0142y wykonane w ramach commita?<\/p>\n\n\n\n W tym celu wykorzystuje pliki tree<\/em>. Ka\u017cdy commit posiada odniesienie do jednego z takich plik\u00f3w. Odniesieniem jest oczywi\u015bcie skr\u00f3t SHA-1<\/strong>, wyliczony na podstawie zawarto\u015bci pliku tree<\/em>, tak jak w przypadku commita. Plik tree<\/em> zawiera list\u0119 plik\u00f3w i podfolder\u00f3w, jakie znajduj\u0105 si\u0119 w konkretnym folderze projektu. Commit wskazuje na plik tree, <\/em>kt\u00f3ry odpowiada zawarto\u015bci katalogu roboczego. Plik tree<\/em> przyporz\u0105dkowuje ka\u017cdemu podfolderowi inny plik tree<\/em>, a ka\u017cdemu plikowi plik blob<\/em>.<\/p>\n\n\n\n Pliki blob<\/em> to kopie plik\u00f3w projektowych zrobione w momencie tworzenia commita. Pliki tree<\/em> tworz\u0105 drzewiast\u0105 struktur\u0119, odpowiadaj\u0105c\u0105 strukturze katalogu roboczego. Obrazuje to poni\u017cszy rysunek – po lewej stronie pokazana jest struktura folder\u00f3w, a po prawej powi\u0105zania w plikach tree<\/em> i blob.<\/em><\/p>\n\n\n\n Podczas tworzeniu commita, Git dodaje nowe pliki tree <\/em>i blob <\/em>tylko dla plik\u00f3w projektowych, kt\u00f3re uleg\u0142y zmianie. Dla pozosta\u0142ych plik\u00f3w wykorzystywane s\u0105 istniej\u0105ce ju\u017c pliki tree<\/em> i blob<\/em>. Git przechowuje je w postaci skompresowanej. Je\u017celi znamy skr\u00f3t interesuj\u0105cego nas pliku, to mo\u017cemy z \u0142atwo\u015bci\u0105 odczyta\u0107 jego zawarto\u015b\u0107 za pomoc\u0105 komendy: Zach\u0119cam do przetestowania jej na dowolnym repozytorium Gita. \u017beby znale\u017a\u0107 skr\u00f3t ostatniego commita, wystarczy u\u017cy\u0107 polecenia Ga\u0142\u0119zie w Gicie s\u0105 jednym z element\u00f3w, kt\u00f3re najbardziej odr\u00f3\u017cniaj\u0105 go od innych system\u00f3w kontroli wersji. Cz\u0119sto mylnie uwa\u017ca si\u0119, \u017ce ga\u0142\u0105\u017a jest zbiorem commit\u00f3w, co mo\u017cna by zobrazowa\u0107 w nast\u0119puj\u0105cy spos\u00f3b:<\/p>\n\n\n\n Nie jest to jednak zgodne z prawd\u0105. Ga\u0142\u0105\u017a w Gicie jest tak naprawd\u0119 tylko wska\u017anikiem na pojedynczy commit. Git przechowuje ga\u0142\u0119zie w postaci plik\u00f3w, co nie powinno ju\u017c by\u0107 zaskoczeniem. W dodatku plik\u00f3w o niewielkich rozmiarach, bo zawieraj\u0105cych jedynie 40 znak\u00f3w. Brzmi znajomo, prawda? Jest to oczywi\u015bcie skr\u00f3t SHA-1 commitu. Czyni to prac\u0119 z ga\u0142\u0119ziami naprawd\u0119 wydajn\u0105. Podczas tworzenia nowej ga\u0142\u0119zi nie s\u0105 wykonywane \u017cadne wymagaj\u0105ce operacje ani nie nast\u0119puje kopiowanie jakichkolwiek plik\u00f3w, jak dzieje si\u0119 w innych systemach kontroli wersji. Git ogranicza si\u0119 do utworzenia jednego niewielkiego pliku. Prze\u0142\u0105czanie si\u0119 mi\u0119dzy ga\u0142\u0119ziami te\u017c jest szybk\u0105 operacj\u0105. Ten proces opisa\u0142em szerzej w paragrafie \u201eCo dzieje si\u0119 za kulisami\u201d.<\/p>\n\n\n\n Ga\u0142\u0105\u017a, na kt\u00f3rej pracujemy, pod\u0105\u017ca za kolejnymi commitami. To znaczy, \u017ce po utworzeniu commita, Git aktualizuje wska\u017anik ga\u0142\u0119zi, tak by wskazywa\u0142 na nowy commit. By ten mechanizm by\u0142 mo\u017cliwy, istnieje specjalny wska\u017anik HEAD, kt\u00f3ry\u2026 r\u00f3wnie\u017c jest plikiem. HEAD przechowuje informacj\u0119 o tym, na jakiej obecnie ga\u0142\u0119zi si\u0119 znajdujemy. Czyli HEAD wskazuje na ga\u0142\u0105\u017a, kt\u00f3ra wskazuje na commit. Commit z kolei wskazuje na plik tree<\/em>, a plik tree<\/em> zawiera odniesienia do plik\u00f3w blob<\/em>. Pliki blob <\/em>to konkretne wersje plik\u00f3w projektowych.<\/p>\n\n\n\n Chocia\u017c najcz\u0119\u015bciej prze\u0142\u0105czamy si\u0119 na konkretn\u0105 ga\u0142\u0105\u017a, mo\u017cliwe jest te\u017c prze\u0142\u0105czenie si\u0119 na wskazany commit. Wystarczy poda\u0107 skr\u00f3t commita, u\u017cywaj\u0105c polecenia git checkout SKROT. Wtedy plik HEAD b\u0119dzie zawiera\u0142 skr\u00f3t tego commita, a nie nazw\u0119 ga\u0142\u0119zi. Taki stan nosi nazw\u0119 detached HEAD<\/em>. Git ostrzega nas jednak przed wykonywaniem tej czynno\u015bci, gdy\u017c \u0142atwo mo\u017cna utraci\u0107 wszystkie odniesienia do nowych commit\u00f3w. W tym stanie, HEAD wskazuje na konkretny commit.<\/p>\n\n\n\n Je\u017celi utworzymy nowy commit, to HEAD zostanie zaktualizowany i b\u0119dzie na niego wskazywa\u0107. B\u0119dzie to jednak jedyne odniesienie do nowego commita, gdy\u017c \u017cadna ga\u0142\u0105\u017a nie b\u0119dzie na niego wskazywa\u0107. Po prze\u0142\u0105czeniu si\u0119 na inn\u0105 ga\u0142\u0105\u017a, HEAD nie b\u0119dzie ju\u017c wskazywa\u0142 nowego commita i nie b\u0119dzie istnia\u0142o do niego ju\u017c \u017cadne inne odniesienie. Git go nie usunie (a przynajmniej nie od razu), wi\u0119c ci\u0105gle mo\u017cliwe b\u0119dzie jego u\u017cycie. Niemniej, dost\u0119p do niego b\u0119dzie utrudniony.<\/p>\n\n\n\n Dobrym sposobem na zrozumienie mechanizm\u00f3w pracy z ga\u0142\u0119ziami w Gicie jest wizualizowanie sobie ca\u0142ego procesu. Dost\u0119pny jest interaktywny kurs<\/a>, kt\u00f3ry wy\u015bwietla struktur\u0119 ga\u0142\u0119zi w postaci animowanego grafu. Wykonuj\u0105c kolejne operacje, widzimy na bie\u017c\u0105co jakie zmiany zachodz\u0105 w ga\u0142\u0119ziach. Zach\u0119cam do zapoznania si\u0119 chocia\u017c z pocz\u0105tkowymi lekcjami tego kursu.<\/p>\n\n\n\n Folder .git jest baz\u0105 danych Gita. Zawiera wszystkie informacje potrzebne do pracy z repozytorium. Git przechowuje je w formie plik\u00f3w. Cz\u0119\u015b\u0107 z nich ma posta\u0107 skompresowan\u0105, by oszcz\u0119dza\u0107 miejsce na dysku.<\/p>\n\n\n\n Folder .git zawiera nast\u0119puj\u0105ce elementy:<\/p>\n\n\n\n Z naszego punktu widzenia interesuj\u0105cy jest folder objects<\/em>, gdzie Git przechowuje pliki tree <\/em>i blob<\/em>. Ciekawy jest zw\u0142aszcza spos\u00f3b w jaki Git to robi. Gdy zajrzymy do folderu objects, <\/em>znajdziemy w nim w wi\u0119kszo\u015bci podfoldery, kt\u00f3rych nazwa sk\u0142ada si\u0119 z dok\u0142adnie dw\u00f3ch znak\u00f3w \u2013 liczb szesnastkowych. S\u0105 to dwa pierwsze znaki skr\u00f3t\u00f3w plik\u00f3w tree <\/em>i blob, <\/em>kt\u00f3re znajduj\u0105 si\u0119 w tych folderach. Jest to rozwi\u0105zanie poprawiaj\u0105ce wydajno\u015b\u0107 przy wyszukiwaniu konkretnych plik\u00f3w po ich skr\u00f3tach, gdy\u017c ogranicza liczb\u0119 plik\u00f3w jak\u0105 trzeba sprawdzi\u0107, by znale\u017a\u0107 ten w\u0142a\u015bciwy.<\/p>\n\n\n\n W folderze objects <\/em>znajduje si\u0119 r\u00f3wnie\u017c podfolder o nazwie pack<\/em>. Przechowuje on pliki binarne zwane packfile<\/em>. \u017beby wyt\u0142umaczy\u0107 jaka jest ich rola, trzeba najpierw wyja\u015bni\u0107 w jaki spos\u00f3b Git zapisuje zmiany w projekcie.<\/p>\n\n\n\n Jak wspomina\u0142em wcze\u015bniej, Git u\u017cywa w tym celu plik\u00f3w blob. <\/em>S\u0105 to po prostu kopie plik\u00f3w z katalogu roboczego. Je\u017celi commit zawiera zmian\u0119 tylko w jednej linijce pliku, to Git i tak wykona kopi\u0119 ca\u0142ego tego pliku. Mo\u017ce sta\u0107 si\u0119 to problematyczne, gdy plik jest du\u017cych rozmiar\u00f3w i wprowadzane s\u0105 do niego cz\u0119sto zmiany. Wtedy kopie takiego pliku b\u0119d\u0105 niepotrzebnie zabiera\u0142y miejsce na dysku. \u017beby temu zapobiec, Git posiada mechanizm zbieraj\u0105cy takie zmiany w jednym pliku. Tym plikiem jest w\u0142a\u015bnie packfile<\/em>. Przechowuje on zmiany w postaci r\u00f3\u017cnic. To znaczy, \u017ce zapisywane s\u0105 tylko te fragmenty, kt\u00f3re uleg\u0142y zmianie, a nie ca\u0142e kopie pliku. Pliki blob <\/em>odpowiadaj\u0105ce tym zmianom mog\u0105 zosta\u0107 usuni\u0119te, co zwalnia miejsce na dysku.<\/p>\n\n\n\n Warto jeszcze wspomnie\u0107 o pliku index, <\/em>kt\u00f3ry znajduje si\u0119 bezpo\u015brednio w folderze .git. Git zapisuje zawarto\u015b\u0107 plik\u00f3w w momencie dodawania ich do staging area.<\/em> W tym celu korzysta ze znanych ju\u017c plik\u00f3w blob. <\/em>Zatem ka\u017cdy plik dodany do staging area <\/em>ma sw\u00f3j plik blob<\/em>. Plik index <\/em>zawiera list\u0119 plik\u00f3w w staging area<\/em> wraz z odpowiadaj\u0105cym im plikami blob<\/em>.<\/p>\n\n\n\n Warto podsumowa\u0107 zebrane do tej pory informacje. Prze\u015bled\u017amy zmiany, jakie zachodz\u0105 w repozytorium lokalnym, podczas codziennej pracy z Gitem. B\u0119dzie to dobry spos\u00f3b na uporz\u0105dkowanie wiedzy.<\/p>\n\n\n\n Zacznijmy od pustego folderu przeznaczonego na repozytorium projektu. Pierwszym krokiem jest sklonowanie repozytorium zdalnego za pomoc\u0105 komendy Kiedy tworzymy now\u0105 ga\u0142\u0105\u017a poleceniem Po wprowadzeniu zmian do projektu, dodajemy wybrane pliki do staging area<\/em> za pomoc\u0105 polecenia Wykonuj\u0105c commit, korzystamy z polecenia To pytanie cz\u0119sto pada na rozmowach kwalifikacyjnych<\/strong>, wi\u0119c warto zna\u0107 na nie odpowied\u017a. Przyjrzyjmy si\u0119, jakie mechanizmy zadzia\u0142aj\u0105, podczas wykonywania tych polece\u0144.<\/p>\n\n\n\n Zadaniem obu, jest po\u0142\u0105czenie zmian z dw\u00f3ch ga\u0142\u0119zi. Robi\u0105 to jednak w inny spos\u00f3b.<\/p>\n\n\n\n Dzia\u0142anie komendy rebase<\/em> <\/strong>polega na skopiowaniu commit\u00f3w. Wskazujemy ga\u0142\u0105\u017a docelow\u0105: Commity wybierane s\u0105 z ga\u0142\u0119zi, na kt\u00f3rej si\u0119 znajdujemy. Wybierane s\u0105 jedynie te commity, kt\u00f3rych nie ma na ga\u0142\u0119zi docelowej. M\u00f3wi\u0105c dok\u0142adniej, s\u0105 to commity, do kt\u00f3rych nie mo\u017cna dotrze\u0107, poruszaj\u0105c si\u0119 po kolejnych rodzicach commita wskazywanego przez ga\u0142\u0105\u017a docelow\u0105. Opr\u00f3cz kopiowania commit\u00f3w, wa\u017cn\u0105 operacj\u0105 wykonywan\u0105 podczas rebase,<\/em> jest przeniesienie wska\u017anika bie\u017c\u0105cej ga\u0142\u0119zi na najnowszy skopiowany commit. Rysunki poni\u017cej przedstawiaj\u0105 sytuacj\u0119 przed i po wykonaniu polecenia: List\u0119 commit\u00f3w, kt\u00f3re zostan\u0105 skopiowane mo\u017cemy znale\u017a\u0107 za pomoc\u0105 polecenia Komenda merge<\/em> <\/strong>tak\u017ce s\u0142u\u017cy do \u0142\u0105czenia zmian z dw\u00f3ch ga\u0142\u0119zi, ale w przeciwie\u0144stwie do rebase,<\/em> nie kopiuje \u017cadnych commit\u00f3w. Merge <\/em>mo\u017ce zosta\u0107 wykonany na dwa sposoby.<\/p>\n\n\n\n W repozytorium lokalnym znajduj\u0105 si\u0119 specjalne ga\u0142\u0119zie zdalne, kt\u00f3rych zadaniem jest odzwierciedlanie zmian w repozytorium zdalnym. To znaczy, \u017ce b\u0119d\u0105 zawiera\u0107 te same commity, co ga\u0142\u0119zie w repozytorium zdalnym, kt\u00f3re \u015bledz\u0105. Kiedy pobieramy commity z repozytorium zdalnego, trafiaj\u0105 one do odpowiednich ga\u0142\u0119zi zdalnych. Nazwy tych ga\u0142\u0119zi zawieraj\u0105 przedrostek z nazw\u0105 repozytorium zdalnego, np. origin\/master. Origin <\/em>to domy\u015blna nazwa repozytorium zdalnego, a master<\/em> nazwa \u015bledzonej ga\u0142\u0119zi w tym repozytorium.<\/p>\n\n\n\n Ga\u0142\u0105\u017a lokalna i jej zdalny odpowiednik nie musz\u0105 zawsze wskazywa\u0107 tego samego commitu. Je\u017celi b\u0119d\u0105c na ga\u0142\u0119zi master<\/em>, utworzyli\u015bmy nowy commit, a nie wys\u0142ali\u015bmy go jeszcze do repozytorium zdalnego, to origin\/master<\/em> nie b\u0119dzie wskazywa\u0142 tego commitu. Mo\u017ce te\u017c zdarzy\u0107 si\u0119 odwrotna sytuacja, gdy pobierzemy najnowsze zmiany z repozytorium zdalnego i znajd\u0105 si\u0119 one tylko na ga\u0142\u0119zi origin\/master<\/em>, ale nie b\u0119dzie ich jeszcze na ga\u0142\u0119zi master<\/em>.<\/p>\n\n\n\n Taki efekt osi\u0105gniemy przy pomocy komendy Czym jest repozytorium?<\/h2>\n\n\n\n
Wersje plik\u00f3w<\/h3>\n\n\n\n
git add<\/code>, to Git utworzy jego kopi\u0119. Umie\u015bci j\u0105 w folderze .git, kt\u00f3ry b\u0119dzie zawiera\u0142 pozosta\u0142e wersje pliku. Innymi s\u0142owy, Git posiada osobn\u0105 wersj\u0119 pliku dla ka\u017cdego commita, w kt\u00f3rym ten plik zosta\u0142 zmodyfikowany.<\/strong> Dzi\u0119ki temu prze\u0142\u0105czanie si\u0119 mi\u0119dzy commitami jest bardzo wydajne.<\/p>\n\n\n\nCzym jest commit?<\/h2>\n\n\n\n
git commit --amend<\/code>, daj\u0105 nam poczucie, \u017ce wykonali\u015bmy zmiany w commicie, ale tak naprawd\u0119 tworz\u0105 one nowe commity na wz\u00f3r ju\u017c istniej\u0105cych. W efekcie wykonania tych komend w repozytorium b\u0119d\u0105 znajdowa\u0107 si\u0119 dwa commity. Ten pierwszy nie zostanie usuni\u0119ty, ale najcz\u0119\u015bciej utracimy do niego odniesienie. Nadal b\u0119dzie istnia\u0142 w repozytorium, ale dost\u0119p do niego b\u0119dzie utrudniony, co jest do\u015b\u0107 schludnym rozwi\u0105zaniem.<\/p>\n\n\n\ngit commit --amend <\/code>wida\u0107 na rysunku poni\u017cej. Pokazuje on, \u017ce zosta\u0142a utworzona kopia commita C2, na kt\u00f3rym wykonano operacj\u0119 amend<\/em>.<\/p>\n\n\n\n![\"Efekt](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2021\/01\/01_amend-git-300x90.png\")
<\/a><\/figure><\/div>\n\n\n\nRodzaje commit\u00f3w<\/h3>\n\n\n\n
Wykorzystanie plik\u00f3w tree<\/h3>\n\n\n\n
![\"Struktura](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2021\/01\/02_tree-blob-diagram-git-e1611576005171.png\")
<\/a><\/figure><\/div>\n\n\n\ngit cat-file -p SKROT<\/code><\/p>\n\n\n\ngit log -1<\/code><\/p>\n\n\n\nCzym jest ga\u0142\u0105\u017a?<\/h2>\n\n\n\n
![\"\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2021\/01\/03_branch-git-300x290.png\")
<\/a><\/figure><\/div>\n\n\n\nPrze\u0142\u0105czanie na wskazany commit<\/h3>\n\n\n\n
Jak zbudowany jest folder .git?<\/h2>\n\n\n\n
Folder objects<\/h3>\n\n\n\n
Podfolder pack i plik index<\/h3>\n\n\n\n
Co dzieje si\u0119 za kulisami?<\/h2>\n\n\n\n
git clone<\/code>. W efekcie w folderze lokalnym jest tworzony folder .git ze znan\u0105 ju\u017c nam zawarto\u015bci\u0105. W pliku .git\/config zostaje zapisane odniesienie do zdalnego repozytorium z domy\u015bln\u0105 nazw\u0105 origin.<\/em> Dzi\u0119ki temu Git wie, jak si\u0119 z nim po\u0142\u0105czy\u0107. Plik .git\/refs\/remotes\/origin\/HEAD wskazuje domy\u015bln\u0105 ga\u0142\u0105\u017a w repozytorium zdalnym. Najcz\u0119\u015bciej jest to master. <\/em>Git sprawdza jaki commit jest wskazywany przez t\u0119 ga\u0142\u0105\u017a, a nast\u0119pnie znajduje plik tree<\/em>, wskazywany przez ten commit. Nast\u0119pnie umieszcza pliki i foldery w katalogu roboczym zgodnie ze wskazaniami pliku tree<\/em>. To znaczy, \u017ce katalog roboczy zawiera pliki w takiej wersji, w jakiej by\u0142y podczas tworzenia commita.<\/p>\n\n\n\ngit branch nowa_galaz<\/code>, Git automatycznie tworzy nowy plik .git\/refs\/heads\/nowa_galaz<\/em> zawieraj\u0105cy skr\u00f3t bie\u017c\u0105cego commita. Po prze\u0142\u0105czeniu si\u0119 na t\u0119 ga\u0142\u0105\u017a za pomoc\u0105 komendy git checkout nowa_galaz<\/code>, Git aktualizuje plik HEAD. B\u0119dzie wskazywa\u0142 na now\u0105 ga\u0142\u0105\u017a, na kt\u00f3r\u0105 si\u0119 prze\u0142\u0105czyli\u015bmy.<\/p>\n\n\n\ngit add.<\/code> Dla wszystkich dodanych w ten spos\u00f3b plik\u00f3w, Git tworzy ich kopie w postaci plik\u00f3w blob.<\/em> Nast\u0119pnie zapisuje do pliku index<\/em> list\u0119 dodanych plik\u00f3w i skr\u00f3ty odpowiadaj\u0105cych im plik\u00f3w blob.<\/em> Tylko zmiany, kt\u00f3re znajd\u0105 si\u0119 w pliku index <\/em>zostan\u0105 uwzgl\u0119dnione w commicie.<\/p>\n\n\n\ngit commit<\/code>.<\/p>\n\n\n\ngit merge nowa_galaz<\/code>. Cz\u0119sto okazuje si\u0119, \u017ce w mi\u0119dzyczasie powsta\u0142y na nim ju\u017c jakie\u015b commity, przez co nie jest mo\u017cliwe u\u017cycie mechanizmu fast-forward<\/em>. Oznacza to, \u017ce Git musi utworzy\u0107 nowy merge-commit<\/em>. Powstaj\u0105 odpowiednie pliki tree<\/em>, natomiast wszystkie pliki blob<\/em> ju\u017c istniej\u0105.<\/li><\/ol>\n\n\n\nJaka jest r\u00f3\u017cnica mi\u0119dzy merge<\/em> a rebase?<\/em><\/h2>\n\n\n\n
Komenda rebase<\/h3>\n\n\n\n
git rebase galaz_docelowa<\/code><\/p>\n\n\n\ngit rebase docelowa<\/code><\/p>\n\n\n\n![\"\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2021\/01\/04_rebase_before-git.png\")
<\/a><\/figure><\/div>\n\n\n\n![\"\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2021\/03\/05_rebase-after-git-1024x319.png\")
<\/a><\/figure><\/div>\n\n\n\ngit log docelowa..zrodlowa<\/code><\/p>\n\n\n\nKomenda merge<\/h3>\n\n\n\n
![\"\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2021\/01\/06_merge-before-git-300x63.png\")
<\/a><\/figure><\/div>\n\n\n\n![\"\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2021\/01\/07_merge-after-git-300x45.png\")
<\/a><\/figure><\/div>\n\n\n\n![\"\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2021\/01\/08_merge-commit-before-git-300x94.png\")
<\/a><\/figure><\/div>\n\n\n\n![\"\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2021\/01\/09_merge-commit-after-git-300x82.png\")
<\/a><\/figure><\/div>\n\n\n\nJaka jest r\u00f3\u017cnica mi\u0119dzy fetch <\/i>a pull?<\/em><\/h2>\n\n\n\n
Git fetch<\/h3>\n\n\n\n
git fetch<\/code>. Pobiera ona commity z repozytorium zdalnego i umieszcza je w odpowiednich ga\u0142\u0119ziach zdalnych. Sytuacj\u0119 po wykonaniu git fetch<\/code> przedstawia poni\u017cszy rysunek:<\/p>\n\n\n\n
![\"\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2021\/01\/10_fetch-git.png\")
<\/a><\/figure><\/div>\n\n\n\n![\"\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2021\/01\/11_fetch-after-git-300x137.png\")
<\/a><\/figure><\/div>\n\n\n\n