Jogg.About::$Me->RaVbaker

« Hakowanie git-svn aby działał pod Mac OS X Leopard... SEO i bookmarklety »

Praca z Gitem lokalnie a z SVNem globalnie, cz. 2 - uprzyjemnianie pracy

W poprzednim wpisie poruszyłem temat podstawowej migracji na hybrydę: Git lokalnie, SVN zdalnie. W dzisiejszym wpisie czas na nieco bardziej szczegółowe zagłębienie się w niuanse codziennej pracy za Gitem. Spróbuję poruszyć tematy takie jak: ignorowanie plików oraz żonglowanie branchami SVNowymi i ich merge'owanie przy pomocy Gita, oraz jak poskromić nowe komendy Gita nie zapominając tego co się już wie o SVNie.

.svnignore a Git

Prawdopodobnie większość z was wie jak korzystać z plików .svnignore. Git dysponuje dwoma miejscami na owe ignorowane pliki. Pierwszym z nich jest plik .gitignore w głównym katalogu repozytorium. Poszczególne ignorowane pliki są pojedyńczymi liniami. Najprościej migrując z SVNa ustawić nazwę pliku wyłączającego niektóre pliki z śledzenia na już używany przez SVNa .svnignore jeśli takowy posiadamy. Wówczas dane będą wspólne dla obu repozytoriów:

$ git config --add core.excludesfile ".svnignore"

Wynik naszej operacji można zobaczyć w pliku konfiguracyjnym (cat .git/config) lub przy pomocy polecenia git config --get core.excludesfile, a sam plik (.svnignore) normalnie "git add .svnignore" dodajemy do systemu śledzenia wersji, jeśli jeszcze go tam nie ma.

Wspominianą przeze mnie drugą metodą, jest dodanie ignorowanych plików tylko lokalnie. Na swoim komputerze. Robimy tak np. wtedy, gdy pracując na maku nasz komputer tworzy tymczasowe pliki .DS_store. Gdyż wiadomo, że nasz kolega który również pracuje nad tym samym projektem ale z poziomu windows nie ma potrzeby ignorowania tych samych plików. W takim przypadku wystarczy, że my sami sobie lokalnie je zbanujemy. Robi się to za pomocą zupełnie podobnej listy plików (jeden wzorzec, jedna linia), jak ta w .gitignore, z tym wyjątkiem, że jest ona umieszczona w pliku: .git/info/exclude. Wystarczy wyedytować ów plik i zapisać zmiany.

Jest jeszcze jeden sposób na tę czynność. Mianowicie, gdy nasze informacje o ignorowanych plikach są rozproszone pomiędzy katalogi możemy poprosic git-svn aby je odnalazł a następnie dopisać je do listy ignorowanych zmian:

$ git svn show-ignore >> .git/info/exclude

Branche, branche lokalne i branche SVNowe...

Aby zobaczyć branche zaimportowane z SVNa należy spróbować wywołać komendę git branch -r, która pokazuje wszystkie zdalne branche. Po pobraniu projektu przy pomocy "git svn clone" powinny znajdować się tam tylko te pobrane z SVNa. Jeśli widzimy tylko jeden z nich, znaczy to, że w commitach, które Git zaimportował nie znalazła się żadna sygnatura z innego niż bieżący branch. Aby tak się stało musimy po prostu pobrać. Albo liczyć na to, że w którymś z nadchodzących commitów pojawi się odwołanie do jeszcze nieistniejącego brancha (a on zostanie wówczas automatycznie stworzony), bądź też podczas inicjalizowania repozytorium nie tworząc je od początku, a od konkretnej rewizji można podać zakres od której git-svn ma zacząć budować repozytorium. Wówczas zamiast wspomnianego przeze mnie argumentu "-r" będącego numerem rewizji początkowej do "git svn clone" podajemy przedział rewizji w którym znajdzie się również którakolwiek z rewizji jednego z branchy nad którym chcielibyśmy pracować. Zakres podaje się z operatorem ":". Oto przykład:

$  git svn clone -s http://sciezka.do.naszego.repo/svn/ -r19:HEAD

Więc gdy na liście branchy mamy już jakieś zaczerpnięte z SVNa możemy rozpocząć na którymś z nich pracę. Jednak, nie wystarczy po prostu przełączyć się na odpowiedni branch przy pomocy komendy git-checkout, trzeba najpierw stworzyć kopię zdalnego (ang. remote) brancha w naszym repozytorium, a potem się na niego przełączyć. Są na to dwa sposoby:

# pierwszy sposob:

$ git branch lokalny_branch nazwa/brancha_zdalnego
$ git checkout lokalny_branch

#drugi sposob:

$ git checkout -b lokalny_branch nazwa/brancha_zdalnego

Wynik takiej operacji jest identyczny. Tzn. zostajemy przeniesieni do kopii brancha z SVNa, w którym możemy już się zająć pracą dowolnie. Tzn. tworzyć nowe branche, merge'ować kod z innych, commitować pliki i co tylko chcemy. Aktualizacja takiego brancha o nowe dane jest identyczna jak w przypadku każdego innego:

$ git svn rebase

