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

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

Druga część, drugiego rozdziału (część pierwsza tutaj, a pierwszy rozdział tutaj) książki Pro Git autorstwa Scotta Chacona, wydanej na licencji Creative Commons Attribution-Non Commercial-Share Alike 3.0. Miłego czytania!

2.4 Cofanie zmian

W dowolnym czasie, możesz chcieć cofnąć coś. Tutaj przyjrzymy się kilku podstawowym narzędziom do cofania zmian które zrobiłeś. Bądź ostrożny, ponieważ nie zawsze możesz cofnąć niektóre z tych cofnięć. Jest to jeden z obszarów w gitcie gdzie możesz stracić swoją pracę jeżeli zrobisz coś źle.

Zmienianie Twojego ostatniego commita

Jednym z typowych cofnięć które ma miejsce jest kiedy za wcześnie zrobisz commit i zapomnisz dodać niektórych plików lub źle napiszesz wiadomość commita. Jeżeli chcesz spróbować stworzyć ten commit jeszcze raz, możesz uruchomić [cc inline=”true” no_cc=”true”]commit[/cc] z opcją [cc inline=”true” no_cc=”true”]–amend[/cc]:

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

Polecenie to wykorzystuje przechowalnię na potrzeby modyfikacji commitu. Jeżeli nie zrobiłeś żadnych zmian od ostatniego commitu (np przykład, to polecenie zostało uruchomione bezpośrednio po poprzednim commitcie), wtedy Twój zrzut będzie wyglądał dokładnie tak samo i wszystkie co zmienisz to wiadomość commita.

Zostanie uruchomiony ten sam edytor wiadomości commitów, ale będzie już zawierał wiadomość z poprzedniego commita. Możesz edytować wiadomość tak samo jak zawsze, ale to nadpisze Twój poprzedni commit.

Na przykład, jeżeli scommitowałeś swoją pracę, a potem uświadomiłeś sobie, że zapomniałeś wrzucić do przechowalni zmiany z pliku którego chciałeś dodać do tego commita, możesz zrobić coś takiego:

[cc lang=”bash”]$ git commit -m ‚initial commit’
$ git add zapomniany_plik
$ git commit –amend[/cc]

Po wykonaniu wszystkich 3 poleceń zostanie jeden commit – zastępujący rezultat pierwszego.

Pozbywanie się pliku z poczekalni

W następnych dwóch sekcjach pokażę jak cofać zmiany w poczekalni i katalogu roboczym. Miłym akcentem w tym poleceniu jest to, że przy zmianie stanu tych dwóch obszarów przypomina również, jak cofnąć te zmiany. Na przykład, jeżeli zmieniłeś dwa pliki i chcesz je scommitować jako dwie oddzielne zmiany, ale wydałeś już polecenie [cc inline=”true” no_cc=”true”]git add *[/cc] i masz już w przechowalni oba. Jak możesz wyrzucić z poczekalni jeden z nich? Informuje o tym polecenie [cc inline=”true” no_cc=”true”]git status[/cc]:

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

Zaraz pod tekstem „Changes to be committed” jest napisane, aby użyć [cc inline=”true” no_cc=”true”]git reset HEAD <plik>[/cc] aby wyrzucić plik z poczekalni. Więc użyjmy tej podpowiedzi żeby pozbyć się pliku benchmarks.rb z poczekalni:

[cc lang=”bash”]$ git reset HEAD benchmarks.rb
benchmarks.rb: locally modified
$ git status
# On branch master
# Changes to be committed:
# (use „git reset HEAD …” to unstage)
#
# modified: README.txt
#
# Changed but not updated:
# (use „git add
…” to update what will be committed)
# (use „git checkout —
…” to discard changes in working directory)
#
# modified: benchmarks.rb
#[/cc]

To polecenie jest trochę dziwne, ale działa. Plik benchmarks.rb jest zmodyfikowany ale poza poczekalnią.

Cofanie zmian pliku

Co zrobić jeżeli uświadomiłeś sobie, że jednak nie chcesz zmian, które wprowadziłeś do pliku benchmarks.rb? Jak możesz łatwo cofnąć zmiany, żeby wyglądał tak jak w czasie ostatniego commita (lub klonowania, albo w jakiś inny sposób w jakim miałeś katalog roboczy)? Na szczęście, [cc inline=”true” no_cc=”true”]git status[/cc] także mówi nam jak to zrobić. W wyjściu ostatniego przykładu, pliki poza poczekalnią wyglądają mniej więcej tak:

