Pro Git – rozdział 2, część 1

Matthew @ 2010-04-24 — Kategorie: git, Pro Git, Programowanie, Techblog

I przyszedł czas na drugi rozdział Pro Git. Na razie tylko część, ze względu że to dość długi rozdział i długo mi zeszło tłumaczenie (i jeszcze nie skończyłem, zostały mi 3 podrozdziały), poza tym jogger i tak by nie przyjął całości i bym musiał dzielić. Ale trudniejsza część roboty za mną, więc druga część powinna się pojawić w ciągu kilku dni. Przypominam że, książkę napisał Scott Chacon a jej treść jest wydana na licencji Creative Commons Attribution-Non Commercial-Share Alike 3.0. Miłego czytania (i jak zwykle mam nadzieję, że uda wam się wyłapać błędy które ja przeoczyłem).

2. Podstawy gita
2.1 Tworzenie repozytorium gita
2.2 Zapisywanie zmian do repozytorium
2.3 Przeglądanie historii commitów
2.4 Cofanie zmian
2.5 Praca ze zdalnymi repozytoriami
2.6 Tagowanie
2.7 Tips and Tricks
2.8 Podsumowanie

2. Podstawy gita

Jeżeli miałbyś przeczytać tylko jeden rozdział, żeby zacząć pracować z gitem, to jest właśnie ten. Omawia on każdą podstawową komendę którą będziesz wykorzystywał przez większość czasu którego spędzisz z gitem. Pod koniec rozdziału, powinieneś być w stanie stworzyć i skonfigurować repozytorium, zacząć i przestać śledzić pliki, przechowywać i commitować zmiany. Pokażemy również jak ignorować konkretne pliki lub wzorce plików, jak szybko i łatwo cofnąć pomyłki, jak przeglądać historię projektu i zobaczyć zmiany między commitami, oraz jak wypchnąć (push) i pobrać (pull) dane ze zdalnego repozytorium.

2.1 Tworzenie repozytorium gita

Repozytorium z projektem można zdobyć na dwa sposoby. Pierwszy to wzięcie istniejącego projektu lub katalogu i zaimportowanie go do gita. Drugim jest sklonowanie istniejącego repozytorium gita z innego serwera.

Inicjalizacja repozytorium w istniejącym katalogu

Jeżeli zaczynasz śledzić istniejący projekt w gitcie, musisz wejść do folderu projektu i wydać komendę

[cc lang=”bash”]$ git init[/cc]

Utworzy to nowy podkatalog o nazwie [cc inline=”true” no_cc=”true”].git[/cc], który zawiera wszystkie potrzebne Ci pliki repozytorium – szkielet repozytorium gita. W tym momencie jeszcze nic w Twoim projekcie nie jest śledzone (zobacz rozdział 9 żeby uzyskać więcej informacji co dokładnie zawierają pliki w katalogu [cc inline=”true” no_cc=”true”].git[/cc], który właśnie utworzyłeś).

Jeżeli chcesz zacząć kontrolę wersji istniejących plików, powinieneś zacząć śledzić te pliki i zrobić pierwszy commit. Możesz osiągnąć to dzięki kilku poleceniom [cc inline=”true” no_cc=”true”]git add[/cc] które określają pliki jakie chcesz śledzić, po których nastąpi commit:

[cc lang=”bash”]$ git add *.c
$ git add README
$ git commit -m ‚początkowa wersja projektu'[/cc]

Za minutę wrócimy do tego, co te polecenia robią. W tej chwili masz repozytorium gita ze śledzonymi plikami i pierwszym commitem.

Klonowanie istniejącego repozytorium

Jeżeli chcesz mieć kopię istniejącego repozytorium gita – na przykład projektu, przy którym chciałbyś współpracować z innymi – poleceniem którego potrzebujesz jest [cc inline=”true” no_cc=”true”]git clone[/cc]. Jeżeli jesteś zaznajomiony z innym VCS jak np. Subversion, zauważysz, że to polecenie jest klonowaniem a nie pobieraniem aktualnej kopii roboczej. Jest to ważna różnica – git ściąga kopię prawie wszystkich danych które są na serwerze. Każda wersja każdego pliku w historii projektu jest ściągana kiedy wykonujesz polecenie [cc inline=”true” no_cc=”true”]git clone[/cc]. W związku z tym, jeżeli dysk Twojego serwera ulegnie awarii, możesz użyć dowolnej kopii z dowolnego klienta aby odtworzyć stan serwera z momentu kiedy projekt został sklonowany (możesz stracić niektóre hooki znajdujące się po stronie serwera i inne, ale wszystkie wersjonowane dane nadal powinny być – zobacz rozdział 4).

Kopiujesz repozytorium przy pomocy polecenia [cc inline=”true” no_cc=”true”]git clone <url>[/cc]. Na przykład, jeżeli chcesz sklonować bibliotekę gita w Rubym, zwaną Grit, możesz zrobić tak:

[cc lang=”bash”]$ git clone git://github.com/schacon/grit.git[/cc]

Zostanie utworzony folder o nazwie „grit”, katalog [cc inline=”true” no_cc=”true”].git[/cc] wewnątrz niego, ściągnięte wszystkie dane odnośnie tego repozytorium i ustawiona kopia robocza na ostatnią wersję projektu. Jeżeli wejdziesz do folderu [cc inline=”true” no_cc=”true”]grit[/cc] zobaczysz tam pliki projektu, gotowe aby na nich pracować. Jeżeli chcesz sklonować repozytorium do katalogu nazwanego inaczej niż „grit”, możesz określić to jako kolejną opcję w linii poleceń:

[cc lang=”bash”]$ git clone git://github.com/schacon/grit.git mygrit[/cc]

To polecenie robi dokładnie to samo co poprzednie, ale katalog docelowy zostanie nazwany mygrit.

Git używa kilku różnych protokołów do przesyłania danych. W poprzednim przykładzie użyliśmy protokołu git://, ale możesz zobaczyć również http(s):// lub user@serwer:/sciezka.git, który jest używany przez protokół SSH. Rozdział 4 wprowadzi Cie we wszystkie dostępne opcje serwera, którymi możesz ustawić dostęp do repozytorium gita oraz wszystkich za i przeciw każdej z tych metod.

2.2 Zapisywanie zmian do repozytorium

Masz repozytorium gita i kopię roboczą plików projektu. Musisz teraz zrobić jakieś zmiany i scommitować te zmiany do Twojego repozytorium za każdym razem, gdy Twój projekt osiągnął stan w którym chcesz go zachować.

Zapamiętaj, każdy plik w Twoim katalogu roboczym może być w dwóch stanach: śledzony lub nie. Śledzone pliki są takie, które były w ostatnim zrzucie. Mogą być niezmodyfikowane, zmodyfikowane lub zachowane w przechowalni. Nieśledzone pliki to wszystkie inne – każdy plik w Twoim katalogu roboczym, który nie były w ostatnim zrzucie i nie są w poczekalni. Kiedy po raz pierwszy klonujesz repozytorium, wszystkie pliki będą śledzona i niezmodyfikowane, ponieważ właśnie pobrałeś je i nie zmodyfikowałeś niczego.

Jeżeli edytowałeś swoje pliki, git widzi je jako zmodyfikowane, ponieważ zmieniłeś je od ostatniego commita. Przechowujesz te zmodyfikowane pliki a następnie wszystkie przechowane zmiany i cykl się powtarza. Jest to zilustrowane na obrazku 2-1.

Cykl życia stanu plików

Rysunek 2-1: cykl życia stanu Twoich plików

