Dariusz [LocK] Łuksza

Jakiś czas temu projekty jgit (czyli implementacja git‘a w java’ie) oraz egit (plugin do eclipse’a dodający wsparcie dla git’a) znalazły się w inkubatorze fundacji Eclipse. Dawno temu wyczytałem nawet, że git ma zastąpić CVS‘a na miejscu domyślnego systemu kontroli wersji w IDE … ale zanim to nastąpi upłynie pewnie jeszcze sporo czasu … nie mniej jednak już teraz można podejrzeć jak się mają rzeczy, co też właśnie w uczynię .

Może na początek kilka numerków 3.5.2 oraz 0.6.0.201002030558, nie nie są to numery dużego lotka . Pierwszy oczywiście opisuje aktualną wersje stabilną Eclipse, drugi zaś jest numerem wersji egit/jgit.

Pierwotnie stroną domową obu projektów było jgit.org (tutaj też znajduje się update site dla eclpse‘a) ale po przejściu projektu pod skrzydła Eclipse Fundation dostępne są dwie stronki eclipse.org/egit/ oraz eclipse.org/jgit/ na obu w sekcji download znajdziemy ten sam link do update site’u:

http://download.eclipse.org/egit/updates

Ja używam ciągle starego update site‘u:

http://www.jgit.org/updates

Z tego co sprawdziłem to podana wcześniej wersja jest dostępna tylko w drugim repo, możliwe że jest to jakiś nightly build czy coś “nie stabilnego” … nie wiem, u mnie działa ;>

W tym wpisie chciał bym omówić jak “podłączyć” nowy projekt pod git SCM (zakładając, że wcześniej nie współdzieliliśmy go w żadnym SCM‘ie). Jeżeli chodzi natomiast o dodanie istniejącego już projektu podpiętego pod jakieś git‘owe repo to robi się to przez File -> Import, nie ma do tego nowej perspektywy wszystko robią wizard‘y.

Tak więc dla przykładu zakładamy sobie nowy projekt GitTest, dodajemy tam jedną klasę Main z “standardowym”

System.out.println("Hello git!");

Następnie na tak spreparowanym projekcie klikamy prawym myszy i wybieramy po kolei Team -> Schare Project… z dostępnej listy oczywiście wybieramy git. Jeżeli plugin znajdzie w jakimś katalogu nadrzędnym katalog .git (czyli miejsce gdzie git przechowuje swoje metadane) to zasugeruje podpięcie się pod już istniejące repo. W moim przypadku taka sytuacja nie występuje.

Zaznaczmy nasz projekt, klikamy w Create Repository, następnie w Next i oto wykonaliśmy odpowiednik git init … sam nie wiem co jest prostsze, chyba jednak wolał bym to zrobić z “palca”.

Skoro już zainicjalizowaliśmy nasze repo trzeba by je czymś wypełnić, czyli wykonać odpowiednik git add. Spokojnie, wszystko można wyklikać tak wiec zaczynajmy klikać ;>. Parawym myszy na pliku/katalogu który chcemy dodać (w moim wypadku jest tylko jeden katalog src) i poklei Team -> Add to version control.

Kolejny krok to git commit. Znowu to wyklikamy ;> Team -> Commit. Możemy teraz dodać komentarz do commit‘a jak również odznaczyć pliki które nie chcemy dodać do repo. Po kliknięciu w Commit nasze zmiany zostaną zapisane w repozytorium.

Jako że przez pomyłkę na dodałem cały projekt do commita (Team -> Add to version control) również “nie chciane pliki” takie jak .setting, .classpath oraz .project dodały się co commit‘a. W takim wypadku odpalamy widok Navigator i na każdym takim pliku wykonujemy po kolei operację Team -> Remove from version control, Team -> Add to .gitignore. Tak powstały plik .gitignore dodajemy do git‘a i commit‘ujemy (czyli: Team -> Add to version control, Team -> Commit).

Pora zrobić coś bardziej szalonego … zmieńmy zawartość Main.java ! Żeby za bardzo nie szaleć ja dodałem dodatkowy wykrzyknik na końcu “Hello git!” ;>. Zapisujemy zmiany. Eclipse automatycznie (podobnie z resztą jak to ma miejsce podczas korzystania z CVS‘a) informuje nas o tym, że względem repozytorium nasz plik jest zmieniony. Jak sprawdzić zmiany ? Nie ma czegoś takiego jak Synchronize with repository … ale jest za to: Compare with -> Git index. Moje „szalone zmiany” są widoczne jak na dłoni … albo jak kto woli “jak na CVS’ie”

