Git: Różnice pomiędzy wersjami

Usunięta treść Dodana treść
m robot dodaje: ca:Tutorial de git
Derbeth (dyskusja | edycje)
po polsku
Linia 4:
GIT to system plików zaprojektowany jako [[w:system kontroli wersji|system kontroli wersji]]. Stworzył go Linus Torvalds jako narzędzie wspomagające rozwój jądra systemu operacyjnego Linux. GIT stanowi wolne oprogramowanie i został opublikowany pod ochroną licencji GNU GPL.
 
Git jest dobry do obsługi dużych projektów jak Linux, które mają po kilkanaście tysięcy plików, setki łat dziennie. Nazywany jest "stupid content tracker", ponieważ ma bardzo proste algorytmy scalania, prostsze niż w innych systemach kontroli wersji. Ale dzięki temu jest kilkukrotnie szybszy. Jeśli chcemy się dowiedzieć, czym się różnią dane wersje jądra, odpowie w mig. Jeżeli jednak będziemy chcieli znać historię zmian danego pliku, potrwa to trochę dłużej. Wynika to z tego, że git nie pracuje na poziomie plików, ale zestawów plików.
 
Wspomaga także zdecentralizowany rozwój - umożliwia każdemu utworzenie własnego repozytorium z czyjegoś repozytorium oraz śledzenie zmian między nimi.
 
= [[Git/SCM|Porównanie gitgita i svnSVN-a według komend]] =
 
= [[Git/Przypadki|Przypadki użycia]] =
Linia 14:
= [[Git/Konfiguracja|Konfiguracja]] =
 
= Git - Koncepcjekoncepcje =
* Zdecentralizowane
** Każde repozytorium jest gałęzią
Linia 20:
** Drzewo reprezentuje katalog
** Zatwierdzenie reprezentuje drzewo, poprzednie zatwierdzenie(a) i wiadomość
** tag jest aliasem dla commitcommita
* Zatwierdzenie jest zaprojektowane z uwzględnieniem sum kontrolnych
* Zatwierdzenie może mieć kilkunastu przodków
Linia 26:
 