Sprawdzanie statusu Twoich plików.

Głównym narzędziem, które używasz aby sprawdzić które pliki mają jaki status jest [cc inline=”true” no_cc=”true”]git status[/cc]. Jeżeli uruchamiasz to polecenie zaraz po sklonowaniu, powinieneś coś takiego:

[cc lang=”bash”]$ git status
# On branch master
nothing to commit (working directory clean)[/cc]

Oznacza to, że masz czysty katalog roboczy – innymi słowy, nie ma tam śledzonych i zmodyfikowanych plików. Git również nie widzi żadnych nieśledzonych plików, w przeciwnym wypadku były tutaj wypisane. W końcu, polecenie to powie Ci którą gałąź wykorzystujesz aktualnie. Na razie, jest to zawsze gałąź główna (master), która jest domyślną; nie musisz się na razie tym przejmować. W następnym rozdziale przyjrzymy się bliżej gałęzią i referencją.

Powiedzmy, że chcesz dodać nowy plik do projektu, prosty plik README. Jeżeli ten plik nie istniał wcześniej i uruchomisz [cc inline=”true” no_cc=”true”]git status[/cc], zobaczysz nieśledzone pliki:

[cc lang=”bash”]$ vim README
$ git status
# On branch master
# Untracked files:
# (use „git add …” to include in what will be committed)
#
# README
nothing added to commit but untracked files present (use „git add” to track)[/cc]

Możesz zobaczyć, że Twój nowy plik README nie jest śledzony, ponieważ jest pod nagłówkiem „Unstracked files” w komunikacie statusu. Nieśledzone, najprościej mówiąc znaczy, że git widzi pliki których nie było w poprzednim zrzucie (commitcie). Git nie zacznie dołączać ich do Twojego commitu, dopóki nie nakażesz mu tego robić. Dzieje się tak, aby przypadkowo nie śledzić plików binarnych lub innych których byś nie chciał śledzić. Jeżeli chcesz zacząć dołączyć README, więc zacznijmy śledzić ten plik.

Śledzenie nowego pliku

Aby zacząć śledzić nowy plik, wydasz polecenie [cc inline=”true” no_cc=”true”]git add[/cc]. Żeby zacząć śledzić plik README, musisz uruchomić:

[cc lang=”bash”]$ git add README[/cc]

Jeżeli uruchomisz polecenie statusu jeszcze raz, możesz zobaczyć, że Twój plik README jest śledzony i przechowywany:

[cc lang=”bash”]$ git status
# On branch master
# Changes to be committed:
# (use „git reset HEAD …” to unstage)
#
# new file: README
#[/cc]

Teraz można powiedzieć, że plik jest przechowywany, ponieważ jest pod nagłówkiem „Changes to be committed”. Jeżeli zrobisz commit w tym momencie, wersja pliku w czasie kiedy wydałeś polecenie [cc inline=”true” no_cc=”true”]git add[/cc] będzie tą, która będzie w historycznym zrzucie. Możesz wydać ponownie polecenie kiedy uruchamiałeś [cc inline=”true” no_cc=”true”]git init[/cc] wcześniej, następnie [cc inline=”true” no_cc=”true”]git add <pliki>[/cc] – zaczniesz śledzić pliki w swoim folderze. Polecenie [cc inline=”true” no_cc=”true”]git add[/cc] pobiera ścieżkę dla każdego piku lub folderu; jeżeli jest to folder, polecenie doda wszystkie pliki w tym folderze rekursyjnie.

Przechowywanie zmodyfikowanych plików

Zmieńmy plik, który był już śledzony. Jeżeli zmienisz, wcześniej śledzony plik nazwany [cc inline=”true” no_cc=”true”]benchmarks.rb[/cc] a następnie uruchomisz polecenie [cc inline=”true” no_cc=”true”]status[/cc] ponownie, zobaczysz coś wyglądającego mniej więcej tak:

[cc lang=”bash”]$ git status
# On branch master
# Changes to be committed:
# (use „git reset HEAD …” to unstage)
#
# new file: README
#
# Changed but not updated:
# (use „git add
…” to update what will be committed)
#
# modified: benchmarks.rb
#[/cc]

Plik [cc inline=”true” no_cc=”true”]benchmarks.rb[/cc] pojawi się pod sekcją nazwaną „Changed but not updated” – co oznacza, że plik jest śledzony, został zmodyfikowany w katalogu roboczym, ale jeszcze nie został dodany do przechowalni. Żeby dodać go do przechowalni, uruchamiasz polecenie [cc inline=”true” no_cc=”true”]git add[/cc] (jest to wielozadaniowe polecenie – możesz użyć go do śledzenia nowych plików, przechowywania plików i innych rzeczy jak oznaczanie konflików jako rozwiązane). Uruchommy [cc inline=”true” no_cc=”true”]git add[/cc], żeby przechować plik [cc inline=”true” no_cc=”true”]benchmarks.rb[/cc] a następnie ponownie uruchommy [cc inline=”true” no_cc=”true”]git status[/cc]:

[cc lang=”bash”]$ git add benchmarks.rb
$ git status
# On branch master
# Changes to be committed:
# (use „git reset HEAD …” to unstage)
#
# new file: README
# modified: benchmarks.rb
#[/cc]

Oba pliki są przechowywane i pójdą z następnym commitem. W tym momencie, prawdopodobnie przypominasz sobie o jednej małej zmianie, którą chcesz zrobić w pliku [cc inline=”true” no_cc=”true”]benchmarks.rb[/cc] zanim scommitujesz to. Otwierasz go ponownie, wprowadzasz zmiany i jesteś gotowy, do commita. Jedna, jeszcze raz zobaczmy co pokazuje [cc inline=”true” no_cc=”true”]git status[/cc]:

[cc lang=”bash”]$ vim benchmarks.rb
$ git status
# On branch master
# Changes to be committed:
# (use „git reset HEAD …” to unstage)
#
# new file: README
# modified: benchmarks.rb
#
# Changed but not updated:
# (use „git add
…” to update what will be committed)
#
# modified: benchmarks.rb
#[/cc]

Co do…? Teraz [cc inline=”true” no_cc=”true”]benchmarks.rb[/cc] pojawia się zarówno w przechowalni, jak również poza przechowalnią (jako zmodyfikowany). Jak to jest możliwe? Dzieje się tak, ponieważ git przechowuje pliki w poczekalni dokładnie takimi jakimi były w czasie uruchamiania polecenia [cc inline=”true” no_cc=”true”]git add[/cc]. Jeżeli teraz zrobisz commita, wersja [cc inline=”true” no_cc=”true”]benchmarks.rb[/cc], która zostanie do commita włączona będzie taką, kiedy ostatnio uruchomiłeś polecenie [cc inline=”true” no_cc=”true”]git add[/cc], a nie tą, która znajduje się w katalogu roboczym kiedy uruchamiałeś [cc inline=”true” no_cc=”true”]git commit[/cc]. Jeżeli zmodyfikujesz plik po uruchomieniu [cc inline=”true” no_cc=”true”]git add[/cc], musisz ponownie je uruchomić, aby wrzucić do poczekalni ostatnią wersję pliku:

[cc lang=”bash”]$ git add benchmarks.rb
$ git status
# On branch master
# Changes to be committed:
# (use „git reset HEAD …” to unstage)
#
# new file: README
# modified: benchmarks.rb
#[/cc]

Ignorowanie plików