Oczywiście commitowanie, jak zawsze w Gicie nie działa od razu do zdalnego repozytorium w SVNie. Również w tym przypadku trzeba popchnąć commity dalej przy pomocy zwykłego git svn dcommit.

Oczywiście w dowolnej chwili możemy się przełączyć na każdy inny branch lokalny przy pomocy git checkout nazwa_brancha. Tak samo łatwe jest domerge'owanie zmian z innego brancha do tego nad którym aktualnie pracujemy: git merge nazwa_brancha_ktory_domergowujemy. Chciałbym się jednak na chwilę zatrzymać przy tej opcji, gdyż są 3 tryby merge'owania:

• bezpośrednie - jest to standardowe wywołanie git merge nazwa_brancha_z_ktorego_idzie_merge. Co jest ważne, każda zmiana jest po prostu dorzucana taka jaka jest. Czyli każdy commit ląduje w branchu do którego merge'ujemy indywidualnie. Opcjonalnym parametrem jest "--no-commit", które zapobiegnie automatycznemu zacommitowaniu, pozwalając nam na przejrzenie tego co się w kodzie zmieni, zanim całość trafi repozytorium. Z tą opcją merge'owanie jest bardzo zbliżone do tego znanego z SVNa.
• squash - polega na połączeniu wszystkich zmian z brancha w jedne wielki commit, a następnie pozwala ustalić nowy komentarz do commitu i wrzucić wszystkie zmiany. Jak użyć? git merge --squash nazwa_brancha_z_ktorego_idzie_merge. Przydatne np. wtedy, gdy używamy branchy do pracy nad małymi fragmentami naszej pracy. Np. gdy rozwiązując buga tworzymy branch. Wtedy przeniesienie wszystkich zmian w jednym commicie daje nam spójność historii zmian(mam nadzieję, że rozumiecie ;-) ).
• cherry-pick - ostatnia opcja. Najciekawsze w niej jest to, że można merge'ować do brancha pojedyńcze commity. Np. git cherry-pick 321d76f, gdzie 321d76f jest początkiem identyfikatora commitu.

To o czym jeszcze nie mówiłem, to usuwanie i tworzenie branchy w repozytorium SVNowym. Niestety, nie udało mi się w żadnej dokumentacji dokopać do informacji jak usunąć zdalny branch z repozytorium SVNowego z poziomu git-svn. Jedyne na co natrafiłem, to użycie: git branch -D -r nazwa_brancha_do_usuniecia. Powoduje to, że z listy zdalnych branchy znika nam ten który wybierzemy. Jednak, w repozytorium SVN on zostaje. Tak więc użycie tej komendy może tylko powodować jakieś nieścisłości pomiędzy tym co w Gicie a tym co w SVNie. Zdecydowanie nie polecam. Tak więc, do usuwania pozostają domyślne komendy SVNowe w stylu "svn rm ....". Oczywiście lokalne kopie zdalnych branchy możemy usuwać do woli - jak zwykłe Gitowe. Natomiast w kontekście tworzenia branchy, to tutaj jest o wiele prościej. Po prostu komenda: git svn branch nazwa_nowego_brancha_w_svnie. Podobnie jest z tagami: git svn tag nazwa_tagu, tworzy nowy tag w SVNie.

Aliasy na komendy

Pierwszą rzeczą, która mnie w Gicie zdenerwowała po poznaniu, to to, że aby zobaczyć bieżący status zmienionych plików muszę wklepywać całe "git status", zamiast SVNowego "svn st". Na szczęście, jest na to rada. Wystarczy w configu ustawić sobie, że dane słowo stanowi alias dla czegoś co chcemy użyć. Przykład?

$ git config alias.st "status"

Proste prawda? Po zaaplikowaniu takiej komendy słowo "st" stanowi aliast dla "status". Więc, gdy wpiszemy "git st" to tak naprawdę wywołamy "git status". Oczywiście ostatni człon może być nieco bardziej rozbudowany. Np. $ git config alias.mrg "merge moj_glowny_branch". Pozwoli prostym "git mrg" zmergowac konkretny branch, ktory jest pod danym aliasem. Tak jak przy modyfikacji konfiguracji na początku, bieżące zmiany do podejrzenia w pliku ".git/config" w sekcji "[alias]". Jedyne, co może nas jeszcze interesować, to usuwanie gdy dana opcja się już nam znudzi, oraz ustawianie globalnych aliasów dla wszystkich naszych repozytoriów.Zacznijmy jednak od usuwania. Komenda równie prosta, jak dodająca alias:

$ git config alias.st --unset

Natomiast, aby ustawić dany alias globalnie dla wszystkich naszych repozytoriów opartych na Gicie, wystarczy dodać parametr "--global". Podobnie do tego: $ git config --global alias.st "status".

Koniec

Tak, to już wszystkie z bardziej zaawansowanych opcji związanych z przejściem z SVNa na Gita, ale transparentnie. Mam nadzieję, że komuś się to przyda. Ja sam bardzo dobrze się bawiłem ucząc się tych wszystkich smaczków. Liczę, że dzięki mojej pracy i wam będzie się znacznie łatwiej prowadziło wszelkie swoje projekty.

Z okazji dzisiejszego prima-aprilis liczę na wybaczenie wszelkich merytorycznych wpadek. ;-)