[cc lang=”bash”]# Changed but not updated:
# (use „git add …” to update what will be committed)
# (use „git checkout —
…” to discard changes in working directory)
#
# modified: benchmarks.rb
#[/cc]

Mówi nam to, jak porzucić zmiany które zrobiliśmy. Więc wypróbujmy to:

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

Możesz zobaczyć, że zmiany zostały cofnięte. Powinieneś sobie uświadomić, że jest to niebezpieczne polecenie: jakiekolwiek zmiany, które zrobiłeś w tym pliku zostaną utracone – po prostu skopiujesz inny plik nadpisując ten. Nigdy nie uruchamiaj tego polecenie dopóki nie jesteś absolutnie pewien, że nie chcesz tego co zrobiłeś w tym pliku.Jeżeli po prostu potrzebujesz odstawić na chwilę zmiany na bok, to powinieneś użyć gałęzi i stashy (dowiesz się o nich z następnego rozdziału).

Pamiętaj, cokolwiek zostało scommitowego w gitcie jest prawie zawsze do odzyskania. Nawet commity które były w gałęziach które zostały skasowane lub commity nadpisane poprzez [cc inline=”true” no_cc=”true”]–amend[/cc] mogą być odzyskane (zobacz rozdział 9). Jednak cokolwiek stracisz a nie zostało scommitowane przepadnie na zawsze.

2.5 Praca ze zdalnymi repozytoriami

Aby była możliwa współpraca w jakimkolwiek projekcie trzymanym w repozytoriach gita, musisz wiedzieć jak zarządzać Twoimi zdalnymi repozytoriami. Zdalne repozytoria są wersjami Twojego projektu, które są hostowane w internecie albo w sieci gdziekolwiek indziej. Możesz posiadać kilka takich repozytoriów, przeważnie każdy jest albo tylko do odczytu albo do odczytu i zapisu dla Ciebie. Współpraca z innymi wprowadza zarządzania tymi zdalnymi repozytoriami i wypychanie oraz ściąganie danych do i z tych repozytoriów wtedy kiedy chcesz się podzielić swoją pracą. Zarządzanie nimi wymusza znajomości jak dodawać zdalne repozytoria, usuwać kiedy już nie ma już uzasadnienia aby dłużej je trzymać, zarządzanie różnymi zdalnymi gałęziami oraz definiowanie ich jako śledzących lub nie, oraz znacznie więcej. W tej sekcji, odkryjemy te umiejętności.

Pokazywanie zdalnych repozytoriów

Żeby zobaczyć który zdalny serwer masz skonfigurowany, możesz uruchomić polecenie [cc inline=”true” no_cc=”true”]git remote[/cc]. Wypisze krótką nazwę każdego serwera który ustawiłeś. Jeżeli sklonowałeś repozytorium, powinieneś zobaczyć [cc inline=”true” no_cc=”true”]origin[/cc] – jest to domyślna nazwa dla serwerów z których klonowałeś:

[cc lang=”bash”]$ git clone git://github.com/schacon/ticgit.git
Initialized empty Git repository in /private/tmp/ticgit/.git/
remote: Counting objects: 595, done.
remote: Compressing objects: 100% (269/269), done.
remote: Total 595 (delta 255), reused 589 (delta 253)
Receiving objects: 100% (595/595), 73.31 KiB | 1 KiB/s, done.
Resolving deltas: 100% (255/255), done.
$ cd ticgit
$ git remote
origin[/cc]

Możesz również dodać [cc inline=”true” no_cc=”true”]-v[/cc], które pokaże URL które git przechowuje pod tymi krótkimi nazwami:

[cc lang=”bash”]$ git remote -v
origin git://github.com/schacon/ticgit.git[/cc]

Jeżeli masz więcej niż jedno zdalne repozytorium, to polecenie wypisze je wszystkie. Na przykład moje repozytorium Grit wygląda mniej więcej tak:

[cc lang=”bash”]$ cd grit
$ git remote -v
bakkdoor git://github.com/bakkdoor/grit.git
cho45 git://github.com/cho45/grit.git
defunkt git://github.com/defunkt/grit.git
koke git://github.com/koke/grit.git
origin git@github.com:mojombo/grit.git[/cc]

Oznacza to, że możemy ściągnąć wkład do projektu od każdego z tych ludzi całkiem łatwo. Zauważ jednak, że tylko [cc inline=”true” no_cc=”true”]origin[/cc] ma URL SSH, więc jest jedynym do którego mogę wysyłać (dlaczego tak jest przeczytasz w rozdziale 4).