Często, masz zbiór plików które, nie chcesz aby git je automatycznie dodawał albo nawet pokazywał jako nieśledzone. Przeważnie są to automatycznie generowane pliki, jak logi albo wyprodukowane podczas budowania projektu. W tym przypadku, możesz stworzyć plik zawierający wzorce, wg. których takie pliki będą ignorowane. Plik ten nazywa się [cc inline=”true” no_cc=”true”].gitignore[/cc]. Może wyglądać np. tak:

[cc lang=”bash”]$ cat .gitignore
*.[oa]
*~[/cc]

Pierwsza linia mówi gitowi aby ignorował jakiekolwiek pliki kończące się na [cc inline=”true” no_cc=”true”].o[/cc] albo [cc inline=”true” no_cc=”true”].a[/cc] – pliki obiektów i archiwów które mogą być produktem budowania Twojego kodu. Druga linia mówi gitowi o ignorowaniu wszystkich plików kończących się na ~, które są używane przez wiele edytorów tekstowych, jak Emacs, do oznacza plików tymczasowych. Również, możesz chcieć dopisać log, tmp lub foldery pid, automatycznie generowaną dokumentację i inne. Przygotowanie pliku [cc inline=”true” no_cc=”true”].gitignore[/cc] zanim zaczniesz cokolwiek robić jest dobrym pomysłem jeżeli nie chcesz przypadkowo scommitować plików, których nie chcesz mieć w swoim repozytorium gita.

Zasady dla wzorców, które możesz umieścić w [cc inline=”true” no_cc=”true”].gitignore[/cc]: – puste linie lub zaczynające się do # są ignorowane
– standardowe wzorce działają
– możesz zakończyć wzorzec ukośnikiem ([cc inline=”true” no_cc=”true”]/[/cc]) aby określić, że chodzi Ci o katalog
– możesz zanegować wzorzec poprzez zaczęcie go od wykrzyknika ([cc inline=”true” no_cc=”true”]![/cc]).

Globalne wzorce są uproszconymi wyrażenimi regularnymi których używają powłoki. Gwiazdka ([cc inline=”true” no_cc=”true”]*[/cc]) oznacza zero lub więcej znaków; [cc inline=”true” no_cc=”true”][abc][/cc] oznacza dowolny znak zawarty między nawiasami (w tym wypadku a, b lub c); znak zapytania ([cc inline=”true” no_cc=”true”]?[/cc]) oznacza pojedynczy znak; nawiasy zawierające znaki oddzielone myślnikiem ([cc inline=”true” no_cc=”true”][0-9][/cc]) oznaczają dowolny znak w tym przedziale (w tym wypadku między 0 a 9).

Kolejny przykład [cc inline=”true” no_cc=”true”].gitignore[/cc]:

