Część druga (tu jest część pierwsza) HOWTO nt. gita. Opisze podstawowe funkcje i tyowe komendy używane podczas pracy z repo, oraz narzędzia GUIowe do obsługi rep.

To mamy już nasze kochane repo. Nieważne czy jest to nasz własny projekt, czy developujemy już jakiś istniejący projekt. Załóżmy dla przykładu że chcemy napisać patcha do jakiegoś opensourcowego projektu. Zaczynamy więc od sklonowania repo, następnie tworzymy gałąź, która potem użyjemy do zrobienia diffa z masterem i wygenerowania patcha.

<br /> $ git clone git://some.repo/some_project.git<br /> $ git branch uberpatch<br /> $ git branch<br /> master<br /> * uberpatch<br />
Widzimy że są 2 gałęzie i jesteśmy w gałęzi uberpatch. Czas zacząć pisać kod ;]. Po skończeniu dajemy
<br /> $ git add configwatch.pl<br /> $ git commit<br /> [uberpatch bfacadb] comment cleanup<br /> 1 files changed, 0 insertions(+), 2 deletions(-)<br />
można też użyć ***-a ***w commicie, doda to wszystkie śledzone i zmienione pliki, ale żeby dodać nowy plik do projektu trzeba użyć add.  Teraz tworzenie patchu. Wypadałoby żeby patch był zrobiony na podstawie aktualniej wesji repo, więc przełączamy się na mastera i ściagamy ew. aktualizacje
<br /> $ git checkout master<br /> $ git pull<br /> $ git branch<br /> * master<br /> uberpatch<br />
Teraz czas żeby wygenerowac diffa. Dajemy po prostu
<br /> $ git diff master uberpatch<br /> diff --git a/configwatch.pl b/configwatch.pl<br /> index 019fc32..33fdfdb 100755<br /> --- a/configwatch.pl<br /> +++ b/configwatch.pl<br /> @@ -13,8 +13,6 @@ my $db = new Thread::Queue;
<br /> new Thread \&log, $log;<br /> new Thread \&diff, $db, $diff, $notify;<br /> -<br /> -#new Thread \&notify, $notify;<br /> new Thread \&db_save, $db;<br /> new Thread \&rss;
<br /> @@ -24,8 +22,6 @@ foreach (@ARGV) {<br /> }
<br /> while (1) {<br /> -<br /> - # By default this will block until something is read<br /> my @events = $inotify->read();<br /> if ( scalar(@events) == 0 ) {<br /> print "read error: $!";<br /> @@ -50,7 +46,6 @@ while (1) {<br /> }<br /> $diff->enqueue( \%a );<br /> $log->enqueue( \%a );<br /> -<br /> }<br /> }<br />
I mamy patch ;].

Dobra, ale co jak mamy własne repo ? Ano kroki są podobne, tylko zamiast diffa wpychamy zmiany na master server
<br /> $ git push<br /> warning: You did not specify any refspecs to push, and the current remote<br /> warning: has not configured any push refspecs. The default action in this<br /> warning: case is to push all matching refspecs, that is, all branches<br /> warning: that exist both locally and remotely will be updated. This may<br /> warning: not necessarily be what you want to happen.<br /> warning:<br /> warning: You can specify what action you want to take in this case, and<br /> warning: avoid seeing this message again, by configuring 'push.default' to:<br /> warning: 'nothing' : Do not push anything<br /> warning: 'matching' : Push all matching branches (default)<br /> warning: 'tracking' : Push the current branch to whatever it is tracking<br /> warning: 'current' : Push the current branch<br /> Everything up-to-date<br />
He? Wuts that ? Git po prostu nam mówi że domyśnie wrzuci wszystkie gałęzie które istnieja zarówno lokalnie jak i zdalnie. Nie przepadam za domyślnym zachowaniem (bo np. po stowrzeniu nowej gałęzi nie wyśle jej automatycznie) więc ustawie domyślną na “current” (czyli wyślij gałąź w której jestem aktualnie)
<br /> $ git config push.default current<br /> $ git push<br /> Counting objects: 8, done.<br /> Delta compression using up to 2 threads.<br /> Compressing objects: 100% (6/6), done.<br /> Writing objects: 100% (6/6), 562 bytes, done.<br /> Total 6 (delta 4), reused 0 (delta 0)<br /> To ssh://git@devrandom.pl/configwatch.git<br /> * [new branch] HEAD -> uberpatch<br />
Jak widać właśnie wysłałem nową gałąź do serwera. Dobra, skończyłem pracę nad tą gałęzią i chce ją wrzucić spowrotem do mastera. Robię więc:
<br /> $ git checkout master<br /> $ git merge uberpatch<br /> Updating f52c581..37450ad<br /> error: Entry 'configwatch.pl' not uptodate. Cannot merge.<br />
Eep! Coś się źle mergnęło. Zaglądam więc co poszło nie tak przez, poprawiam błędy i commituje
<br /> $ git diff<br /> diff --git a/configwatch.pl b/configwatch.pl<br /> index 019fc32..065fccf 100755<br /> --- a/configwatch.pl<br /> +++ b/configwatch.pl<br /> @@ -14,7 +14,7 @@ my $db = new Thread::Queue;<br /> new Thread \&log, $log;<br /> new Thread \&diff, $db, $diff, $notify;
<br /> -#new Thread \&notify, $notify;<br /> +new Thread \&notify, $notify;<br /> new Thread \&db_save, $db;<br /> new Thread \&rss;<br /> $ emacs configwatch.pl<br /> $ git add configwatch.pl<br /> $ git commit<br />
Gałąż uberpatch nie jest mi już potrzebna więc:
<br /> $ git branch -d uberpatch<br /> $ git push<br /> Counting objects: 10, done.<br /> Delta compression using up to 2 threads.<br /> Compressing objects: 100% (6/6), done.<br /> Writing objects: 100% (6/6), 663 bytes, done.<br /> Total 6 (delta 4), reused 0 (delta 0)<br /> To ssh://git@devrandom.pl/configwatch.git<br /> f52c581..6addf28 HEAD -> master<br />
Dobra, fajnie, da sie używać, tylko pomyliłem się w commicie i co dalej ? Zrobić nowy i wpisać w komentarzu że to poprawki do starego ? Ano nie, wystarczy “zmienić na dobrze”, porobić gid add tego co trzeba i
<br /> $ git commit --amend<br />
Spowoduje to “zmianę” ostatniego commita na to co przed chwilą poprawiliście. Byleby zrobić to przed pushem bo jeżeli nie to już trzeba będzie troche się pobawić. Już nie mówiąc o tym że ktoś może ściągnąć “zły” commit zanim go poprawicie