gittutorial (7).pdf

gittutorial (7) Instrukcja obsługi Page

NAZWA

gittutorial wprowadzenie tutorial git (dla wersji 1.5.1 lub nowszej)

SKŁADNIA

git *

OPIS

Ten poradnik wyjaśnia, jak zaimportować nowy projekt na git, wprowadzić w nim zmiany, a zmiany podzielić się z innymi programistami.

Jeśli zamiast przede wszystkim zainteresowane wykorzystaniem git do pobrania projektu, na przykład, aby przetestować najnowszą wersję, może wolisz,

aby rozpocząć z dwóch pierwszych rozdziałów użytkownika Git obsługi .

Po pierwsze, zauważyć, że można pobrać dokumentację dla polecenia, takie jak dziennik git wykres z:

$ Man gitlog

lub:

$ Git log pomoc

Z tym ostatnim, można użyć instrukcji widza do wyboru, patrz gitpomocy (1) więcej informacji.

Jest to dobry pomysł, aby przedstawić się git swoje nazwisko i adres email publicznej przed wykonaniem każdej operacji. Najprostszym sposobem na

to jest:

$ Git config global user.name "Your Name Here Comes" $ git config global user.email you@yourdomain.example.com

Importowanie nowego projektu

Zakładam, że masz project.tar.gz archiwum z pierwszych prac. Można go umieścić w kontroli wersji git w następujący sposób.

$ Tar xzf project.tar.gz $ cd project $ git init

Git odpowie

Zainicjowany puste repozytorium Git w. Git /

Masz teraz inicjowane katalogupracujesz mogą zauważyć nowo utworzonego katalogu o nazwie ". Git".

Dalej, powiedz git, aby zrobić zdjęcie zawartości wszystkich plików w bieżącym katalogu (uwaga . ), z git add :

$ Git add.

Ten obraz jest teraz zapisywany w pamięci tymczasowej obszaru przemieszczania które git nazywa "index". Możesz trwale zapisać zawartość indeksu w

repozytorium git commit :

$ Git commit

Ten poprosi o popełnienia wiadomość. Masz teraz przechowywane w pierwszej wersji projektu w git.

Dokonywanie zmian

Modyfikacja niektórych plików, a następnie dodać swoje uaktualnione treści do indeksu:

$ Git dodać plik1 plik2 plik3

Jesteś teraz gotowy do popełnienia. Można zobaczyć, co ma być popełnione przy użyciu git diff z opcją pamięci podręcznej:

$ Git diff cached

(Bez buforowane, git diff pokaże wszelkie zmiany, które zrobiłeś, ale jeszcze nie dodane do indeksu.) Można również uzyskać krótkie podsumowanie

sytuacji w stan git :

$ Git statusu # Na mistrza oddziału # Zmiany zostać popełnione: # (uŜyj "git reset HEAD <plik> ..." do unstage) # # zmienione: plik1 # zmienione: file2 # zmienione: plik3 #

Jeśli konieczne jest wprowadzenie dalszych zmian, zrób to teraz, a następnie dodać nowo zmodyfikowaną treść do indeksu. Wreszcie swoje zmiany z:

$ Git commit

Będzie to kolejny monit o komunikat opisujący zmiany, a następnie nagrać nową wersję projektu.

Alternatywnie, zamiast uruchamiania git dodać wcześniej, można użyć

$ Git commit

który automatycznie zauważenia jakichkolwiek modyfikacji (ale nie nowe) pliki, dodać je do indeksu i zobowiązać się, w jednym kroku.

Uwaga na temat popełnienia wiadomości: Choć nie jest wymagane, to jest dobry pomysł, aby rozpocząć popełnienia wiadomość jeden krótki (mniej niż

50 znaków) linii podsumowanie zmian, a następnie pusty wiersz, a następnie opis bardziej dokładne. Narzędzia, które z kolei zobowiązuje się do email,

na przykład, w pierwszej linii na Temat: linia i reszty zaangażować w organizmie.

Git utworów zawartości plików

Wiele systemów kontroli wersji zapewniają dodać polecenie, które mówi systemowi aby rozpocząć śledzenie zmian w nowym pliku. Git jest dodać

polecenie ma czegoś prostszego i bardziej wydajny: dodać git jest wykorzystywany zarówno do plików nowych i nowo zmodyfikowane, i w obu

przypadkach w skrócie z podanych i etapy tych treści w indeksie, gotowy do włączenia w następnym popełnienia.

Przeglądanie historii projektu

W dowolnym momencie można wyświetlić historię zmian za pomocą

$ Git log