Niestety na chwilę obecną nie dopatrzyłem się żadnych możliwości porównania całego projektu, jak to jest możliwe w CVS’ie. Trzeba porównywać każdy plik z osobna … jest to trochę męczące ale mam nadzieje, że w kolejnych wydaniach taka funkcjonalność zostanie “jakoś” zaimplementowana oraz dodana.

Po sprawdzeniu jakie zmiany, względem repo, wprowadziliśmy w naszym projekcie możemy śmiało wyklikać Team -> Commit na naszym zmienionym pliku. W ten sposób moje repo zawiera już 3 commit‘y ;>

Może teraz sobie po-branch‘ujemy. Prawie standardowo klikamy na projekt i wybieramy Team -> Branch… wyskakuje nam okienko w którym możemy dodać nową gałąź, zmienić jej nazwę oraz przełączyć się na wybraną gałąź. Aktualna gałąź jest pogrubiona oraz dodatkowo oznaczona przypisem (current). Klikamy w New branch nazwa jest praktycznie dowolna, ja nazwałem nowy branch jako “awesome-changes” , akceptujemy zaznaczamy nowo dodany branch i klikamy Checkout, żeby się na niego przełączyć. Prawda, że proste ?

Teraz jeżeli klikniemy na projekt prawym myszy i z menu wybierzmy Team -> Show in Resource History widzimy historię zmian w naszym projekcie.

Niestety na chwilę obecną plugin nie pozwala merge‘ować branch‘y … szkoda, trzeba to robić ręcznie z linii poleceń czyli git merge <target> <source>.

Dostępna jest natomiast opcja nadpisywania poczynionych zmian. Przez Team -> Reset można wykonać reset wprowadzonych zmian do poziomu w wskazanej gałęźi.

To tyle mojego małego przeglądu, więcej informacji można znaleźć w User Guide EGit‘a.

Prace nad programem do inżynierki zaszły już tak “daleko”, że wypadało by gdzieś ten kod przetrzymywać dla bezpieczeństwa. Dobrym dodatkowym feature’m byla by też możliwość jego wersjonowania … jako, że jakiś temu postawiłem sobie własne repo git’a (dwie (1, 2) z zamierzonych trzech części opisu instalacji zostały już opublikowane) wybór był oczywisty.

Początkowo zadanie wydawało się bardzo banalne … dodać repozytorium do gitosis i wszystko powinno się zrobić automatycznie … cóż tak niestety nie było. Dla potomności (oraz mojej często wątpliwej pamięci) postanowiłem opisać całą procedurę.

Będzie do tego potrzebna nam konfiguracja gitosis. Jako że jest ona przetrzymywana jako jedno z repozytoriów nie powinno być żadnych problemów z jej uzyskaniem. Tak więc jeżeli nie mamy już jakiejś kopi na dysku wywołujemy komendę:

git clone ssh://gitosis@server.z.gitem.org/gitosis-admin.git

Następnie edytujemy plik gitosis.conf w którym odajemy nowe repo:

[repo nazwa-nowego-repo]
owner = joe
description = opis

No i niby wygląda na to, że to wszystko … niestety nie jest tak łatwo, z tego co doświadczyłem to  gitosis wymaga, żeby każde repo posiadało osobną grupę o tej samej nazwie (możliwe, że można to jakoś przekonfigurować ale ja nie znalazłem takich informacji). Więc nie pozostaje nam nic innego jak dodać kolejną grupę:

[group nazwa-nowego-repo]
owner = joe
writable = nazwa-nowego-repo
members = joe

Zapisujemy zmiany i za pomocą git push wypychamy je na serwer … no to konfiguracje gitosis mamy za sobą. Teraz zostało nam jeszcze utworzyć repo ;>

