Wracamy po przerwie. Będzie kilka słów o schowku w GIT. Z całą pewnością większość z Was pierwsze słyszy o czymś takim. Mi samemu często umyka ta możliwość w systemie. Ale dla zasady warto z tej możliwości korzystać, by zachować porządek i być zadowolonym ze swojej staranności. Pasjonaci są tym zachwyceni.

Powiem szczerze, że zdarza się konieczność pilnych zmian w wydzielonej części repozytorium (praca na innej gałęzi, wyłączenie innej gałęzi, scalanie itd.). Wówczas pracując nad czymś zupełnie innym w trybie pilnym musimy przejść do innego zadania. Cóż robimy?

Wyjście, które najczęściej NIESTETY stosuję to „szybki commit” i praca nad nowym zleceniem. Biję się w pierś. O ile jest to wyjście proste, najszybciej podsuwane przez diabełka żerującego na tempie pracy, o tyle niekoniecznie najlepsze, a skoro nienajlepsze to znajdujemy element do optymalizacji pracy. Najczęściej nie komplikujemy sobie pracy przez „szybki commit”, ale nie zawsze warto „chwalić się” nieprzemyślamymi, nieukończonymi, nietrafionymi rozwiązaniami zastosowanymi w danym tasku, do którego końca (całości lub części) jeszcze zapewne trochę roboczogodzin przed programistą.

W tym momencie przychodzi do łask możliwość korzystania ze schowka w systemie kontroli wersji, jakim jest GIT.

Korzystanie ze schowka

git stash
git stash list
git stash show stash@{x}
git stash apply
git stash apply --index
git stash apply stash@{x} --index
git stash branch
git stash drop stash@{x}
git stash pop
git stash clear

Komenda „stash” jak się pewnie domyślacie wrzuca zmiany do schowka, ale należy pamiętać, że nie dotyczy to plików w stanie „untracked”.

„List” znowuż jest intuicyjna i pozwala prześledzić nasze „stash-commity” w schowku. Posiadają one swoje numerki 0,1,2,..,x, gdzie 0 to ostatnio dodane zmiany do schowka.

Te numerki wykorzystujemy, gdy chcemy prześledzić jakich plików dotyczą konkretne zmiany („stash show stash@{x}”).

Nakładanie zmian ze schowka na obecny stan HEAD odbywa się przy pomocy „stash apply”. Nie podając parametru „–index” powodujemy, że zmiany nie znajdą się w przechowalni i konieczne jest jawne ich dodanie przez „git add …” lub „git commit -a …”. Oczywiście „apply” możemy zastosować do konkretnego „stash-commita”.

Wraz z upływem czasu zmiany w schowku mogą zacząć znacznie się różnić od aktualnego stanu HEAD. Wówczas nałożenie zmian ze schowka może przysporzyć nieco pracy nad rozwiązaniem konfliktów. W skrajnych przypadkach możemy chcieć zrezygnować ze zmian – co tak naprawdę nie jest problemowe, ale powoduje chaos w projekcie. Zakładając od razu możliwość dłuższej integracji schowka z aktualną wersją projektu możemy wykorzystać „stash branch”, czyli komendę, która stworzy nową gałąź, nałoży zmiany i usunie ze schowka. Teraz możemy na wydzielonej gałęzi pracować dalej (nakładać kolejne zmiany lub integrować z projektem).

Przed momentem poruszyliśmy kwestię usuwania nałożonych na projekt zmian ze schowka. Komenda „apply” pozostawia zmiany na liście – zawsze! Musimy jawnie zdecydować (przede wszystkim pamiętać o tym), czy i kiedy je usuniemy (pojedynczo „stash drop …” lub wszystkie „stash clear”).

Gdy często nas pamięć zawodzi warto pomyśleć o stosowaniu komendy „stash pop”. Nakładamy nią ostatnie zmiany ze schowka (pozycja x=0) i automatycznie usuwamy z listy zmian. Gwoli jasności – każde operacji usuwania zmian (konkretnych) z listy zmian wywołują reindeksację listy, przez to „{x}” zawsze rośnie o 1 – nie ma dziur na liście.

Pozdrawiam!