Dodawanie zdalnych repozytoriów

Wspomniałem i dałem kilka przykładów dodawania zdalnych repozytoriów w poprzednich częściach, ale tutaj dokładnie wyjaśnię jak to robić. Żeby dodać nowe zdalne repozytorium wraz z jego krótką nazwą, do której mógłbyś się łatwo odwołać, uruchom [cc inline=”true” no_cc=”true”]git remote add [nazwa] [url][/cc]:

[cc lang=”bash”]$ git remote
origin
$ git remote add pb git://github.com/paulboone/ticgit.git
$ git remote -v
origin git://github.com/schacon/ticgit.git
pb git://github.com/paulboone/ticgit.git[/cc]

Teraz możesz użyć nazwy [cc inline=”true” no_cc=”true”]pb[/cc] w poleceniu w miejscu całego URLa. Na przykład, jeżeli chcesz ściągnąć (fetch) wszystkie dane, które Paul ma, których Ty jeszcze nie masz w swoich repozytorium, możesz uruchomić [cc inline=”true” no_cc=”true”]git fetch pb[/cc]:

[cc lang=”bash”]$ git fetch pb
remote: Counting objects: 58, done.
remote: Compressing objects: 100% (41/41), done.
remote: Total 44 (delta 24), reused 1 (delta 0)
Unpacking objects: 100% (44/44), done.
From git://github.com/paulboone/ticgit
* [new branch] master -> pb/master
* [new branch] ticgit -> pb/ticgit[/cc]

Gałąź master Paula jest dostępna lokalnie jako [cc inline=”true” no_cc=”true”]pb/master[/cc] – możesz ją włączyć do jednej z Twoich gałęzi lub możesz przejrzeć lokalną gałąź w tym momencie jeżeli chcesz ją sprawdzić.

Ściąganie (fetch i pull) z Twoich zdalnych repozytoriów

Jak już widziałeś, żeby pobrać dane z Twoich zdalnych repozytoriów, możesz uruchomić:

[cc lang=”bash”]$ git fetch [remote][/cc]

To polecenie przechodzi do zdalnego repozytorium i pobiera wszystkie dane, których jeszcze nie masz. Po tym, powinieneś mieć dowiązania do wszystkich gałęzi z tego zdalnego repozytorium, które możesz włączyć do projekt lub przejrzeć w dowolnym czasie. (Przyjrzymy się gałęzią i tym jak je używać w rozdziale 3.)

Jeżeli sklonujesz repozytorium, polecenie automatycznie doda zdalne repozytorium pod nazwą [cc inline=”true” no_cc=”true”]origin[/cc], Więc, [cc inline=”true” no_cc=”true”]git fetch origin[/cc] ściąga każdą nową pracę, która została wypchnięta do serwera od kiedy sklonowałeś repozytorium z niego (lub ostatni raz ściągnąłeś dane). Ważne jest abyś zapamiętał, że polecenie [cc inline=”true” no_cc=”true”]fetch[/cc] tylko ściąga dane do Twojego lokalnego repozytorium – nie włącza, automatycznie, ich do Twojej pracy czy modyfikacji nad którą aktualnie pracujesz. Musisz włączyć je ręcznie do swojej kopii, kiedy jesteś na to gotowy.

Jeżeli masz gałąź, która śledzi zdalną gałąź (po więcej informacji zobacz następną sekcję i rozdział 3), możesz użyć polecenia [cc inline=”true” no_cc=”true”]git pull[/cc] do automatycznego ściągnięcia i włączenia zdalnej gałęzi do Twojej aktualnej gałęzi. Może to być łatwiejszy i bardziej komfortowy sposób pracy dla Ciebie. Domyślnie, polecenie [cc inline=”true” no_cc=”true”]git clone[/cc] automatycznie ustawi Twoją lokalną gałąź główną do śledzenia głównej gałęzi na serwerze z którego sklonowałeś repozytorium (przyjmując, że zdalne repozytorium posiada główną gałąź). Uruchamiając [cc inline=”true” no_cc=”true”]git pull[/cc] pobierasz dane z serwera, z którego sklonowałeś repozytorium i automatycznie jest podejmowana próba włączenia tego kodu do tego nad czym teraz pracujesz.

Wypychanie Twojego repozytorium

