Marioosh's developer diary

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