= Ograniczenia =
Git nie śledzi węzłów urządzeń (ang. device nodes) oraz zmian [http[w://en.wikipedia.org/wiki/User_identifier_:User identifier (Unix) uid|uidów]] i [http[w://en.wikipedia.org/wiki/Group_identifier_:Group identifier (Unix) gid|gidów]].
 
Aby wyświetlić w katalogu roboczym pliki (np. węzły urządzeń), które nie będą śledzone, należy wykonać komendę:
find / ! -type f ! -type l ! -type d -ls
 
= Porównanie svnSVN-a i gitgita =
 
{| class="wikitable" |
Linia 71:
* git clone
** klonuje zdalne repozytorium
** Wyjątek: zdalnezdalny master = lokalnelokalny origin
** ~ svn checkout
* git pull
Linia 82:
= Podręcznik =
 
Git ma wbudowany podręcznik. Listę poleceń otrzymamy po wpisanie samego git. Jeśli chcemy dowiedzieć się o jakimś poleceniu, np commit, to wpisujemy
 
git commit --help # wyświetli stronę manuala
Linia 96:
Aby uzyskać pomoc na temat jakiegoś polecenia wpisujemy "git help polecenie" lub "git --help".
 
= Reprezentacja historii w GitGicie =
 
Istnieją cztery typy obiektów w obiektowej bazie danych Gita. Wszystkie z nich są globalnie unikalnymi 40-znakowymi szesnastkowymi nazwami powstałymi w wyniku obliczenia sumy haszującej ich typu i zawartości.
Linia 102:
* Obiekty drzewa zapisują zawartość katalogu; zawierają nazwy plików, uprawnienia i powiązane nazwy obiektów drzew i blob.
* Obiekty tagi to wskaźniki do innych obiektów, które można współdzielić; generalnie są używane do przechowywania podpisów cyfrowych.
* I wreszcie doszliśmy do obiektów zatwierdzeń (commitcommitów). Każde zatwierdzenie wskazuje na (zawiera nazwę) powiązanego obiektu drzewo, który zapisuje stan kodu źródłowego w czasie zatwierdzenia oraz pewne dane opisowe (czas, autor, zatwierdzający, komentarz zatwierdzenia) o zatwierdzeniu.
 
I najważniejsze, zawiera listę "zatwierdzeń przodkowych", starszych zatwierdzeń z których to jedno się wywodzi. Te wskaźniki są tym co tworzy graf historii.
Linia 112:
W wreszcie są zatwierdzenia które mają wielu przodków. Dwa jest najbardziej spotykane, ale git umożliwia dużo więcej. (Istnieje limit szesnastu w kodzie źródłowym, a najwięcej ktokolwiek użył w rzeczywistości to 12 i było to uważane za przesadę).
 
Na końcu są referencje, przechowywane w katalogu <tt>.git/refs</tt>. To są nazwy odczytywalneczytelne dla człowieka powiązane z zatwierdzeniami oraz "zestaw root", od którego wszystkie inne zatwierdzenia powinny być osiągalne.
 
Te referencje są generalnie podzielone na dwa typy, mimo że nie ma fundamentalnej różnicy:
Linia 118:
* Głowice (head) to referencje przeznaczone do aktualizacji. Głowica to aktualnie synonim gałęzi, jednak pierwszy bardziej jest podpowiedzią, podczas gdy drugi kieruje twoją uwagę na całkowitą ścieżkę, która tu doprowadziła.
 
Czy tak czy tak, są po prostu 41-bajtowym plikiem, który zawiera po prostu 40-bajtowy szesnastkowy identyfikator obiektu, plus znak nowej linii. Tagi są przechowywane w <tt>.git/refs/tags</tt>, a głowice są przechowywane w <tt>.git/refs/geads</tt>. Tworzenie nowej gałęzi to po prostu wybranie nazwy pliku i zapisanie do niego identyfikatora istniejącego zatwierdzenia.
 
Polecenia git wymuszają niezmienialność tagów, ale to jest dodatek bezpieczeństwa, nie cecha fundamentalna. Możesz zmienić tag w głowicę i oszaleć.
Linia 124:
Jedyne ograniczenie gałęzi to bałagan. Wiele poleceń gita umie operować na "wszystkich głowicach" i jeśli masz zbyt dużo, to może stać się nieznośne. Jeśli nie używasz gałęzi, usuń ją, lub przenieś gdzieś (na przykład do katalogu tags) gdzie nie będą zaśmiecać listę aktywnych aktualnie głowic.
 
(Zauważ, że CVS nie ma domyślnie włączonego operowania na wszystkich głowicach, więc ludzie zwykle używają dłuższych nazw gałęzi i pozostawiają je po tym, jak zostały złączone z aktywną gałęzią (trunktrunkiem). Stare repozytoria CVS przekształcone do gita zwykle wymagają wyczyszczenia starego rozgałęziania.
 
Inną rzeczą wartą wspomnienia jest to, że nazwy głowic i tagów mogą zawierać ukośniki: np. możesz tworzyć podkatalogi w katalogach .git/refs/heads i .git/refs/tags. Pełny opis legalnych nazw na stronie podręcznika man git-check-ref-format.
Linia 136:
Po pierwsze, każde zatwierdzenie posiada globalną unikalną nazwę, swój 40-cyfrowy szesnastkowy identyfikator obiektu. Jest trochę za długi i dziwaczny, ale zawsze działa. To jest przydatne do omawiania szczególnego zatwierdzenia na liście dyskusyjnej. Możesz podać unikalny przedrostek, większość ludzi uważa 8 cyfr za wystarczające.
 
(Subversion jest nawet prostsze, ponieważ przypisuje kolejny numer do każdego zatwierdzenia. Jakkolwiek nieNie jest to jednak możliwe w rozproszonym systemie kontroli wersji, jakim jest git.)
 
Po drugie, możesz odnieść się do nazwy głowicy lub taga. Git szuka głowicy w następujących miejscach:
Linia 167:
Istnieje zawsze aktualna głowica, zwana HEAD. (Aktualnie jest to link symboliczny, .git/HEAD, do pliku takiego jak refs/heads/master.) Git wymaga aby to zawsze wskazywało do katalogu refs/heads.
 
== Pomniejsze szczegóły techniczne: ==
 
1)# HEAD zwykł być Uniksowym symlinkiem, i nadal może być tak postrzegany, ale aby obsługiwać systemy firmy Microsoft, to jest teraz tym co jest nazywane "symboliczna referencja" lub symref i jest prostym plikiem zawierającym "ref: refs/heads/master". Git traktuje to tak jak symlink. Istnieje pomocnik git-update-ref, który je zapisuje.
2)# Podczas gdy HEAD musi wskazywać na refs/heads, legalnym jest wskazywanie na nieistniejący plik. To właśnie się dzieje przed pierwszym zatwierdzeniem w całkowicie nowym repozytorium.
 
2) Podczas gdy HEAD musi wskazywać na refs/heads, legalnym jest wskazywanie na nieistniejący plik. To właśnie się dzieje przed pierwszym zatwierdzeniem w całkowicie nowym repozytorium.
 
Kiedy wykonujesz "git commit", nowy obiekt zatwierdzenia jest tworzony ze starym HEAD jako przodkiem, a nowe zatwierdzenie jest zapisywane do aktualnej głowicy (wskazywanej przez HEAD).
Linia 239 ⟶ 238:
Jeśli chcesz używać systemu śledzenia błędów w połączeniu z gitem, zobacz na tą stronę:
 
[[w:en:Comparison of issue tracking systems|en:Comparison of issue tracking systems]]
http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems
 
Interesuje nas kolumna "Source code revision control system integration".