Kiedy jesteś w momencie, w którym chcesz się podzielić swoim projektem, możesz wypchnąć go na zewnątrz. Polecenie jest bardzo proste: [cc inline=”true” no_cc=”true”]git push [remote] [branch][/cc]. Jeżeli chcesz wypchnąć Twoją główną gałąź do Twojego serwera [cc inline=”true” no_cc=”true”]origin[/cc] (znowu, klonowanie ustawia tą nazwę automatycznie), wtedy możesz uruchomić polecenie do wypchnięcia Twojej pracy na serwer:

[cc lang=”bash”]$ git push origin master[/cc]

To polecenie działa tylko jeżeli sklonowałeś repozytorium z serwera, do którego masz prawa zapisu i nikt nie wypchnął swojej pracy w międzyczasie. Jeżeli Ty i ktoś inny sklonowaliście repozytorium w tym samym czasie i ta osoba wypchnęła swoją pracę a później zrobiłeś to Ty, Twoje wysłanie zostanie przerwane. Będziesz musiał najpierw pobrać czyjś kod najpierw pobrać i włączyć go do swojego kodu zanim będziesz mógł wypchnąć swój. Po więcej informacji na temat wypychania danych na zdalne serwery przejdź do rozdziału 3.

Przeglądanie zdalnego repozytorium

Jeżeli chcesz zobaczyć więcej szczegółowych informacji o zdalnych repozytoriach, możesz użyć polecenia [cc inline=”true” no_cc=”true”]git remote show [remote][/cc]. Jeżeli uruchomisz to polecenie z nazwą repozytorium, np. [cc inline=”true” no_cc=”true”]origin[/cc], możesz uzyskać coś takiego:

[cc lang=”bash”]$ git remote show origin
* remote origin
URL: git://github.com/schacon/ticgit.git
Remote branch merged with ‚git pull’ while on branch master
master
Tracked remote branches
master
ticgit[/cc]

Polecenie to pokaże URLe zdalnych repozytoriów jak również informacje na temat śledzonych gałęzi. To polecenie powie Ci, że jeżeli jesteś w gałęzi głównej i uruchomisz [cc inline=”true” no_cc=”true”]git pull[/cc], zostanie przeprowadzony automatyczny włączenie głównej gałęzi z zdalnego repozytorium, po pobraniu wszystkich informacji. Pokazuje również wszystkie zdalne powiązania które zostały ściągnięte.

Prosty przykład z którym mógłbyś się spotkać. Kiedy używasz gita częściej, będziesz mógł zobaczyć takie informacje od [cc inline=”true” no_cc=”true”]git remote show[/cc]:

[cc lang=”bash”]$ git remote show origin
* remote origin
URL: git@github.com:defunkt/github.git
Remote branch merged with ‚git pull’ while on branch issues
issues
Remote branch merged with ‚git pull’ while on branch master
master
New remote branches (next fetch will store in remotes/origin)
caching
Stale tracking branches (use ‚git remote prune’)
libwalker
walker2
Tracked remote branches
acl
apiv2
dashboard2
issues
master
postgres
Local branch pushed with ‚git push’
master:master[/cc]

Polecenie to pokazuje która gałąź jest automatycznie wypychana, kiedy uruchomisz [cc inline=”true” no_cc=”true”]git push[/cc] na jakiejś gałęzi. Pokazuje również której zdalnej gałęzi, na serwerze, jeszcze nie masz, również, którą już masz, a została usunięte z serwera oraz gałęzie które zostaną automatycznie włączone do projektu, kiedy uruchomisz [cc inline=”true” no_cc=”true”]git pull[/cc].

Usuwanie i zmiana nazwy zdalnych repozytoriów

Jeżeli chcesz zmienić nazwę zdalnego repozytorium, w nowszych wersjach gita, możesz uruchomić [cc inline=”true” no_cc=”true”]git remote rename[/cc] żeby zmienić nazwę repozytorium. Na przykład, jeżeli chcesz zmienić nazwę [cc inline=”true” no_cc=”true”]pb[/cc] na [cc inline=”true” no_cc=”true”]paul[/cc] możesz zrobić to z [cc inline=”true” no_cc=”true”]git remote rename[/cc]:

[cc lang=”bash”]$ git remote rename pb paul
$ git remote
origin
paul[/cc]

Warto przypomnieć, że zmienia to również nazwy zdalnych gałęzi. Wcześniej używane dowiązanie [cc inline=”true” no_cc=”true”]pb/master[/cc] to teraz [cc inline=”true” no_cc=”true”]paul/master[/cc].

