Git
Wewnętrzne

Repo

git repository to struktura danych na dysku, która przechowuje metadane dla zestawu plików i katalogów.

Żyje w folderze .git/ twojego projektu. Za każdym razem, gdy zatwierdzasz dane do git, są one tutaj przechowywane. Odwrotnie, .git/ zawiera każdy pojedynczy zatwierdzenie.

Jego podstawowa struktura wygląda następująco:

.git/
    objects/
    refs/

Obiekty

git jest zasadniczo sklepem o kluczowej wartości. Po dodaniu danych do git , to buduje object i używa skrótu SHA-1 z object „s zawartość jako klucza.

Dlatego każda zawartość w git może być sprawdzana przez jego skrót:

git cat-file -p 4bb6f98

Istnieją 4 typy Object :

• blob
• tree
• commit
• tag

HEAD ref

HEAD to specjalny ref . Zawsze wskazuje na bieżący obiekt.

Możesz zobaczyć, gdzie obecnie wskazuje, sprawdzając plik .git/HEAD .

Zwykle HEAD wskazuje na inny ref :

$cat .git/HEAD
ref: refs/heads/mainline

Ale może również wskazywać bezpośrednio na object :

$ cat .git/HEAD
4bb6f98a223abc9345a0cef9200562333

Jest to tak zwana „odłączona głowa” - ponieważ HEAD nie jest przywiązany (wskazuje na) żaden ref , ale wskazuje bezpośrednio na object .

Refs

ref jest zasadniczo wskaźnikiem. To nazwa, która wskazuje na object . Na przykład,

"master" --> 1a410e...

Są one przechowywane w `.git / refs / heads / w zwykłych plikach tekstowych.

$ cat .git/refs/heads/mainline
4bb6f98a223abc9345a0cef9200562333

Jest to powszechnie nazywane branches . Zauważysz jednak, że w git nie ma czegoś takiego jak branch - tylko ref .

Teraz można poruszać się po git wyłącznie poprzez przeskakiwanie do różnych objects bezpośrednio za pomocą skrótów. Byłoby to jednak wyjątkowo niewygodne. ref daje ci wygodną nazwę do odwoływania się do objects . O wiele łatwiej jest poprosić git aby poszedł do określonego miejsca według nazwy niż według skrótu.

Obiekt zatwierdzenia

commit jest prawdopodobnie typem object najbardziej znanym użytkownikom git , ponieważ są one używane do tworzenia przy użyciu poleceń git commit .

Jednak commit nie zawiera bezpośrednio żadnych zmienionych plików ani danych. Zamiast tego zawiera głównie metadane i wskaźniki do innych objects które zawierają rzeczywistą zawartość commit .

commit zawiera kilka rzeczy:

• hash tree
• hash rodzica commit
• nazwa autora / adres e-mail, nazwa komisarza / adres e-mail
• zatwierdzić wiadomość

Możesz zobaczyć zawartość każdego takiego zatwierdzenia:

$ git cat-file commit 5bac93
tree 04d1daef...
parent b7850ef5...
author Geddy Lee <[email protected]>
commiter Neil Peart <[email protected]>

First commit!

Drzewo

Bardzo ważną uwagą jest to, że obiekty tree przechowują KAŻDY plik w twoim projekcie i przechowują całe pliki, a nie różnice. Oznacza to, że każde commit zawiera migawkę całego projektu *.

* Technicznie przechowywane są tylko zmienione pliki. Jest to jednak bardziej szczegół implementacji pod kątem wydajności. Z punktu widzenia projektu, commit należy uznać za zawierające kompletną kopię projektu .

Rodzic

Linia parent zawiera skrót innego obiektu commit i może być uważana za „wskaźnik nadrzędny”, który wskazuje na „poprzednie zatwierdzenie”. To domyślnie tworzy wykres zatwierdzeń znany jako wykres zatwierdzeń . W szczególności jest to ukierunkowany wykres acykliczny (lub DAG).

Obiekt drzewa

tree zasadniczo reprezentuje folder w tradycyjnym systemie plików: zagnieżdżone kontenery na pliki lub inne foldery.

tree zawiera:

• 0 lub więcej obiektów blob
• 0 lub więcej obiektów tree

Tak jak możesz użyć ls lub dir aby wyświetlić zawartość folderu, możesz także wyświetlić zawartość obiektu tree .

$ git cat-file -p 07b1a631
100644 blob b91bba1b   .gitignore
100644 blob cc0956f1   Makefile
040000 tree 92e1ca7e   src
...

Możesz wyszukać pliki w commit , najpierw znajdując skrót tree w commit , a następnie patrząc na to tree :

$ git cat-file commit 4bb6f93a
tree 07b1a631
parent ...
author ...
commiter ... 
 
$ git cat-file -p 07b1a631
100644 blob b91bba1b   .gitignore
100644 blob cc0956f1   Makefile
040000 tree 92e1ca7e   src
...

Obiekt Blob

Obiekt blob zawiera dowolną zawartość pliku binarnego. Zwykle będzie to surowy tekst, taki jak kod źródłowy lub artykuł na blogu. Ale równie dobrze mogą to być bajty pliku PNG lub cokolwiek innego.

Jeśli masz skrót obiektu blob , możesz sprawdzić jego zawartość.

$ git cat-file -p d429810
package com.example.project

class Foo {
 ...
}
...

Na przykład, można przeglądać tree jak wyżej, a następnie spojrzeć na jednym z blobs w nim.

$ git cat-file -p 07b1a631
100644 blob b91bba1b   .gitignore
100644 blob cc0956f1   Makefile
040000 tree 92e1ca7e   src
100644 blob cae391ff   Readme.txt

$ git cat-file -p cae391ff
Welcome to my project! This is the readmefile
...

Tworzenie nowych zobowiązań

Polecenie git commit robi kilka rzeczy:

1. Twórz obiekty blobs i trees reprezentujące katalog projektu - przechowywane w .git/objects
2. Tworzy nowy obiekt commit z informacjami o autorze, komunikatem zatwierdzenia i tree głównym z kroku 1 - również przechowywanym w .git/objects
3. Aktualizuje odniesienie HEAD w .git/HEAD do skrótu nowo utworzonego commit

Powoduje to dodanie nowej migawki projektu do git połączonego z poprzednim stanem.

Ruchoma GŁOWA

Kiedy uruchamiasz git checkout przy zatwierdzeniu (określonym przez hash lub ref), mówisz git aby twój katalog roboczy wyglądał tak, jak wtedy, gdy zrobiono migawkę.

1. Zaktualizuj pliki w katalogu roboczym, aby pasowały do tree wewnątrz commit
2. Zaktualizuj HEAD aby wskazywał na określony skrót lub ref

Przenoszenie referencji

Uruchamianie git reset --hard ruch przenosi git reset --hard do określonego skrótu / odwołania.

Przenoszenie MyBranch do b8dc53 :

$ git checkout MyBranch      # moves HEAD to MyBranch
$ git reset --hard b8dc53    # makes MyBranch point to b8dc53     

Tworzenie nowych referencji

Uruchomienie git checkout -b <refname> spowoduje utworzenie nowego git checkout -b <refname> które wskazuje na bieżący commit .

$ cat .git/head
1f324a

$ git checkout -b TestBranch

$ cat .git/refs/heads/TestBranch
1f324a