Tak więc w lokalnym systemie tworzymy sobie nowy katalog albo wchodzimy do katalogu projektu który chcemy wrzucić do repo, w środku wywołujemy git init, następnie przy użyciu git add dodajemy wszystkie pliki do commit’a. Potem commit’ujemy zmiany do lokalnego repo (git commit -m “initial commit”) … no i teraz najważniejsze, dodajemy nasze zdalne repo:

git remote add dowolna-nazwa-repo ssh://gitosis@server.z.gitem.org/nazwa-nowego-repo.git

i tryumfalnie wypychamy wszystko na serwer

git push dowolna-nazwa-repo --all

To tyle, wszystko powinno działać … przynajmniej na razie u mnie działa ;>

Dziś lub jutro dodam wpis odnośnie aktualnego stanu wtyczki dodającej obsługę git’a dla Eclipse będzie to bardzo szybkie overview funkcjonalności których do tej pory użyłem/używałem.

UPDATE:
Wpis o git’cie i eclipse jest prawie gotowy, zostało mi jeszcze opisać branche’owanie, merge’owanie, push’owanie oraz pull’owanie i wstawić screenshot’y

UPDATE2:
Dziś git też mnie pokonał … okazało się, że aktualnie plugin nie wspiera merge’owania branche’y, a push’owanie i fetch’owanie jest zbyt skomplikowane żeby opisywać je w jednym wpisie (zwłaszcza jeżeli nie ma się z tym zbyt wiele doświadczenia). Postaram się skończyć wpis jutro (zapamiętać: jutro nigdy nie umiera ) i go opublikować.

W poprzednim poście de facto mało zajmowaliśmy się git’em … szczerze powiedziawszy to skonfigurowaliśmy tylko lighttpd które to później będzie nam potrzebne do uruchomienia cgit‘a czyli interfejsu www w którym będziemy mogli obejrzeć sobie nasze repo. Dziś za to zajmiemy się instalacją i konfiguracją gitosis.

Czym jest gitosis i o czego będzie nam potrzebne?

Cóż, podobnie jak sam git, gitosis jest zestawem skryptów ułatwiającym prace z repozytorium. Zestaw tych skryptów odpowiedzialny jest za kontrolę dostępu do repo jak i za sam dostęp do niego.

Jak działa gitosis?

“Integruje” się ono z serwerem SSH, “integruje się” to za wiele powiedziane, bo sshd wykorzystywane jest tylko do autoryzacji użytkowników oraz transferu danych z i do repo. Samo gitosis nie uruchamia dodatkowego daemona, jak już wspomniałem korzysta z sshd.

Jak przebiega proces autoryzacji ?

Podobnie jak w GitHub‘ie najpierw trzeba dodać nasz klucz publiczny, żebyśmy mogli zostać z autoryzowani, następnie przy każdej próbie połączenia z repo będzie on wykorzystywany do przeprowadzenia autoryzacji … nie ma w tym żadnej wielkiej filozofii, dorzycamy nasz klucz i wszystko po prostu działa.

Ok, więc może w końcu do sedna … zaczynamy od zainstalowania pakietu gitosis w systemie:

apt-get install gitosis

Proces instalacji sam utworzy w systemie konto użytkownika (standardowy login to gitosis), założy mu katalog domowy (standardowo: /srv/gitosis). Jeżeli bardzo chcemy to możemy to zmienić korzystając ze standardowej komendy usermod dla uproszczenia ja będę się posługiwał standardową nazwą użytkownika. Pozostaje nam tylko inicjalizacja i konfiguracja:

sudo -H -u gitosis gitosis-init < id_rsa.pub

Gdzie id_rsa.pub jest naszym kluczem publicznym używanym przez naszego klienta ssh … fajnie to brzmi ale co to właściwie jest ? Dokładny opis jak taki klucz sobie wygenerować (i co z nim zrobić) znajduje się tutaj. Generalnie powinien być to klucz który będzie identyfikował naszą maszynę z której będziemy się łączyć do repozytorium (tj. klucz prywatny i publiczny powinny być zapisane w katalogu ~/.ssh na twoim desktopie/laptopie, tylko klucz publiczny w celu instalacji go w konfiguracji gitosis powinieneś skopiować na serwer na którym instalujesz repozytorium). Powyższa komęda powinna zainicjalizować repozytorium git/gitosis oraz dodać wskazany klucz publiczny jako klucz administratora. Jeżeli mamy szczęście to po wykonaniu poniżeszej komędy na naszym desktopie/laptopie (tj. na tym na którym znajduje się para ~/.ssh/id_rsa i ~/.ssh/id_rsa.pub):