Jeżeli, z jakiś powodów, chcesz usunąć dowiązanie – przeniosłeś serwer lub nie używasz dłużej tego mirroru, lub prawdopodobnie dłużej nie współpracujesz z danym programistą – możesz użyć [cc inline=”true” no_cc=”true”]git remote rm[/cc]:

[cc lang=”bash”]$ git remote rm paul
$ git remote
origin[/cc]

2.6 Tagowanie

Jak większość VCS, git jest zdolny do tagowania specyficznych punktów w historii jako ważne. Generalnie, ludzie używają tej funkcji do oznaczenia wydać (v1.0 i kolejnych). W tej sekcji, nauczysz się jak wyświetlać dostępne tagi, tworzyć nowe oraz jakie są różnice między różnymi typami tagów.

Wyświetlanie tagów

Wypisywanie dostępnych tagów w gitcie jest bardzo łatwe. Po prostu wpisz [cc inline=”true” no_cc=”true”]git tag[/cc]:

[cc lang=”bash”]$ git tag
v0.1
v1.3[/cc]

Polecenie to wypisze tagi w kolejności alfabetycznej. Kolejność w której się pojawiają nie jest zbyt istotna.

Możesz również poszukiwać tagów przy pomocy wyrażeń regularnych. Repozytorium kodu gita zawiera ponad 240 tagów. Jeżeli jesteś zainteresowany tylko przejrzeniem serii 1.4.2, możesz uruchomić takie polecenie:

[cc lang=”bash”]$ git tag -l ‚v1.4.2.*’
v1.4.2.1
v1.4.2.2
v1.4.2.3
v1.4.2.4[/cc]

Tworzenie tagów

Git używa dwóch rodzajów tagów: lekkich oraz adnotacji. Lekki tag jest bardziej jak gałąź która nic nie zmienia – jest po prostu wskaźnikiem do specyficznego commita. Tagi adnotujące, są przechowywane jako pełne obiekty w bazie gita. Mają sumy kontrolne, zawierają nazwę tagującego, e-mail oraz datę. Posiadają również wiadomość dołączoną do tagu. Mogą być również podpisane i zweryfikowane przez GNU Privacy Guard (GPG). Generalnie jest zalecane, żebyś tworzył tagi adnotujące, żebyś mógł trzymać wszystkie informacje. Jednak, jeżeli chcesz tymczasowego tagu lub z jakiś powodów nie chcesz zachować innych informacji, lekkie tagi również są dostępne.

Tagi adnotujące

Tworzenie adnotujących tagów w gitcie jest proste. Najłatwiejszym sposobem jest wykorzystanie opcji [cc inline=”true” no_cc=”true”]-a[/cc] kiedy uruchamiasz polecenie [cc inline=”true” no_cc=”true”]tag[/cc]:

[cc lang=”bash”]$ git tag -a v1.4 -m ‚my version 1.4’
$ git tag
v0.1
v1.3
v1.4[/cc]

Parametr [cc inline=”true” no_cc=”true”]-m[/cc] określa wiadomość tagu, która jest w nim przechowywana. Jeżeli jej nie ustawisz dla tagu adnotującego, git uruchomi Twój edytor tekstu abyś mógł ją wpisać.

Możesz zobaczyć dane tagu razem z commitem do którego ten tag został przypisany używając polecenia [cc inline=”true” no_cc=”true”]git show[/cc]:

[cc lang=”bash”]$ git show v1.4
tag v1.4
Tagger: Scott Chacon
Date: Mon Feb 9 14:45:11 2009 -0800

my version 1.4
commit 15027957951b64cf874c3557a0f3547bd83b3ff6
Merge: 4a447f7… a6b4c97…
Author: Scott Chacon
Date: Sun Feb 8 19:02:46 2009 -0800

Merge branch ‚experiment'[/cc]

Zostaną pokazane informacje o osobie która utworzyła ten tag, datę commita który został otagowany, oraz wiadomość z adnotacji przed informacjami z commita.

Podpisywanie tagów

Możesz również podpisać swoje tagi przy pomocy GPG, zakładając że masz klucz prywatny. Wszystko co musisz zrobić to użyć parametru [cc inline=”true” no_cc=”true”]-s[/cc] zamiast [cc inline=”true” no_cc=”true”]-a[/cc]:

[cc lang=”bash”]$ git tag -s v1.5 -m ‚my signed 1.5 tag’
You need a passphrase to unlock the secret key for
user: „Scott Chacon
1024-bit DSA key, ID F721C45A, created 2009-02-09[/cc]