Jeśli chcesz także, aby zobaczyć pełną łaty na każdym kroku, należy użyć

$ Git logp

Często przegląd zmian jest przydatna, aby poczuć każdego kroku

$ Git log stat podsumowanie

Oddziałów Zarządzanie

Jednego repozytorium git może utrzymywać wiele gałęzi rozwoju. Aby utworzyć nowy oddział o nazwie "eksperymentalny", użyj

$ Eksperymentalnej gałęzi git

Jeśli teraz uruchomić

$ Git branch

dostaniesz listę wszystkich istniejących branżach:

eksperymentalnych * mistrza

"Eksperymentalne" oddział jest jednym właśnie utworzony, a "master" oddział jest domyślną gałąź, która została utworzona automatycznie. Gwiazdka

oznacza oddział, który jest aktualnie na, rodzaj

$ Git checkout eksperymentalnych

, aby przejść do gałęzi eksperymentalnej. Teraz otwórz plik, zatwierdzamy zmiany i powrócić do oddziału master:

(Edycja pliku) $ git commita $ git checkout mistrza

Sprawdź, czy zmiany wprowadzone nie jest już widoczne, ponieważ dokonano w eksperymentalnej gałęzi i jesteś z powrotem na oddział główny.

Można dokonać różnych zmian na gałęzi master:

(Edytować plik) $ git commita

w tym momencie dwa oddziały rozeszły, z różnych zmian w każdej z nich. Aby połączyć zmiany dokonane w eksperymentalnych na mistrza, uruchom

$ Git merge eksperymentalnych

Jeśli zmiany nie są sprzeczne, gotowe. W razie konfliktu, markery pozostanie w problematycznych plików pokazuje konfliktu;

$ Git diff

będzie to udowodnić. Po edytowane pliki do rozwiązania konfliktów,

$ Git commit

zobowiąże wyniku połączenia. Wreszcie,

$ Gitk

pokaże ładne graficzne przedstawienie historii wynikające.

W tym momencie można usunąć eksperymentalnej gałęzi z

$ Git branchd eksperymentalnych

Polecenie to zapewnia, że zmiany w gałęzi eksperymentalnej są już w bieżącym oddziale.

Jeśli pojawią się na gałęzi crazypomysł, a potem żałować, zawsze możesz usunąć oddział, z

$ Git branchD crazyidea

Oddziały są tanie i łatwe, więc jest to dobry sposób, aby spróbować coś.

Korzystanie git współpracy

Załóżmy, że Alicja rozpoczęła nowy projekt z repozytorium git w / home / alicja / projektu, i Bob, który katalogu na tej samej maszynie, chce się

przyczynić.

Bob zaczyna się na:

bob $ git clone / home / alicja / projektu myrepo

Tworzy nowy katalog "myrepo" zawierające klon repozytorium Alice. Klon jest na równi z pierwotnego projektu, posiadającą własną kopię oryginalnego

projektu historii.

Bob następnie wprowadzono kilka zmian i zobowiązuje się je:

(Edycja plików) bob $ git commita (w razie potrzeby powtórzyć)

Kiedy będzie gotowy, mówi Alice pociągnąć zmiany z repozytorium w / home / bogdan / myrepo. Czyni to z:

alice $ cd / home / alicja / projektu alice $ git pull / home / bogdan / myrepo mistrza

Ta opcja scala zmiany Boba "master" oddział w obecnej branży Alice. Jeżeli Alicja ma się jej własne zmiany w międzyczasie, to ona może trzeba ręcznie

rozwiązać wszelkie konflikty.

"Pull" polecenia w ten sposób wykonuje dwie operacje: sam pobiera zmiany ze zdalnej gałęzi, a następnie łączy je w obecnej branży.

Należy pamiętać, że w ogóle, Alice chciał jej lokalnych zmian popełnione przed rozpoczęciem tego typu "pull". Jeśli Bob konfliktów pracy z tym, co

Alicja nie od ich historii rozwidlone, Alice użyje jej pracy drzew i indeks do rozwiązywania konfliktów, a istniejące lokalne zmiany będą zakłócać proces

rozwiązania konfliktu (git będzie nadal wykonywać pobrać ale odmówić merge Alice będzie musiał się jej pozbyć lokalnych zmian w jakiś sposób i

wyciągnąć ponownie, kiedy to nastąpi).

Alice może zajrzeć na to, co Bob nie bez połączenia pierwsze, korzystając z "fetch" polecenia, co pozwala Alice do wglądu co Bob nie, za pomocą