[cc lang=”bash”]# to jest komentarz – będzie ignorowany
*.a # nie dla plików *.a
!lib.a # ale śledź plik lib.a, nawet jeżeli powyżej kazałeś ignorować pliki *.a
/TODO # ignoruj tylko plik TODO w katalogu głównym, nie TODO w podkatalogach
build/ # ignoruj wszystkie pliki w katalogu build/
doc/*.txt # zignoruj doc/notes.txt, ale nie doc/server/arch.txt[/cc]

Podglądanie Twoich przechowanych i nieprzechowanych zmian

Jeżeli wynik polecenia [cc inline=”true” no_cc=”true”]git status[/cc] jest za bardzo ubogi dla Ciebie – chcesz znać dokładnie to co zmieniłeś, nie tylko które pliki zostały zmienione, możesz użyć polecenia [cc inline=”true” no_cc=”true”]git diff[/cc]. Bardziej szczegółowo zajmiemy się [cc inline=”true” no_cc=”true”]git diff[/cc] później, lecz prawdopodobnie będziesz go używał najczęściej do odpowiedzi na dwa pytania: co zmieniłeś ale jeszcze nie wysłałeś do przechowalni? Oraz co masz w przechowalni co chciałbyś scommitować? [cc inline=”true” no_cc=”true”]git status[/cc] odpowie na te pytania bardzo ogólnikowo, [cc inline=”true” no_cc=”true”]git diff[/cc] pokaże Ci które linie zostały dodane lub usunięte.

Powiedzmy, że ponownie edytowałeś i wrzuciłeś do przechowalni plik README a następnie edytowałeś plik benchmarks.rb bez dodawania do przechowania. Jeżeli uruchomisz polecenie [cc inline=”true” no_cc=”true”]status[/cc], zobaczysz coś takiego:

[cc lang=”bash”]$ git status
# On branch master
# Changes to be committed:
# (use „git reset HEAD …” to unstage)
#
# new file: README
#
# Changed but not updated:
# (use „git add
…” to update what will be committed)
#
# modified: benchmarks.rb
#[/cc]

Żeby zobaczyć jakie zmiany nie zostały jeszcze dodane do przechowalni, uruchom [cc inline=”true” no_cc=”true”]git diff[/cc] bez argumentów:

[cc lang=”bash”]$ git diff
diff –git a/benchmarks.rb b/benchmarks.rb
index 3cb747f..da65585 100644
— a/benchmarks.rb
+++ b/benchmarks.rb
@@ -36,6 +36,10 @@ def main
@commit.parents[0].parents[0].parents[0]
end

+ run_code(x, ‚commits 1’) do
+ git.commits.size
+ end
+
run_code(x, ‚commits 2’) do
log = git.commits(‚master’, 15)
log.size[/cc]

To polecenie porównuje to co masz w swoim katalogu roboczym z tym co masz w przechowalni. Rezultat mówi Ci jakie zmiany nie zostały jeszcze jeszcze wrzucone do przechowalni.

Jeżeli chcesz zobaczyć co z przechowalni zostanie dołączone do następnego commita możesz użyć [cc inline=”true” no_cc=”true”]git diff –cached[/cc] (w gitcie 1.6.1 i późniejszych, możesz również uruchomić [cc inline=”true” no_cc=”true”]git diff –staged[/cc], co może być łatwiejsze do zapamiętania). To polecenie porówna przechowywane zmiany w stosunku do ostatniego commita:

[cc lang=”bash”]$ git diff –cached
diff –git a/README b/README
new file mode 100644
index 0000000..03902a1
— /dev/null
+++ b/README2
@@ -0,0 +1,5 @@
+grit
+ by Tom Preston-Werner, Chris Wanstrath
+ http://github.com/mojombo/grit
+
+Grit is a Ruby library for extracting information from a Git repository[/cc]

Ważne jest, żebym zapamiętać, że [cc inline=”true” no_cc=”true”]git diff[/cc] sam z siebie nie pokazuje wszystkich zmian które zrobiłeś od ostatniego commita – tylko zmiany, który ciągle nie są wrzucone do przechowalni. Może to być mylące, ponieważ jeżeli oddałeś do przechowania wszystkie Twoje zmiany, [cc inline=”true” no_cc=”true”]git diff[/cc] nic nie pokaże.

Kolejny przykład, jeżeli masz w przechowalni benchmarks.rb a następnie edytujesz go, użyjesz [cc inline=”true” no_cc=”true”]git diff[/cc] żeby zobaczyć zmiany w pliku który masz w przechowalni i zmiany jeszcze do niej nie dodane:

[cc lang=”bash”]$ git add benchmarks.rb
$ echo ‚# test line’ >> benchmarks.rb
$ git status
# On branch master
#
# Changes to be committed:
#
# modified: benchmarks.rb
#
# Changed but not updated:
#
# modified: benchmarks.rb
#[/cc]

Terasz możesz użyć [cc inline=”true” no_cc=”true”]git diff[/cc] żeby zobaczyć co jest jeszcze poza przechowalnią

[cc lang=”bash”]$ git diff
diff –git a/benchmarks.rb b/benchmarks.rb
index e445e28..86b2f7c 100644
— a/benchmarks.rb
+++ b/benchmarks.rb
@@ -127,3 +127,4 @@ end
main()

##pp Grit::GitRuby.cache_client.stats
+# test line[/cc]

oraz [cc inline=”true” no_cc=”true”]git diff –cached[/cc] żeby zobaczyć co do tej pory wrzuciłeś do przechowalni:

[cc lang=”bash”]$ git diff –cached
diff –git a/benchmarks.rb b/benchmarks.rb
index 3cb747f..e445e28 100644
— a/benchmarks.rb
+++ b/benchmarks.rb
@@ -36,6 +36,10 @@ def main
@commit.parents[0].parents[0].parents[0]
end

+ run_code(x, ‚commits 1’) do
+ git.commits.size
+ end
+
run_code(x, ‚commits 2’) do
log = git.commits(‚master’, 15)
log.size[/cc]

Commitowanie Twoich zmian

Teraz, kiedy w przechowalni znajduje się to co chcesz, możesz scommitować swoje zmiany. Pamiętaj, że wszystko co nie zostało do niej dodane – dowolny plik który stworzyłeś lub zmodyfikowałeś ale nie uruchomiłeś [cc inline=”true” no_cc=”true”]git add[/cc] na nim od czasu kiedy go edytowałeś – nie będzie znajdował się w tym commitcie. Zostaną jako zmodyfikowane na Twoim dysku. W tym wypadku, ostatni raz uruchom [cc inline=”true” no_cc=”true”]git status[/cc], zobacz czy wszystko zostało dodane do przechowalni i jesteś gotowy żeby scommitować swoje zmiany. Najprostszą drogą aby zrobić commit jest wydanie polecenia [cc inline=”true” no_cc=”true”]git commit[/cc]:

[cc lang=”bash”]$ git commit[/cc]

Zostanie uruchomiony Twój edytor (jest to ustawione poprzez zmienną środowiskową $EDITOR Twojej powłoki – zwykle vim lub emacs, Również możesz skonfigurować to jakkolwiek chcesz używając polecenia [cc inline=”true” no_cc=”true”]git config –global core.editor[/cc], które widziałeś w pierwszym rozdziale).

Edytor wyświetli następujący tekst (ten przykład pochodzi z Vima):

[cc lang=”bash”]
# Please enter the commit message for your changes. Lines starting
# with ‚#’ will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
# (use „git reset HEAD …” to unstage)
#
# new file: README
# modified: benchmarks.rb
~
~
~
„.git/COMMIT_EDITMSG” 10L, 283C[/cc]

Możesz zobaczyć, że domyślna wiadomość commita zawiera zakomentowane ostatnie wyjście polecenia [cc inline=”true” no_cc=”true”]git status[/cc] i jedną pustą linię na samej górze. Możesz usunąć te komentarze i wpisać własną wiadomość lub zostawić je, żeby pomogły Ci zapamiętać co scommitowałeś (żeby jeszcze dokładniej EXPLICIT przypomnienie co zmodyfikowałeś, możesz dodać opcję [cc inline=”true” no_cc=”true”]-v[/cc] do [cc inline=”true” no_cc=”true”]git commit[/cc]. Robiąc to również dołączasz różnice między zmianami do edytora, więc możesz dokładnie zobaczyć co zrobiłeś). Kiedy wyjdziesz z edytora git stworzy commita z tą wiadomością (ale bez komentarzy i różnic).

Alternatywnie, możesz dodać swoją wiadomość w linii, razem z poleceniem [cc inline=”true” no_cc=”true”]commit[/cc] poprzez dodanie flagi [cc inline=”true” no_cc=”true”]-m[/cc]:

[cc lang=”bash”]$ git commit -m „Story 182: Fix benchmarks for speed”
[master]: created 463dc4f: „Fix benchmarks for speed”
2 files changed, 3 insertions(+), 0 deletions(-)
create mode 100644 README[/cc]

Utworzyłeś teraz swój pierwszy commit. Możesz zobaczyć, że commit wyświetlił informacje o sobie: do której gałęzi został scommitowany (master), jaką sumę kontrolną SHA-1 ma ([cc inline=”true” no_cc=”true”]463dc4f[/cc]), jak dużo plików zostało zmienionych oraz statystyki na temat tego ile linii zostało dodanych i usuniętych w tym commicie.

Pamiętaj, że commit rejestruje zrzut który wrzuciłeś do przechowalni. Cokolwiek tam nie umieściłeś ciągle jest oznaczone jako zmodyfikowane. Możesz zrobić kolejny commit aby dodać to do historii. Za każdym razem kiedy Ty tworzysz commit, zapisujesz zrzut Twojego projektu możesz przywrócić lub porównać później.

Omijanie przechowalni

Również może się zdarzyć, że materiał do commita jest dokładnie taki jaki chcesz, żeby był w commicie. Przechowalnia w takich wypadkach jest nadmiarowym rozwiązaniem. Jeżeli chcesz przeskoczyć przechowalnię, git oferuje prosty skrót. Dodanie opcji [cc inline=”true” no_cc=”true”]-a[/cc] do polecenia [cc inline=”true” no_cc=”true”]git commit[/cc] powoduje automatyczne przechowywanie każdego pliku który jest już śledzony zanim zostanie zrobiony commit, pozwalając Ci ominąć [cc inline=”true” no_cc=”true”]git add[/cc]:

[cc lang=”bash”]$ git status
# On branch master
#
# Changed but not updated:
#
# modified: benchmarks.rb
#
$ git commit -a -m ‚added new benchmarks’
[master 83e38c7] added new benchmarks
1 files changed, 5 insertions(+), 0 deletions(-)[/cc]

Zauważ, że nie uruchamiasz [cc inline=”true” no_cc=”true”]git add[/cc] na pliku benchmarks.rb przed commitem.

Usuwanie plików

Żeby usunąć plik z gita, musisz usunąć go z śledzonych plików (bardziej dokładnie, usunąć go z Twojej poczekalni) a następnie scommitować. Polecenie [cc inline=”true” no_cc=”true”]git rm[/cc] zrobi to oraz usunie go również z Twojego katalogu roboczego, więc nie zobaczysz go jako nieśledzonego przy następnej okazji.

Jeżeli po prostu usuniesz plik z katalogu roboczego, zostanie on pokazany w sekcji „Changed but not updated” (tak jest, nie przechowywany) przy wyjściu polecenia [cc inline=”true” no_cc=”true”]git status[/cc]:

[cc lang=”bash”]$ rm grit.gemspec
$ git status
# On branch master
#
# Changed but not updated:
# (use „git add/rm …” to update what will be committed)
#
# deleted: grit.gemspec
#[/cc]

Następnie, jeżeli uruchomisz [cc inline=”true” no_cc=”true”]git rm[/cc], plik umieszczony w przechowalni zostanie usunięty:

{geshi}$ git rm grit.gemspec
rm ‚grit.gemspec’
$ git status
# On branch master
#
# Changes to be committed:
# (use „git reset HEAD …” to unstage)
#
# deleted: grit.gemspec
#[/cc]

Następnym razem kiedy scommitujesz, plik przestanie być dłużej śledzony. Jeżeli zmodyfikujesz ten plik i już dodałeś go do indeksu, musisz usunąć go siłą przy pomocy opcji [cc inline=”true” no_cc=”true”]-f[/cc]. Jest to zabezpieczenie przed przypadkowym usunięciem danych których nie zachowałeś jeszcze w zrzucie i nie może zostać odzyskany z gita.

Kolejną przydatną rzeczą, którą możesz chcieć zrobić jest zachowaniem w Twoim katalogu roboczym, ale usunięcie go z poczekalni. Innymi słowy, możesz chcieć zachować go na dysku twardym, ale żeby git przestał go śledzić. Jest to szczególnie użyteczne jeżeli zapomnisz dodać coś do pliku [cc inline=”true” no_cc=”true”].gitignore[/cc] i przypadkowo dodasz takie rzeczy, jak duży plik logów lub pliki kompilacji ([cc inline=”true” no_cc=”true”]*.a[/cc]). Żeby to zrobić użyj opcji [cc inline=”true” no_cc=”true”]–cached[/cc]:

[cc lang=”bash”]$ git rm –cached readme.txt[/cc]

Możesz dodać pliki, foldery i wzorce do polecenia [cc inline=”true” no_cc=”true”]git rm[/cc]. To oznacza że możesz robić takie rzeczy:

[cc lang=”bash”]$ git rm log/\*.log[/cc]

Zauważ backslash ([cc inline=”true” no_cc=”true”]\[/cc]) przed [cc inline=”true” no_cc=”true”]*[/cc]. Jest to konieczne, ponieważ git rozszerza wyrażenia regularne w stosunku do tych w powłoce. To polecenie usuwa wszystkie pliki które mają rozszerzenie [cc inline=”true” no_cc=”true”].log[/cc] w katalogu [cc inline=”true” no_cc=”true”]log/[/cc]. Lub możesz zrobić coś takiego:

[cc lang=”bash”]$ git rm \*~[/cc]

To polecenie usuwa wszystkie pliki kończące się na [cc inline=”true” no_cc=”true”]~[/cc].

Przenoszenie plików

W przeciwieństwie do wielu innych VCS, git nie uwzględnia przenoszenie śledzonych plików. Jeżeli zmienisz nazwę pliku w gitcie, żadne metadane przechowane w gitcie nie powiedzą Ci o tej zmianie nazwy. Jednak, git jest całkiem inteligentny jeżeli chodzi o odkrycie tego po fakcie – zajmiemy się wykrywaniem przenoszeniem pliku trochę później.

Jest to trochę mylące, że git posiada polecenie [cc inline=”true” no_cc=”true”]mv[/cc]. Jeżeli chcesz zmienić nazwę pliku w gitcie, możesz uruchomić coś takiego:

[cc lang=”bash”]$ git file_from file_to[/cc]

I działa to dobrze. W rzeczywistości, jeżeli uruchomisz coś takiego i spojrzysz w status, zobaczysz jak git wykrył przeniesienie pliku:

[cc lang=”bash”]$ git mv README.txt README
$ git status
# On branch master
# Your branch is ahead of ‚origin/master’ by 1 commit.
#
# Changes to be committed:
# (use „git reset HEAD …” to unstage)
#
# renamed: README.txt -> README
#[/cc]

Jednak, jest to równoznaczne uruchomieniu czegoś takiego:

[cc lang=”bash”]$ mv README.txt README
$ git rm README.txt
$ git add README[/cc]

Git odkrył, że jest to zmiana nazwy, więc nie ma znaczenia jeżeli zmienisz nazwę pliku tym sposobem czy poprzez polecenie [cc inline=”true” no_cc=”true”]mv[/cc]. Jedyną prawdziwą różnicą jest to, że [cc inline=”true” no_cc=”true”]mv[/cc] jest jednym poleceniem w miejsce trzech – jest to wygodna funkcjonalność. Bardziej interesujące jest to, że możesz użyć dowolnego narzędzia do zmiany nazwy pliku, a usunięcie „starego” i dodanie nowego pliku do repozytorium możesz zrobić później.

2.3 Przeglądanie historii commitów

Po stworzeniu kilku commitów lub jeżeli sklonowałeś repozytorium z istniejącymi commitami, prawdopodobnie chcesz przejrzeć co zdarzyło się wcześniej. Najbardziej BASIC i POWERFUL narzędziem do zrobienia tego jest polecenie [cc inline=”true” no_cc=”true”]git log[/cc].

Ten przykład używa bardzo prostego projektu nazwanego simplegit, którego często używam do demonstracji. Aby zdobyć ten projekt uruchom:

[cc lang=”bash”]git clone git://github.com/schacon/simplegit-progit.git[/cc]

Kiedy uruchomisz [cc inline=”true” no_cc=”true”]git log[/cc] w tym projekcie powinieneś dostać OUTPUT wyglądający mniej więcej tak:

[cc lang=”bash”]$ git log
commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon
Date: Mon Mar 17 21:52:11 2008 -0700

changed the version number

commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
Author: Scott Chacon
Date: Sat Mar 15 16:40:33 2008 -0700

removed unnecessary test code

commit a11bef06a3f659402fe7563abf99ad00de2209e6
Author: Scott Chacon
Date: Sat Mar 15 10:31:28 2008 -0700

first commit[/cc]

Domyślnie, bez argumentów, [cc inline=”true” no_cc=”true”]git log[/cc] listuje commity zrobione w repozytorium w odwrotnej chronologicznej kolejności. Znaczy to, że najnowsze commity zostaną pokazane jako pierwsze. Jak możesz zobaczyć, to polecenie wyświetla każdy commit z sumą kontrolną SHA-1, imię i nazwisko autora, e-mail, datę oraz wiadomość commita.

Duża liczba i różnorodność opcji polecenia [cc inline=”true” no_cc=”true”]git log[/cc] są dostępne aby pokazać Ci dokładnie czego poszukujesz. Teraz pokażemy kilka najbardziej użytecznych opcji.

Jedną z najbardziej pomocnych jest [cc inline=”true” no_cc=”true”]-p[/cc], która pokazuje różnice wprowadzone w każdym commitcie. Również możesz użyć [cc inline=”true” no_cc=”true”]-2[/cc], który limituje wyjście tylko do dwóch ostatnich pozycji:

[cc lang=”bash”]$ git log –p -2
commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon
Date: Mon Mar 17 21:52:11 2008 -0700

changed the version number

diff –git a/Rakefile b/Rakefile
index a874b73..8f94139 100644
— a/Rakefile
+++ b/Rakefile
@@ -5,7 +5,7 @@ require ‚rake/gempackagetask’
spec = Gem::Specification.new do |s|
– s.version = „0.1.0”
+ s.version = „0.1.1”
s.author = „Scott Chacon”

commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
Author: Scott Chacon
Date: Sat Mar 15 16:40:33 2008 -0700

removed unnecessary test code

diff –git a/lib/simplegit.rb b/lib/simplegit.rb
index a0a60ae..47c6340 100644
— a/lib/simplegit.rb
+++ b/lib/simplegit.rb
@@ -18,8 +18,3 @@ class SimpleGit
end

end

-if $0 == __FILE__
– git = SimpleGit.new
– puts git.show
-end
\ No newline at end of file[/cc]

Ta opcja wyświetla te same informacje lecz z różnicami bezpośrednio przed każdą pozycją. Jest to bardzo pomocne do przeglądania kodu lub szybkiego przeszukiwania co się stało podczas serii commitów które współpracownicy dodali. Możesz również użyć serii podsumowujących opcji z [cc inline=”true” no_cc=”true”]git log[/cc]. Na przykład, jeżeli chcesz zobaczyć trochę statystyk dla każdego commita, możesz użyć opcji [cc inline=”true” no_cc=”true”]–stat[/cc]:

[cc lang=”bash”]$ git log –stat
commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon
Date: Mon Mar 17 21:52:11 2008 -0700

changed the version number

Rakefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
Author: Scott Chacon
Date: Sat Mar 15 16:40:33 2008 -0700

removed unnecessary test code

lib/simplegit.rb | 5 —–
1 files changed, 0 insertions(+), 5 deletions(-)

commit a11bef06a3f659402fe7563abf99ad00de2209e6
Author: Scott Chacon
Date: Sat Mar 15 10:31:28 2008 -0700

first commit

README | 6 ++++++
Rakefile | 23 +++++++++++++++++++++++
lib/simplegit.rb | 25 +++++++++++++++++++++++++
3 files changed, 54 insertions(+), 0 deletions(-)[/cc]

Jak możesz zauważyć, opcja [cc inline=”true” no_cc=”true”]–stat[/cc] wypisuje listę zmodyfikowanych plików które są w commitach, ile z nich zostało zmienione, ile linii zostało dodane lub usunięte z tych plików. Również dodaje podsumowanie na końcu. Kolejną przydatną opcją jest [cc inline=”true” no_cc=”true”]–pretty[/cc]. Ta opcja zmienia format wyświetlania logów na inny niż domyślny. Dostępne jest kilka gotowych opcji. Opcja [cc inline=”true” no_cc=”true”]oneline[/cc] wypisuje każdy commit w jednej linii, jeżeli szukasz wielu commitów jest to bardzo przydatna opcja. Dodatkowo są dostępne opcje [cc inline=”true” no_cc=”true”]short[/cc], [cc inline=”true” no_cc=”true”]full[/cc] oraz [cc inline=”true” no_cc=”true”]fuller[/cc], pokazujące wyjście w podobnym formacie ale z mniejszą lub większą ilością informacji:

[cc lang=”bash”]$ git log –pretty=oneline
ca82a6dff817ec66f44342007202690a93763949 changed the version number
085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 removed unnecessary test code
a11bef06a3f659402fe7563abf99ad00de2209e6 first commit[/cc]

Najbardziej interesującą opcją jest [cc inline=”true” no_cc=”true”]format[/cc], która pozwala stworzyć własny format wyświetlania logów. Jest to szczególnie przydatne, gdy generujesz wyjście dla maszyny parującej – ponieważ sam ustalasz format, masz pewność, że nie zmieni się wraz z update’ami gita:

[cc lang=”bash”]$ git log –pretty=format:”%h – %an, %ar : %s”
ca82a6d – Scott Chacon, 11 months ago : changed the version number
085bb3b – Scott Chacon, 11 months ago : removed unnecessary test code
a11bef0 – Scott Chacon, 11 months ago : first commit[/cc]

Tabela 2-1 pokazuje kilka najbardziej przydatnych opcji do wykorzystania w opcji [cc inline=”true” no_cc=”true”]format[/cc]:

[cc lang=”bash”]Opcja Opis wyjścia
%H Hash commita
%h Skrócony hash commita
%T Drzewo hashy
%t Skrócone drzewo hashy
%P Hashe rodziców
%p Skrócone hashe rodziców
%an Imię autora
%ae e-mail autora
%ad Data (jest respektowana format opcja –date=)
%ar Relatywna data
%cn Imię commitera
%ce e-mail commitera
%cd Data commitera
%cr Relatywna data commitera
%s Tytuł[/cc]

Możesz się zastanawiam jaka jest różnica między autorem a commiterem. Autor jest osobą która oryginalnie pracowała nad daną częścią projektu, zaś commiter to osoba która ostatnia zaakceptowała pracę. Więc, jeżeli wyślesz patcha do projektu i jeden z członków go przyjmie, obydwoje zostaną umieszczeni w napisach końcowych – Ty jako autor, a członek projektu jako commiter. Więcej powiemy o tym w rozdziale 5.

Opcje [cc inline=”true” no_cc=”true”]oneline[/cc] i [cc inline=”true” no_cc=”true”]format[/cc] są przydatne z jeszcze jedną opcją polecenia [cc inline=”true” no_cc=”true”]log[/cc] nazwaną [cc inline=”true” no_cc=”true”]–graph[/cc]. Dodaje ona ładny wykres ASCII pokazujący gałęzie oraz historię złączeń, które możemy zobaczyć w naszej kopii repozytorium gita.

[cc lang=”bash”]$ git log –pretty=format:”%h %s” –graph
* 2d3acf9 ignore errors from SIGCHLD on trap
* 5e3ee11 Merge branch ‚master’ of git://github.com/dustin/grit
|\
| * 420eac9 Added a method for getting the current branch.
* | 30e367c timeout code and tests
* | 5a09431 add timeout protection to grit
* | e1193f8 support for heads with slashes in them
|/
* d6016bc require time for xmlschema
* 11d191e Merge branch ‚defunkt’ into local[/cc]

Są to tylko proste opcje do formatowania wyjścia w [cc inline=”true” no_cc=”true”]git log[/cc] – jest ich znacznie więcej. Tabela 2-2 pokazuje opcje które do tej pory odkryliśmy i trochę innych podstawowych opcji, które mogą być przydatne, z tym jak zmieniają wyjście polecenia [cc inline=”true” no_cc=”true”]log[/cc]:

[cc lang=”bash”]Opcje Opis
-p Pokaż patche dla każdego commita
–stat Pokaż statystyki dla każdego commita.
–shortstat Wyświetl tylko zmienione/dodane/usunięte linie z opcji –stat
–name-only Pokaż listę zmodyfikowanych plików po commitcie
–name-status Pokaż listę plików z informacjami o dodaniu/zmodyfikowaniu/usunięciu danych
–abbrev-commit Pokaż tylko kilka pierwszych liter z SHA-1
–relative-date Pokaż datę relatywnie („2 tygodnie temu”) zamiast pełnej
–graph Pokaż graf w ASCII obrazujący gałęzie i złączenia
–pretty Pokaż commity w alternatywnej formie. Opcja zwiera oneline, short, full, fuller i format (gdzie ustalasz swój własny format).[/cc]

Limitowanie wyjścia logów

Dodatkową, do formatowania wyjścia, [cc inline=”true” no_cc=”true”]git log[/cc] posiada kilka użyteczne opcje limitowania wyjścia – są to opcje, które pozwalają pokazać tylko część commitów. Widziałeś już jedną taką opcję – [cc inline=”true” no_cc=”true”]-2[/cc], która pokazuje tylko dwa ostatnie commity. W rzeczywistości możesz zrobić [cc inline=”true” no_cc=”true”]-<n>[/cc], gdzie [cc inline=”true” no_cc=”true”]n[/cc] jest liczbą naturalną pokazującą ostatnie [cc inline=”true” no_cc=”true”]n[/cc] commitów. W rzeczywistości, nie będziesz chciał używać tego często, ponieważ git domyślnie pokazuje tylko jedną stronię wyników na raz.

Jakkolwiek, limitowanie w czasie dzięki takim opcją jak [cc inline=”true” no_cc=”true”]–since[/cc] i [cc inline=”true” no_cc=”true”]–until[/cc] są bardzo przydatne. Na przykład to polecenie wyświetli listę commitów z dwóch ostatnich tygodni:

[cc lang=”bash”]$ git log –since=2.weeks[/cc]

Opcja ta działa z dużą liczbą formatów – możesz podać dokładną datę („2008-01-15”) lub relatywną datą jak „2 lata 1 dzień 3 minuty temu” (takie parametry należy podawać w języku angielskim więc poprawnie powinno być „2 years 1 day 3 minutes ago” – przyp. tłum.).

Możesz również filtrować listę commitów tak, żeby pasowała do listy kryteriów. Opcja [cc inline=”true” no_cc=”true”]–author[/cc] pozwala przefiltrować wyniki po konkretnym autorze, a opcja [cc inline=”true” no_cc=”true”]–grep[/cc] pozwala wyszukiwać słowo kluczowe w wiadomościach commitów. (Zauważ, że jeżeli chcesz wyświetlić dopasowanie do obu opcji, autora i grepa, musisz dodać [cc inline=”true” no_cc=”true”]–all-match[/cc] lub polecenie dopasuje commity do każdej opcji z osobna.)

Ostatnią na prawdę użyteczną opcją filtrującą jest ścieżka. Jeżeli określisz folder lub nazwę pliku, możesz ograniczyć wyjście loga do commitów które zawierają zmiany właśnie tych plików. Jest to zawsze ostatnia opcja i potrzeba oddzielić ją poprzez podwójny myślnik ([cc inline=”true” no_cc=”true”]–[/cc]) od pozostałych opcji.

W tabeli 2-3 są wypisane te i kilka innych opcji:

[cc lang=”bash”]Opcja Opis
-(n) Pokaż tylko n ostatnich commitów
–since, –after Ogranicz commity tylko do tych powstałych po podanej dacie
–until, –before Ogranicz commity tylko do tych powstałych przed podaną datą
–author Pokaż commity pasujące tylko do podanego autora
–committer Pokaż commity pasujące tylko do podanego commitera.[/cc]

Na przykład, jeżeli chcesz zobaczyć które commity modyfikowały pliki testowe w źródłach gita, zostały scommitowane przez Junio Hamano i nie zostały włączone w październiku 2008, możesz uruchomić coś takiego:

[cc lang=”bash”]$ git log –pretty=”%h – %s” –author=gitster –since=”2008-10-01″ \
–before=”2008-11-01″ –no-merges — t/
5610e3b – Fix testcase failure when extended attribute
acd3b9e – Enhance hold_lock_file_for_{update,append}()
f563754 – demonstrate breakage of detached checkout wi
d1a43f2 – reset –hard/read-tree –reset -u: remove un
51a94af – Fix „checkout –track -b newbranch” on detac
b0ad11e – pull: allow „git pull origin $something:$cur[/cc]

Z ponad 20000 commitów w historii kodu źródłowego gita, ta opcja pokazuje 6 tych, które pasują do kryteriów.

Używanie GUI do wizualizacji historii

Jeżeli chcesz używać narzędzia graficznego do wizualizacji historii commitów, możesz przyjrzeć się programowi napisanemu w Tcl/Tk nazwanego gitk, rozprowadzanym razem z gitem. Gitk jest prostym narzędziem wizualizacji [cc inline=”true” no_cc=”true”]git log[/cc], akceptuje wszystkie opcje filtrowania które ma [cc inline=”true” no_cc=”true”]git log[/cc]. Jeżeli wpiszesz polecenie [cc inline=”true” no_cc=”true”]gitk[/cc] w Twoim projekcie, powinieneś zobaczyć coś takiego jak na rysunku 2-2.

gitk

Rysunek 2-2: gitk

Możesz zobaczyć historię commitów w górnej części okna wraz z grafem. Przeglądarka różnić w dolnej części okna pokazuje zmiany wprowadzone do commita którego kliknąłeś.

Komentarze:

na razie tyle… czytam na raty ;)

Nie przejmuj się, że jest dużo błędów… ciesz się tym, że ktoś pomaga Ci to wyłapać ;)

do poprawki:

-„Jeżeli miałbyś przeczytać tylko jeden rozdział, żeby zacząć pracować z gitem, to jest właśnie ten”
+”Jeżeli miałbyś przeczytać tylko jeden rozdział, żeby zacząć pracować z gitem, to jest nim właśnie ten”

-„Za minutę wrócimy do tego, co te polecenia robią. ”
nie wiem dlaczego ale u mnie ten czas wydłużył się aż do 15 minut! Być może to z powodu kawy, którą sobie w między czasie zrobiłem. Może lepiej to zmienić? :)

-„każdy plik w Twoim katalogu roboczym, który nie były w ostatnim zrzucie i nie są w poczekalni. ”
+”wszystkie pliki w Twoim katalogu roboczym, który nie były w ostatnim zrzucie i nie są w poczekalni. ”

-„Kiedy po raz pierwszy klonujesz repozytorium, wszystkie pliki będą śledzona i niezmodyfikowane, ponieważ właśnie pobrałeś je i nie zmodyfikowałeś niczego.”
+”Kiedy po raz pierwszy klonujesz repozytorium, wszystkie pliki będą śledzone i niezmodyfikowane, ponieważ właśnie je pobrałeś i jeszcze nie zdążyłeś zmodyfikować niczego.”

ad. [image cykl życia stanu pliku].

Patrząc na pierwszą strzałkę „dodanie pliku” można zrozumieć, że chodzi o fizyczne dodanie/stworzenie pliku do/w katalogu projektu. Oczywiście chodzi tam jednak o polecenie git add. Przydalo by się jednak o tym wspomnieć, albo lepiej sprecyzować (dodając dodatkowe strzałki idące do stanu „nieśledzony”). Można było by dodać strzałkę „stworzenie pliku”.

-„Jeżeli uruchamiasz to polecenie zaraz po sklonowaniu, powinieneś coś takiego:”
+”Jeżeli uruchamiasz to polecenie zaraz po sklonowaniu, powinieneś zrobić coś takiego:”

-„Oznacza to, że masz czysty katalog roboczy – innymi słowy, nie ma tam śledzonych i zmodyfikowanych plików.”
+”Oznacza to, że masz czysty katalog roboczy – innymi słowy, nie ma tam śledzonych-zmodyfikowanych plików.”
Śledzony i zmodyfikowany są pojęciami o pewnym wspólnym przekroju znaczeniowym. Dobrze jest podkreślić w jakiś sposób, że chodzi o (plik1 == Śledzony) && (plik2 == zmodyfikowany) && (plik1 == plik2). Jednym słowem o plikach, które posiadają te dwa atrybuty jednocześnie.

-„Git również nie widzi żadnych nieśledzonych plików, w przeciwnym wypadku były tutaj wypisane. ”
+”Git również nie widzi żadnych nieśledzonych plików, w przeciwnym wypadku byłyby tutaj wypisane. ”

-„W następnym rozdziale przyjrzymy się bliżej gałęzią i referencją.”
+”W następnym rozdziale przyjrzymy się bliżej gałęziom i referencjom.”

chciałeś tutaj raczej użyć wyrazu „gałęzie” w liczbie mnogiej odmienionego w celowniku (komu? czemu?(się przyglądam..)) – gałęziom, niż wyrazu „gałęzie” w liczbie pojedynczej odmienionej w narzędniku
(z kim? z czym?(mówię..)) – gałęzią. Podobnie z wyrazem referencje.

-„Jeżeli chcesz zacząć dołączyć README, więc zacznijmy śledzić ten plik.”
???

-„Możesz wydać ponownie polecenie kiedy uruchamiałeś git init wcześniej, następnie git add – zaczniesz śledzić pliki w swoim folderze. ”
??? o której godzinie to pisałeś? :)

-„Polecenie git add pobiera ścieżkę dla każdego piku lub folderu; ”
+”Polecenie git add uruchamiane jest z argumentem będącym ścieżką do dodawanego piku lub folderu; ”

-„jeżeli jest to folder, polecenie doda wszystkie pliki w tym folderze rekursyjnie.”
+”jeżeli jest to folder, polecenie doda wszystkie pliki w tym folderze rekursywnie.”
Jest rekursja ale rzeczy robi się rekursywnie, tak jak i jest agresja ale rzeczy robi się agresywnie.

-„Jedna, jeszcze raz zobaczmy co pokazuje git status:”
+”Jednak, jeszcze raz zobaczmy co pokazuje git status:”

-„Często, masz zbiór plików które, nie chcesz aby git je automatycznie dodawał albo nawet pokazywał jako nieśledzone.”
+”Często, masz zbiór plików których, nie chcesz aby git automatycznie dodawał albo nawet pokazywał jako nieśledzone.”
albo jeszcze jakoś inaczej… :P bo też mi tutaj coś nie pasuje.

-„Druga linia mówi gitowi o ignorowaniu wszystkich plików kończących się na ~, które są używane przez wiele edytorów tekstowych, jak Emacs, do oznacza plików tymczasowych.”
+”Druga linia mówi gitowi o ignorowaniu wszystkich plików kończących się na ~, które są używane przez wiele edytorów tekstowych, jak Emacs, do oznaczania plików tymczasowych.”

-„Przygotowanie pliku .gitignore zanim zaczniesz cokolwiek robić jest dobrym pomysłem jeżeli nie chcesz przypadkowo scommitować plików, których nie chcesz mieć w swoim repozytorium gita.”
+”Jeżeli nie chcesz przypadkowo scommitować plików, których nie chcesz mieć w swoim repozytorium gita to dobrym pomysłem jest przygotowanie pliku .gitignore już na samym początku”

-„Kolejny przykład, jeżeli masz w przechowalni benchmarks.rb a następnie edytujesz go, użyjesz git diff żeby zobaczyć zmiany w pliku który masz w przechowalni i zmiany jeszcze do niej nie dodane:”
+”Kolejny przykład, jeżeli masz w przechowalni benchmarks.rb a następnie edytujesz go, użyjesz git diff żeby zobaczyć zmiany w pliku który masz w przechowalni i zmiany jeszcze do niego nie dodane:”

-„Pamiętaj, że wszystko co nie zostało do niej dodane – dowolny plik który stworzyłeś lub zmodyfikowałeś ale nie uruchomiłeś git add na nim od czasu kiedy go edytowałeś – nie będzie znajdował się w tym commitcie. ”
+”Pamiętaj, że wszystko co nie zostało do niej dodane – dowolny plik, który stworzyłeś lub zmodyfikowałeś, ale nie uruchomiłeś git add na nim od czasu, kiedy go edytowałeś – nie będzie znajdował się w tym commitcie. ”
przecinki.

-„Cokolwiek tam nie umieściłeś ciągle jest oznaczone jako zmodyfikowane. ”
użyłeś zbitku słów podobnego do frazeologizmu „Cokolwiek byś tam nie umieścił”, które w rozumieniu polaków może byc rozumiane jako „wszystko co tam umieściłeś”.
+”Wszystko to co było zmodyfikowane i nie było w staged area (a tym samym nie było przygotowywane go commitu) nadal jest oznaczone jako zmodyfikowane poza poczekalnią.”

-„Dodanie opcji -a do polecenia git commit powoduje automatyczne przechowywanie każdego pliku który jest już śledzony zanim zostanie zrobiony commit, pozwalając Ci ominąć git add:”
+”Dodanie opcji -a do polecenia git commit powoduje automatyczny commit w wszystkich plików zmodyfikowanych (tych z przechowywalni jak i poza nią). Pozwala Ci uniknąć wydawania polecenia git add:”

„{geshi}$ git rm grit.gemspec
rm ‘grit.gemspec’
$ git status
# On branch master
#
# Changes to be committed:
# (use “git reset HEAD …” to unstage)
#
# deleted: grit.gemspec
#[/cc]”

chyba nie zadziałał kawałek skryptu z powodu jakiejś literówki.

@noisy: ależ ja się w ogóle nie martwię, wiem, że mam masę błędów. Podziwiam tylko, że Ci się chce je wyłapywać i wypisywać.

Zalety dwóch monitorów ;)

Na jednym czytam sobie spokojnie, a na drugim wklejam stosowne fragmenty do edytora…

Ty się nie martw tym, czy mi się chce je wyłapywać, tylko tym skąd je brać. Maj minął, czerwiec leci a rozdziału o branchach dalej nie ma… :P

@noisy: jak mi się sesja skończy i będę wiedział na czym (a w zasadzie gdzie) stoję. W tej chwili mam urwanie głowy z tym wszystkim. -.-

-„Kolejną przydatną rzeczą, którą możesz chcieć zrobić jest zachowaniem w Twoim katalogu roboczym, ale usunięcie go z poczekalni.”
+”Kolejną przydatną rzeczą, którą możesz chcieć zrobić jest usunięcie pliku z poczekalni, przy jednoczesnym zachowaniu go w katalogu roboczym”

-„Innymi słowy, możesz chcieć zachować go na dysku twardym, ale żeby git przestał go śledzić. ”
+”Innymi słowy, możesz chcieć by plik zaczął być po prostu ignorowany.”

-„$ git file_from file_to”
+”$ git mv file_from file_to”

-„Jedyną prawdziwą różnicą jest to, że mv jest jednym poleceniem w miejsce trzech – jest to wygodna funkcjonalność”
+”Jedyną prawdziwą różnicą jest to, że git mv jest jednym poleceniem w miejsce trzech – jest to wygodna funkcjonalność”

-„Duża liczba i różnorodność opcji polecenia git log są dostępne aby pokazać Ci dokładnie czego poszukujesz. ”
+”Duża liczba i różnorodność opcji polecenia git log pozwolą Ci wyświetlić dokładnie te informacje jakie poszukujesz.”

-„Dodatkową, do formatowania wyjścia, git log posiada kilka użyteczne opcje limitowania wyjścia – są to opcje, które pozwalają pokazać tylko część commitów. ”
+”Dodatkowo, do formatowania wyjścia, git log posiada kilka użytecznych opcji limitowania wyjścia – są to opcje, które pozwalają pokazać tylko część commitów. ”

-„Jeżeli chcesz używać narzędzia graficznego do wizualizacji historii commitów, możesz przyjrzeć się programowi napisanemu w Tcl/Tk nazwanego gitk, rozprowadzanym razem z gitem. ”
na swoim ubuntu musiałem zainstalować go osobno za pomocą apt-get install gitk

PS. na końcu każdego rozdziału, przydałby się link do kolejnego, jeżeli tak owy został już stworzony.

Dzień dobry cześć i czołem, chciałem tylko podziękować za gites artykuł.
Szacunek dla autora.

@planetmr: to nie tutaj to pisz, tylko wyślij e-mail autorowi (on raczej nie zna polskiego ;]).

Fakt :) czytałem wyrywkowo, w takim razie dzięki za tłumaczenie.
pozdro

Wylapalem tylko
-”$ git file_from file_to”
+”$ git mv file_from file_to”

Ale to juz bylo :-) dzieki za tlumaczenie.

Rewelacja !! Jak dla mnie jest super !!

Hmm…

Jak zmienić nazwę branch’a master na inną nazwę ??

@piotr-e: nie zmieniaj. ;)

Dodaj komentarz:

 

Subscribe without commenting