Jeżeli uruchomisz [cc inline=”true” no_cc=”true”]git show[/cc] na tagu, możesz zobaczyć sygnaturę GPG dołączoną do niego:

[cc lang=”bash”]$ git show v1.5
tag v1.5
Tagger: Scott Chacon
Date: Mon Feb 9 15:22:20 2009 -0800

my signed 1.5 tag
—–BEGIN PGP SIGNATURE—–
Version: GnuPG v1.4.8 (Darwin)

iEYEABECAAYFAkmQurIACgkQON3DxfchxFr5cACeIMN+ZxLKggJQf0QYiQBwgySN
Ki0An2JeAVUCAiJ7Ox6ZEtK+NvZAj82/
=WryJ
—–END PGP SIGNATURE—–
commit 15027957951b64cf874c3557a0f3547bd83b3ff6
Merge: 4a447f7… a6b4c97…
Author: Scott Chacon
Date: Sun Feb 8 19:02:46 2009 -0800

Merge branch ‚experiment'[/cc]

Trochę później nauczysz się, jak weryfikować podpisane tagi.

Lekkie tagi

Kolejnym sposobem na tagowanie commitów jest użycie lekkich tagów. Najprościej mówiąc jest to suma kontrolna commita przechowywana w pliki – brak jakichkolwiek innych informacji. Żeby stworzyć lekkiego tagu nie należy dodawać opcji [cc inline=”true” no_cc=”true”]-a[/cc], [cc inline=”true” no_cc=”true”]-s[/cc] lub [cc inline=”true” no_cc=”true”]-m[/cc]:

[cc lang=”bash”]$ git tag v1.4-lw
$ git tag
v0.1
v1.3
v1.4
v1.4-lw
v1.5[/cc]

Tym razem, jeżeli uruchomisz [cc inline=”true” no_cc=”true”]git show[/cc] na tagu, nie zobaczysz żadnych dodatkowych informacji. Polecenie po prostu pokaże commita:

[cc lang=”bash”]$ git show v1.4-lw
commit 15027957951b64cf874c3557a0f3547bd83b3ff6
Merge: 4a447f7… a6b4c97…
Author: Scott Chacon
Date: Sun Feb 8 19:02:46 2009 -0800

Merge branch ‚experiment'[/cc]

Weryfikacja tagów

Żeby zweryfikować podpisany tag, musisz użyć [cc inline=”true” no_cc=”true”]git tag -v [tag][/cc]. To polecenie używa GPG do zweryfikowania sygnatury. Potrzebujesz klucza publicznego osoby podpisującej, żeby wszystko działało poprawnie:

[cc lang=”bash”]$ git tag -v v1.4.2.1
object 883653babd8ee7ea23e6a5c392bb739348b1eb61
type commit
tag v1.4.2.1
tagger Junio C Hamano 1158138501 -0700

GIT 1.4.2.1

Minor fixes since 1.4.2, including git-mv and git-http with alternates.
gpg: Signature made Wed Sep 13 02:08:25 2006 PDT using DSA key ID F3119B9A
gpg: Good signature from „Junio C Hamano
gpg: aka „[jpeg image of size 1513]”
Primary key fingerprint: 3565 2A26 2040 E066 C9A7 4A7D C0C6 D9A4 F311 9B9A[/cc]

Jeżeli nie masz klucza publicznego osoby która podpisała tagu otrzymasz coś takiego:

[cc lang=”bash”]gpg: Signature made Wed Sep 13 02:08:25 2006 PDT using DSA key ID F3119B9A
gpg: Can’t check signature: public key not found
error: could not verify the tag ‚v1.4.2.1′[/cc]

Późniejsze tagowanie

Możesz również otagować commity, które . Prawdopodobnie Twoja historia commitów będzie wyglądała mniej więcej tak:

[cc lang=”bash”]$ git log –pretty=oneline
15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch ‚experiment’
a6b4c97498bd301d84096da251c98a07c7723e65 beginning write support
0d52aaab4479697da7686c15f77a3d64d9165190 one more thing
6d52a271eda8725415634dd79daabbc4d9b6008e Merge branch ‚experiment’
0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc added a commit function
4682c3261057305bdd616e23b64b0857d832627b added a todo file
166ae0c4d3f420721acbb115cc33848dfcc2121a started write support
9fceb02d0ae598e95dc970b74767f19372d61af8 updated rakefile
964f16d36dfccde844893cac5b347e7b3d44abbc commit the todo
8a5cbc430f1a9c3d00faaeffd07798508422908a updated readme[/cc]