git clone gitosis@adres_serwera:gitosis-admin.git

Jeżeli powyższa komenda nie wykona się poprawnie (jak to było w moim przypadku) zmuszeni jesteśmy skonfigurować gitosis ręcznie. W tym celu udajemy musimy przeedytować plik /srv/gitosis/.ssh/authorized_keys (tak wiem, że nie powinno się go edytować … ale co nam pozostaje ?) i zmienić “domyślny” login na identyczny z tym podanym w komentarzu do naszego klucza prywatnego (to jest to co podaliśmy za przełącznikiem -C podczas jego tworzenia), wartość klucza publicznego (to jest ten dziwny ciąg znaków za ssh-rsa) oraz na samym końcu ponownie wstawiamy wartość z naszego komentarza. Po wykonaniu tych zmian i ich zapisaniu ponownie próbujemy sklonować repozytorium z konfiguracją (czyli jeszcze raz wydajemy poprzednią komendę) … jeżeli znowu nie wykona się poprawnie … cóż czasem trzeba sobie radzić samemu

Ok, zakładam że w końcu uda się pobrać z serwera konfigurację z serwera … tak, na prawdę gitosis przechowuje swoją konfigurację w formie jednego z repozytoriów. Jest to dość wygodne, gdyż nie wymusza na nas logowania się na serwer celem zmiany konfiguracji (w wypadku dodania użytkownika repozytorium, czy też nowego projektu). W każdej chwili możemy sobie ta konfigurację pobrać, zmodyfikować, “wepchnąć” z powrotem i usunąć jak dla mnie bomba .

Co do samej konfiguracji to składa się ona z 2 rzeczy:

• pliku z konfiguracją (znajdują się tam definicje repozytoriów, grup i praw dostępu)
• katalogu z kluczami publicznymi użytkowników

W katalogu keydir/ znajdują się klucze publiczne użytkowników, w postaci:

uzywany_login.pub

najczęściej login ma postać adresu email, więc przykładowy plik dla użytkownika wlodek@luksza.org będzie się nazywał wlodek@luksza.org.pub … jest to niezmiernie skomplikowane, nieprawdaż

W przypadku kiedy chcemy dodać nowego użytkownika bądź repozytorium musimy przeedytować plik gitosis.conf, jego opis można znaleźć tutaj. W przypadku użytkowników należy pamiętać o zgodności nawy użytkownika z nazwą pliku zawierającą jego klucz publiczny. Dodatkowo warto wspomnieć o tym, że dla każdego repozytorium możemy zdefiniować właściciela (parametr owner ) oraz opis (description), są to przydatne parametry zwłaszcza podczas eksploracji repozytorium przy użyciu cgit‘a czy też gitweb‘a.

Kiedy już wykonamy wszystkie zmiany commit’ujemy je do lokalnego repo, a potem wypychamy do głównego:

git commit -a
git push

W ten prosty sposób administrujemy repozytorium git’a zarządzanym przez gitosis

BTW. Chyba szykuje się nam zmiana na miejscu domyślnego repo Eclipse Fundation możliwe, że nowe repo będzie obsługiwane przez git’a, “pierwsze” takie przesłanki można znaleźć tutaj.

Jakiś czas temu pisałem jak za pomocą git’a i pendirve’a można w łatwy sposób zabezpieczyć się przed utratą projektu. Dziś przedstawię bardziej skomplikowane podejście, a mianowicie postawimy repozytorium git’a na serwerze. W moich założeniach takie repozytorium nie będzie dostępnie publicznie (w przeciwieństwie do rozwiązania jakie na starcie proponuje GitHub; mają też rozwiązanie płatne w którym to możemy mieć  prywatne repo, ale ja wole mieć je u siebie ).

Moje oczekiwania od takiego repo są następujące:

• dostępność do repo z każdego zakątka świata (czyli serwer musi być dostępny szeroko pojętej sieci)
• możliwość dostępu do repo tylko dla wybranych użytkowników
• możliwość przeglądania repo z poziomu www
• bezpieczeństwo stosowanego rozwiązania (https, ssh)

