Home > programowanie > JGit + EGit = Eclipse Git support

JGit + EGit = Eclipse Git support

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.

  1. Marzec 7th, 2010 at 13:46 | #1

    A co z push i pull? W IDEi obok Commit jest przycisk Commit And Push, ale mimo to ciągle boję się, że któregoś dnia zapomnę „wypuścić” swoich zmian w świat, robiąc przez przypadek „tylko” commit. Może kwestia zmiany nastawienia po latach pracy z SVN?

  2. Marzec 7th, 2010 at 17:41 | #2

    Moim zadniem jest to kwestia wyrobienia sobie nowego nawyku. Takie rozwiazanie (tzn. push i pull + commit) daje wiele mozliwosci, ot chociazby w bardzo prosty sposob mozna zrobic z kumplem code review nie zasmiecajac glownego repo czy tez nie katujac sie patch’ami lub (co gorsza) paczkami z kodem.

  3. catface
    Marzec 10th, 2010 at 22:50 | #3

    Noto chyba zaproszę Cię na wódkę i pokażesz mi jak tego używać gdy Gti jest na serwerze :)

  4. Marzec 10th, 2010 at 22:59 | #4

    @catface
    Po wodce moze byc gorzej z komunikawynoscia … zarowno miedzyludzka jak i miedzy komputerowa ;>

  5. Marzec 11th, 2010 at 08:23 | #5

    Międzyludzką? Ludzko-komputerową to rozumiem, ale międzyludzka zazwyczaj po wódce wydatnie się poprawia :)

    Lock, a nie chciałbyś zrobić prezentacji na JUGa o tym GITcie? Albo Androidzie?

  6. Marzec 11th, 2010 at 09:18 | #6

    @amorfis
    Wszystko w swoim czasie, dopiero co zaczalem uzywac tych dwoch „technologii” … troche musze sie z nimi obyc ;)

  1. Marzec 17th, 2010 at 22:15 | #1