Teraz, prawdopodobnie zapomniałeś otagować projekt jako v1.2, który powinien być na commitcie „updated rakefile”. Możesz to zrobić po fakcie. Aby otagować commit, na końcu polecenia musisz określić sumę kontrolną (lub jej część) commita:

[cc lang=”bash”]$ git tag -a v1.2 9fceb02[/cc]

Teraz możesz zobaczyć ten otagowany commit:

[cc lang=”bash”]$ git tag
v0.1
v1.2
v1.3
v1.4
v1.4-lw
v1.5

$ git show v1.2
tag v1.2
Tagger: Scott Chacon
Date: Mon Feb 9 15:32:16 2009 -0800

version 1.2
commit 9fceb02d0ae598e95dc970b74767f19372d61af8
Author: Magnus Chacon
Date: Sun Apr 27 20:43:35 2008 -0700

updated rakefile
…[/cc]

Współdzielenie tagów

Domyślnie, polecenie [cc inline=”true” no_cc=”true”]git push[/cc] nie przesyła tagów do zdalnego serwera. Musisz wymusić wysłanie tagu do współdzielonego serwera po tym jak go utworzysz. Ten proces jest jak współdzielenie zdalnych gałęzi – uruchamiasz [cc inline=”true” no_cc=”true”]git push origin [tag][/cc].

[cc lang=”bash”]$ git push origin v1.5
Counting objects: 50, done.
Compressing objects: 100% (38/38), done.
Writing objects: 100% (44/44), 4.56 KiB, done.
Total 44 (delta 18), reused 8 (delta 1)
To git@github.com:schacon/simplegit.git
* [new tag] v1.5 -> v1.5[/cc]

Jeżeli masz dużo tagów które chcesz wypchnąć za jednym razem możesz również użyć opcji [cc inline=”true” no_cc=”true”]–tags[/cc] dla polecenia [cc inline=”true” no_cc=”true”]git push[/cc]. Przeniesie to wszystkie Twoje tagi, do zdalnego serwera, jeżeli jeszcze ich tam nie ma.

[cc lang=”bash”]$ git push origin –tags
Counting objects: 50, done.
Compressing objects: 100% (38/38), done.
Writing objects: 100% (44/44), 4.56 KiB, done.
Total 44 (delta 18), reused 8 (delta 1)
To git@github.com:schacon/simplegit.git
* [new tag] v0.1 -> v0.1
* [new tag] v1.2 -> v1.2
* [new tag] v1.4 -> v1.4
* [new tag] v1.4-lw -> v1.4-lw
* [new tag] v1.5 -> v1.5[/cc]

Teraz, kiedy ktoś inny sklonuje lub pobierze dane z Twojego repozytorium, będą mieli również wszystkie tagi.

2.7 Tips and Tricks

Zanim skończymy ten rozdział o podstawach gita, kilka małych tricków mogących uczyć Twoje doświadczenia z gitem trochę prostsze, łatwiejsze i bardziej przyjazne. Wielu ludzi używa gita bez tych sztuczek i nie będziemy nawiązywać do nich później w tej książce ale powinieneś wiedzieć jak ich używać.

Auto uzupełnianie

Jeżeli używasz basha, git dostarcza Ci ciekawy skrypt do auto uzupełniania który mógłbyś włączyć. Ściągnij kod źródłowy gita i zobacz do folderu [cc inline=”true” no_cc=”true”]contrib/completion[/cc]. Powinien być tam plik nazwany [cc inline=”true” no_cc=”true”]git-completion.bash[/cc]. Skopiuj ten plik do Twojego katalogu domowego i dodaj tą linię do Twojego pliku [cc inline=”true” no_cc=”true”].bashrc[/cc]:

[cc lang=”bash”]source ~/.git-completion.bash[/cc]

Jeżeli chcesz zrobić tak, aby bash automatycznie uzupełniał polecenia gita dla wszystkich użytkowników, skopiuj tej skrypt do folderu [cc inline=”true” no_cc=”true”]/opt/local/etc/bash_completion.d[/cc] na Macu lub do [cc inline=”true” no_cc=”true”]/etc/bash_completion.d/[/cc] na Linuksie. Jest to folder ze skryptami, które Bash automatycznie ładuje aby zapewnić uzupełnianie.

Jeżeli używasz Windowsa z Bashem, który jest domyślnie instalowany kiedy instalujesz gita na Windowsie z msysGit autouzupełnianie powinno być już skonfigurowane.

