Marioosh's developer diary

Pracując z Systemem Kontroli Wersji GIT, wyświetlając logi możemy użyć opcji --decorate aby przy każdym commicie była wyświetlana informacja o głowicy (szczyt gałęzi).
W najnowszej wersji GIT’a poprawiono wyświetlanie i teraz gałęzie są w różnych kolorach. Mocno to polepsza czytelność logów.

Kilka miesięcy temu opisałem jak pracować ze zdalnym repozytorium Git. Został tam opisany najprostrzy sposób jak swój projekt umieścić na serwerze.
Jednak gdy chcemy ten projekt współdzielić z innymi programistami możemy napotkać kilka problemów.

Chciałbym jako uzupełnienie tamtego artykułu napisać krok po kroku jak skonfigurować zdalne repozytorium tak aby kilku programistów mogło się z nim łączyć przez ssh.

Czynności, które musimy wykonać po stronie serwera:

• Wybieramy miejsce na repozytorium, np. “/opt/repos/git” i przechodzimy do niego.

  $ cd /opt/repos/git

• Tworzymy grupę systemową ‘git’ i dodajemy do niej użytkowników, którzy mają dostęp do repozytorium
• Zmieniamy uprawnienia plików w ten sposób, aby członkowie tej grupy mieli prawo zapisu we wszystkich podfolderach tego katalogu. Zablokować zapis dla innych.

  $ chmod o-w .
  $ chgrp -R git .
  $ chmod -R g+swX .

• Teraz jeżeli chcemy stworzyć nowe repozytorium, to tworzymy nowy katalog:

  $ mkdir sample.git

• Następnie inicjujemy współdzielone repozytorium:

  $ git init --bare --shared

To wszystko, jak współdziałać z takim repozytorium zostało opisane w tym artykule

Jeżeli chcemy aby użytkownik, który został dodany do systemu, miał możliwość tylko korzystania z repozytorium – chcielibyśmy wyłączyć mu standardowe logowanie to musimy zmienić mu w ustawieniach powłokę z ‘/bin/login’,na ‘/usr/bin/git-shell’ . Taka powłoka pozwoli łączyć się tylko i wyłącznie z repozytorium gita. Próbla zalogowania się do systemu spowoduje wyświetlenie komunikatu:

" fatal: What do you think I am? A shell?"

Udanego gitowania.

Za każdym razem, gdy rozpoczynam pracę z projektem, muszę skonfigurować Git, aby repozytorium nie zawierało zbędnych plików.
Cała operacja jest wykonywana w kilku krokach, gdzie pierwszym z nich będzie stworzenie nowej aplikacji rails na naszym komputerze. Następnie musimy zaiinicjować kontrolę wersji.


$ rails my_app
$ cd my_app
$ git init
$ git status
...
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
# README
# Rakefile
# app/
# config/
# db/
# doc/
# log/
# public/
# script/
# test/
› Continue reading

Jak obiecałem w jednym z poprzednich artykułów opiszę jak wygląda praca z projektem za pośrednictwem zdalnego repozytorium.

Większość projektów nie jest prowadzona samodzielnie, jest w niego zaangażowane kilku (-nastu, -dziesięciu) innych programistów. Każdy z nich może lokalnie prowadzić własną ścieżkę, ale z doświadczenia wiem, że przydaje się jedno wspólne repozytorium. Punkt centralny dla naszej pracy.

› Continue reading

Zgodnie z zapowiedziami projekt DM Server prowadzony przez SpringSourcezostał zmigrowany z Subversion na GIT. Jest to już drugi projekt tej grupy, który przeniósł się na ten system kontroli wersji (pierwszy to Grails). › Continue reading

Na codzień pracuję z IntelliJ IDEA. W tym IDE bardzo podoba mi się funkcja “szufladkowania zmian” podczas pracy z kontrolą wersji. Na codzień korzystam z Subversion i zdarza mi się z tej funkcji skorzystać. Na czym ona polega? Otóż, zdaża się, że pracujemy nad sporym kawałkiem kodu i już dość dużo zmian poczyniliśmy, gdy nagle dostrzeżemy błąd w aplikacji, który chcielibyśmy zmienić, zanim skommitujemy resztę zmian. Powyższa funkcja IntelliJ IDEA pozwala nam na odłożenie dotychczasowej pracy (czyli zmian od ostatniego commita) do szufladki – po czym, możemy poprawić błąd, scommitować zmiany i następnie z szufladki “wyjąć” kod, który napisaliśmy aby kontynuować pracę.

Wielce mnie ucieszyło, gdy zobaczyłem podczas pracy z GIT, że ma on taką funkcję wbudowaną out-of-the-box. Nazywa się ona ‘Stash’.
Wykonuje ona operację dokładnie tak jak opisałem powyżej, czyli…
1. Pracując z dłuższym kawałkiem kodu, mamy już sporo zmian, gdy dostrzegamy błąd aplikacji, który natychmiastowo powinniśmy poprawić.
2. Wykonujemy komendę

 > git stash save "nazwa stasha"

Wykonanie tej operacji zachowa nasze dotychczasowe zmiany gdzieś na boku, a master tree przywróci do stanu HEAD.
3. Możemy poprawić nasz błąd i wykonać commit

 > git commit -a -m "bugfix #2382

4. Przywracamy stan poprzedni, aby kontynuować pracę:

 > git pop

co jednocześnie usunie naszą “szufladkę”, jeżeli nie chcemy usuwać aby móc do tego stanu jeszcze wrócić wykonujemy komendę :

 > git apply

5. Kontynuujemy pracę.

Git Stash ma więcej możliwości, bo takich wirtualnych szufladek możemy tworzyć dowolną ilość i przywracać stan z każdej z nich. Możemy zatem poprogramować w stylu “co by było gdyby…” i wybrać najbardziej odpowiednią wersję napisanego kodu (dotyczy to zwłaszcza młodych programistów, którzy niejednokrotnie nie są pewni podejmowanych decyzji w programowaniu).

Młody czy stary programista – polecam GIT i funkcję stash.

Więcej o tej komendzie znajdziecie tutaj.

W związku z tym, że ostatnio coraz częściej korzystam z systemu kontroli wersji GIT (zamiast używanego przez kilka ostatnich lat Subversion) postanowiłem napisać kilka słów na jego temat. › Continue reading