specjalnego symbolu "FETCH_HEAD", w celu ustalenia, czy ma coś, co warto ciągnięcie, tak:

alice $ git fetch / home / bogdan / myrepo mistrza alice $ git logp HEAD .. FETCH_HEAD

Ta operacja jest bezpieczna, nawet jeśli Alice niezatwierdzone lokalnych zmian. Zapis zakres "HEAD .. FETCH_HEAD" oznacza "wszystko pokazać, że

jest osiągalny z FETCH_HEAD ale wykluczyć tego, co jest dostępne z HEAD". Alice wie już wszystko, co prowadzi do jej aktualnego stanu (HEAD), a

opinie, co Bob ma w swoim państwie (FETCH_HEAD), że nie widziała z tego polecenia.

Jeżeli Alicja chce wyobrazić, co Bob nie od ich historii rozwidlone ona może wydać następujące polecenie:

$ Gitk HEAD .. FETCH_HEAD

To używają tych samych punktów, zapis zakres widzieliśmy wcześniej z dziennika git .

Alice może chcesz zobaczyć, co oboje nie, ponieważ widłowych. Ona może użyć trzech punktów, postaci zamiast postaci dwóch punktów:

$ Gitk HEAD ... FETCH_HEAD

Oznacza to, że "wszystko pokazać, że jest osiągalny z jedną, ale wykluczyć tego, co jest dostępne z obu z nich".

Proszę pamiętać, że zapis zakres może być stosowany zarówno gitk i "log git".

Po kontroli, co Bob nie, jeśli nie ma nic pilnego, Alice może podjąć decyzję, aby kontynuować pracę bez wyciągania od Boba. Jeśli historia Boba ma

coś Alice natychmiast potrzebne, Alice może zdecydować się na zapas pracę w toku pierwsze, nie "pull", a następnie w końcu unstash pracę w toku na

górze historii wynikające.

Podczas pracy w małych grupach, zwarta, nie jest niczym niezwykłym na interakcję z samym repozytorium, w kółko. Definiując zdalnego skrót

repozytorium, można łatwiej:

alice $ git zdalnego dodać bob / home / bogdan / myrepo

Z tym, Alice może wykonać pierwszą część "pull" operacji tylko przy użyciu git fetch polecenia bez połączenia z własnego oddziału, za pomocą:

alice $ git fetch bob

W przeciwieństwie do postaci longhand, kiedy Alice pobiera od Bob za pomocą pilota zdalnego repozytorium skrót utworzony z git remote , co było

pobierane są przechowywane w zdalne śledzenie oddziału, w tym przypadku bob / master . Więc po tym:

alice $ git logp master..bob / master

wyświetlana jest lista wszystkich zmian, które Bob wykonane bo rozgałęzionych z oddziału kapitana Alice.

Po przeanalizowaniu tych zmian, Alice może scalić zmiany w jej oddziału master:

alice $ git merge bob / master

To połączenie może być również wykonane przez pociągnięcie jej własny oddział zdalnego śledzenia , na przykład:

alice $ git pull. piloty / bob / master

Należy pamiętać, że git pull zawsze przechodzi w obecnej branży, niezależnie od tego, co jest podane w wierszu poleceń.

Później, Bob może zaktualizować swoje repo ze zmianami ostatni Alicji przy

bob $ git pull

Uwaga, że nie trzeba podawać ścieżkę do repozytorium Alice, kiedy Bob sklonowanych repozytorium Alice, git przechowywane położenie jej

repozytorium w konfiguracji repozytorium, a to miejsce służy do wyciągi:

bob $ git config get remote.origin.url / home / alicja / projektu

(Pełna konfiguracja stworzony przez clone git jest widoczne przy użyciu git configl , i gitconfig (1) strony podręcznika wyjaśnia znaczenie

poszczególnych opcji.)

Git również utrzymuje nieskazitelną kopię gałęzi mistrza Alicji pod nazwą "pochodzenia / master":

bob $ git branchr pochodzenia / master

Jeśli Bob później decyduje się na pracę z innego hosta, może on nadal wykonywać klonów i ciągnie za pomocą protokołu ssh:

bob $ git clone alice.org: / home / alicja / projektu myrepo

Alternatywnie, git ma natywnego protokołu, lub można użyć rsync lub http, patrz gitpull (1) o szczegóły.

Git mogą być również wykorzystywane w CVSjak tryb, z centralnym repozytorium różnych użytkowników wcisnąć zmian, patrz gitpush (1) i gitcvs

migracji (7) .

Odkrywanie historii