Jakie wybrałem oprogramowanie ?

• systemem bazowym będzie Debian (znany, lubiany i standardowy linux)
• gitosis (prosty soft do hostowania repozytorium git’a z równie prostą kontrolą dostępu, IMO rozwiązanie w sam raz do moich potrzeb)
• lighttpd (mały i szybki httpd)
• mod_ssl oraz mod_auth do wyżej wymienionego httpd
• cgit odpowiednik gitweb’a ale moim zdaniem ładniejszy i bardziej przejrzysty

We własnym zakresie trzeba zadbać o system bazowy, oraz jego konfigurację . Zakładam, że Debian jest już zainstalowany, skonfigurowany, zabezpieczony oraz podpięty do sieci.

Zaczynamy od instalacji i konfiguracji lighttpd

apt-get install lighttpd apache2-utils

Pakiet apache2-utils będzie nam potrzebny do wygenerowania hash‘a hasła potrzebnego do mod_auth (swoją drogą system pakietowania debiana coraz bardziej mnie zadziwia … nie rozumiem po co w zależnościach do tego pakietu znajduje się libmysqlclient …). Po zainstalowaniu włączamy dwa interesujące nas moduły:

lighttpd-enable-mod auth
lighttpd-enable-mod ssl

Oraz przechodzimy do konfiguracji zarówno httpd jak i modułów. Zaczniemy od mod_auth, czyli edytujemy pliczek /etc/lighttpd/conf-enabled/05-auth.conf, w którym to wybieramy backend (czyli algorytm szyfrowania haseł oraz miejsce ich zapisu) oraz konfigurujemy miejsca do których dostęp będzie strzeżony hasłem. Po modyfikacjach plik konfiguracyjny powinien wyglądać mniej więcej tak:

## Authentication for lighttpd
##
## Documentation: /usr/share/doc/lighttpd-doc/authentication.txt.gz
##                http://www.lighttpd.net/documentation/authentication.html
server.modules                += ( "mod_auth" )
# htdigest jest najmocniejszym dostepnym "algorytmem" szyfrujacym
auth.backend                   = "htdigest"
auth.backend.htdigest.userfile = "/etc/lighttpd/lighttpd-htdigest.user"
 
auth.require                 = ( "/" =>
                                     (
                                       "method"  => "digest",
                                       "realm"   => "secure content",
                                       "require" => "valid-user"
                                      )
                                )

Opcja auth.require zawiera tylko jeden element, którym jest root serwera httpd, czyli dostęp do dowolnego pliku na serwerze będzie chroniony hasłem. Warto tutaj wspomnieć, że hash hasła zostanie posolony wartością w realm, dzięki temu uzyskujemy prosty mechanizm kontroli dostępu (tj. gdybyśmy mieli dwa zasoby z różnymi wartościami w realm, każdego użytkownika który powinien posiadać dostęp do obu powinniśmy dodać osobno). Teraz wystarczy tylko dodać użytkownika:

htdigest -c /etc/lighttpd/lighttpd-htdigest.user 'secure content' user_name

Po wydaniu tej komendy zostaniemy poproszeni o podanie oraz potwierdzenie hasła dla tego użytkownika.

Po skonfigurowaniu mod_auth przechodzimy do konfiguracji mod_ssl, w tym celu edytujemy /etc/lighttpd/conf-enabled/10-ssl.conf. Ja zdecydowałem się udostępniać usługę http tylko na porcie 443 z szyfrowaniem (czyli popularny https ), więc w konfiguracji mod_ssl wskazałem na którym dokładnie adresie IP oraz na jakim porcie ma nasłuchiwać daemon; plik konfiguracyjny wygląda mniej więcej tak:

## lighttpd support for SSLv2 and SSLv3
##
## Documentation: /usr/share/doc/lighttpd-doc/ssl.txt
##      http://www.lighttpd.net/documentation/ssl.html
 
#### SSL engine
$SERVER["socket"] == "111.222.3.4:443" {
ssl.engine                  = "enable"
ssl.pemfile                 = "/etc/lighttpd/server.pem"
}

następnie generujemy certyfikat self-signed dla naszego serwera:

openssl req -new -x509 -keyout server.pem -out server.pem -days 365 -nodes

Który to kopujemy do /etc/lighttpd/server.pem.

Ostatnią częścią konfiguracji lighttpd będzie ogólna konfiguracja serwera, czyli edytujemy plik
/etc/lighttpd/lihttpd.conf. W którym to odkomentowujemy tylko linie:

server.bind = "localhost"

Spowoduje to, że port 80 zostanie otwarty tylko na interfejsie loopback, co w konsekwencji prowadzi do tego, że wszystkie połączenia (z sieci) do portu 80 będą odrzucane (za to akceptowane będą połączenia do portu 443, zgodnie z konfiguracją w pliku 10-ssl.conf).

Na razie to wszystko w kwestii konfiguracji lighttpd, wrócimy jeszcze do niej podczas konfiguracji cgit’a. W następnej części zajmiemy się konfiguracją gitosis.

PS. Tutaj jest część druga.

Konia z rzędem temu kto potrafi zmusić GIT’a do generowania patch’y kompatybilnych z SVN’em (a zwłaszcza z TortoiseSVN) !

Jeżeli nie uda się mi zmusić GIT’a do tego żeby wygenerował patch’e zgodne z SVN niestety będę musiał zakończyć w Summer of Code ‘09 przygodę z GIT’em … na prawdę będzie mi z tego powodu przykro

Oto prosty sposób na przeniesienie repozytorium GIT na pendrive, czy inną przenośna pamięć.

1. Dla uproszczenia dodamy sobie nasze wymienne repozytorium do pliku /etc/fstab w tym celu:

   ls -l /dev/disk/by-uuid # odnajdujemy na liście nasz urządzenie,
   w moim przypadku sdb1
   mkdir /mnt/git-gsoc # tworzymy odpowiedni katalog do montowania
   chown lock:lock /mnt/git-gsoc # zmieniamy właściciela

   przy użyciu ulubionego edytora edytujemy /etc/fstab. Dodajemy następującą linie:

   UUID=<uuid z pierszego polecenia> /mnt/git-gsoc	<system plików> user,rw,noauto 0 0

2. Teraz przydało by się zawartość naszego obecnego repo przenieść do nowego …  wystarczy skopiować główny katalog repozytorium (prostota git’a)

Mając już sklonowane repozytorium przydał by się jeszcze jakiś skrypt który za nas wykona zbędne rzeczy (tj. podmontuje pamięć, odpali git-deamon, a potem po sobie posprząta ).

#! /usr/bin/bash
# Copyrighted, 2009
# Developed by Dariusz Luksza <dariusz[at]luksza[dot]org>
# License: GPL v2
 
case "$1" in
connect)
	echo -n Montuje urzadzenie ...
mount /mnt/git-gsoc &> /dev/null
if  [ "$?" -eq "0" ]
then
		echo " DONE."
		echo -n Startuje git gaemona ...
		git daemon --export-all --base-path=/mnt/git-gsoc/backup --detach \
			--pid-file=/mnt/git-gsoc/git-daemon.pid --enable=receive-pack --listen=localhost
		echo " DONE."
exit 0
else
		echo Wystapil blad podczas montowania, sprawdz urzadzenie!
exit 1
	fi
	;;
disconnect)
if [ -e /mnt/git-gsoc/git-daemon.pid ]
then
		echo -n Zatrzymuje git daemona ...
kill `cat /mnt/git-gsoc/git-daemon.pid`
rm /mnt/git-gsoc/git-daemon.pid
		echo " DONE."
		echo -n Odmontowuje urzadzenie ...
sync
		umount /mnt/git-gsoc/
		echo " DONE."
exit 0
else
		echo Daemon nie zostal uruchomiany
		exit 1
	fi
	;;
*)
	echo Uzycie:
	echo "    " $0 "[connect|disconnect]"
	;;

Oczywiście każdy sam musi sobie dostosować ścieżki dostępu

Kiedy mamy już wszystko poustawiane warto by sprawdzić czy wszytko działa poprawnie tj. uruchamiamy powyższy skrypt z parametrem connect i po chwili powinniśmy mieć uruchomionego daemona GITa. Teraz wystarczy do naszego lokalnego repozytorium dodać to które właśnie utworzyliśmy:

git remote add backup git://localhost/<nazwa repo>

i używać uchwytu backup

Miłej zabawy ;>