Naciśnij klawisz [cc inline=”true” no_cc=”true”]Tab[/cc] w czasie pisania polecenia gita. Powinieneś dostać zbiór sugestii z których możesz wybrać to którego potrzebujesz:

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

W tym wypadku, wpisując [cc inline=”true” no_cc=”true”]git co[/cc] i wciskając klawisz [cc inline=”true” no_cc=”true”]Tab[/cc] dwa razy zostanie nam zasugerowany [cc inline=”true” no_cc=”true”]commit[/cc] i [cc inline=”true” no_cc=”true”]config[/cc]. Dodanie [cc inline=”true” no_cc=”true”]m<tab>[/cc] uzupełni do [cc inline=”true” no_cc=”true”]git commit[/cc] automatycznie.

To również działa z opcjami, co może być nawet bardziej pomocne. Na przykład, jeżeli chcesz uruchomić polecenie [cc inline=”true” no_cc=”true”]git log[/cc] i nie możesz sobie przypomnieć jednej z opcji możesz zacząć pisać ją i wcisnąć [cc inline=”true” no_cc=”true”]Tab[/cc] żeby zobaczyć pasujące:

[cc lang=”bash”]$ git log –s
–shortstat –since= –src-prefix= –stat –summary[/cc]

Ten całkiem niezły trick może pozwolić Ci zaoszczędzić trochę czasu i czytania dokumentacji.

Aliasy

Git nie domyśli się poleceń jeżeli wpiszesz je częściowo. Jeżeli nie chcesz wpisywać całych poleceń, możesz łatwo ustawić aliasy dla każdego polecenia używając [cc inline=”true” no_cc=”true”]git config[/cc]. Kilka przykładów tego co możesz chcieć ustawić:

[cc lang=”bash”]$ git config –global alias.co checkout
$ git config –global alias.br branch
$ git config –global alias.ci commit
$ git config –global alias.st status[/cc]

Oznacza to, że zamiast wpisywać [cc inline=”true” no_cc=”true”]git commit[/cc] możesz po prostu napisać [cc inline=”true” no_cc=”true”]git ci[/cc]. Kiedy zaczniesz używać gita, prawdopodobnie będziesz używał innych poleceń równie często. W tym wypadku nie wahaj się tworzyć nowe aliasy.

Ta technika może być również bardzo pomocna w tworzeniu poleceń które uważasz że powinny istnieć. Na przykład, aby usuwać pliki z poczekalni, możesz dodać taki alias do gita:

[cc lang=”bash”]$ git config –global alias.unstage ‚reset HEAD –‚[/cc]

Spowoduje to, że poniższe polecenia będą równoznaczne:

[cc lang=”bash”]$ git unstage fileA
$ git reset HEAD fileA[/cc]

Wygląda trochę czytelniej. Równie powszechne jest dodanie polecenia [cc inline=”true” no_cc=”true”]last[/cc]:

[cc lang=”bash”]$ git config –global alias.last ‚log -1 HEAD'[/cc]

Dzięki temu, możesz bardzo łatwo zobaczyć ostatni commit:

[cc lang=”bash”]$ git last
commit 66938dae3329c7aebe598c2246a8e6af90d04646
Author: Josh Goebel
Date: Tue Aug 26 19:48:51 2008 +0800

test for current head

Signed-off-by: Scott Chacon [/cc]

Git po prostu zastępują nową komendę tym do czego utworzyłeś alias. Jednakże, możesz chcieć uruchomić zewnętrzne polecenie. W takim wypadku zaczynamy polecenie od znaku wykrzyknika ([cc inline=”true” no_cc=”true”]![/cc]). Jest to przydatne kiedy piszesz własne narzędzie polecenie pracujące z repozytorium gita. Pokażemy to na przykładzie aliasu [cc inline=”true” no_cc=”true”]git visual[/cc] który uruchamia [cc inline=”true” no_cc=”true”]gitk[/cc].

[cc lang=”bash”]$ git config –global alias.viasul „!gitk”[/cc]

2.8 Podsumowanie

W tym momencie, możesz wykonać wszystkie podstawowe lokalne operacje gita – tworzenie lub klonowanie repozytorium, tworzenie zmian, przechowywanie i commitowanie tych zmian i przeglądanie historii wszystkich zmian które posiada repozytorium. Teraz odkryjemy najwspanialszą cechę gita: gałęzie.

Dodaj komentarz:

 

Subscribe without commenting