Historia Git jest przedstawiony jako szereg wzajemnie powiązanych zobowiązuje. Widzieliśmy już, że dziennika git polecenie może listę tych,

zobowiązuje. Zauważ, że pierwsza linia każdego wpisu w dzienniku git daje również nazwę commit:

$ Git log popełnienia c82a22c39cbc32576f64f5c6b3f24b99ea8149c7 Autor: Junio C Hamano Data <junkio@cox.net>: Wto 16 maj 17:18:22 2006 0700 mergepodstawy: Wyjaśnić uwagi na temat obróbki.

Możemy dać tę nazwę do git pokazać , aby zobaczyć szczegóły tego zobowiązać.

$ Git pokazać c82a22c39cbc32576f64f5c6b3f24b99ea8149c7

Ale są też inne sposoby odnoszą się do popełnia. Można użyć dowolnego początkową część nazwy, która jest wystarczająco długi, aby jednoznacznie

identyfikować commit:

$ Git pokazać c82a22c39c # kilka pierwszych znaków z nazwy są zazwyczaj wystarczy # $ git HEAD pokazać # końcówkę obecnego oddziału $ git pokazać eksperymentalnych # końcówki "eksperymentalne" oddział

Każdy commit zwykle ma jeden "rodzic" commit, które punkty do stanu poprzedniego projektu:

$ Git HEAD pokaŜ ^ #, aby zobaczyć rodziców HEAD $ head pokazać git ^ ^ #, aby zobaczyć dziadków HEAD $ git HEAD pokazać ~ 4 # by zobaczyć, prapra dziadka z HEAD

Należy pamiętać, że połączenie zobowiązuje może mieć więcej niż jedno z rodziców:

$ Head pokazać git ^ 1 # show pierwszych rodziców z HEAD (taki sam jak HEAD ^) $ git HEAD pokazać ^ 2 # show drugiego rodzica z HEAD

Można również przekazać zobowiązuje nazwy własne, po uruchomieniu

$ Git tag v2.5 1b2e1d63ff

możesz odwołać się do 1b2e1d63ff pod nazwą "v2.5". Jeśli zamierzasz akcji tej nazwy z innymi ludźmi (np. do identyfikacji wersji), należy utworzyć "tag"

obiekt, a może go podpisać, patrz gittag (1) o szczegóły.

Każde polecenie git, że musi wiedzieć popełnić może przyjąć jedną z tych nazw. Na przykład:

$ Git diff v2.5 HEAD # porównać obecny HEAD v2.5 $ git branch stabilny v2.5 # rozpocząć nowy oddział o nazwie "stajni" na # w wersji 2.5 $ git reset hard HEAD ^ # przywrócenie bieŜącej oddziału i pracy # katalog do jej stanu HEAD ^

Bądź ostrożny, że ostatnie polecenie: oprócz utraty zmian w katalogu, spowoduje również usunięcie wszystkich później popełnia z tej branży. Jeśli oddział

jest tylko oddział zawierające te zobowiązuje się, zostaną one utracone. Nie należy również używać git reset na gałęzi publicznie widoczne, że inni

programiści wyciągnąć z, jak to życie niepotrzebne łączy na innych deweloperów do czyszczenia historii. Jeśli chcesz cofnąć zmiany, które spowodowały,

użyj git przywrócić zamiast.

Grep git polecenia umożliwia wyszukiwanie ciągów znaków w każdej wersji projektu, więc

$ Git grep "hello" v2.5

wyszukiwania wszystkich wystąpień "hello" w v2.5.

Jeśli pominiemy popełnienia nazwę, git grep przeszuka żadnych plików, którymi zarządza w bieżącym katalogu. Tak

$ Git grep "hello"

Jest to szybki sposób na wyszukiwanie tylko pliki, które są śledzone przez git.

Wiele poleceń git również zestawy zobowiązuje, które można określić na wiele sposobów. Oto kilka przykładów z dziennika git :

$ Git log v2.5 .. v2.6 # zobowiązuje między v2.5 i v2.6 $ git log v2.5 .. # Popełnia od v2.5 $ git log od = "2 tygodnie temu" # popełnia z ostatnich 2 tygodni $ git log v2.5 ..

Można również przekazać git dziennika "zakresu" zobowiązuje gdzie pierwsze nie zawsze jest przodkiem drugiego, na przykład, jeśli czubkach gałęzi

"stabilny" i "master" rozeszły się od wspólnego popełnić jakiś czas temu, a następnie

$ Git log stabilny .. mistrza

będzie lista zobowiązuje się w branży mistrza, ale nie w gałęzi stabilnej, podczas gdy

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: