Wiele już na ten temat zostało powiedziane. Poza tym mówienie i pisanie nie przekonuje tak bardzo jak mogłoby się blogerom wydawać. Sam jestem tego przykładem, gdyż wysiłek poświęcony na wdrożenie i poznanie SVN’a w mojej poprzedniej firmie sprawiał, że nie chciało mi się podejmować kolejnego tylko po to, żeby mieć “fajniejszy” system kontroli wersji.

Jednak wraz ze zmianą pracy zmuszony byłem opuścić niektóre dobrze znane mi rejony. Musiałem poznać GIT’a. Wejście w ten temat miałem łatwe, gdyż infrastruktura już stała (podobna do SVNa z centralnym repo) i z aktywnym wsparciem moich nowych kolegów zacząłem powoli uczyć się nowego systemu.

Nie trwało długo zanim zacząłem swobodnie poruszać się po podstawowych tematach. Zacząłem intensywniej używać branch’y (za co w SVNie bałem się zabrać), jednak najbardziej zakochałem się w poleceniu git stash.

Jest to taki schowek, do którego można wrzucić aktualne zmiany. Może, zamiast zagłębiać się w teorię, opowiem o przypadkach w jakich się przydaje.

Załóżmy, że pracujesz na głównej gałęzi (jesteś zielony i nie przekonałeś się do używania branchy). Masz wprowadzone edycje do kilkunastu plików, aż tu nagle trzeba wprowadzić niecierpiącą zwłoki zmianę do repozytorium. Zmiana jest drobna, ale nie zrobisz ‘push’a z tymi wszystkimi zmianami. Wtedy robisz:

git stash
#znów masz czystą kopię roboczą
#wprowadzasz zmiany
git add .
git commit
git push
git stash pop
#przywracasz swoje zmiany

Pracujesz dalej, aż tu nagle przydałoby się zrobić commit. Jednak boisz się, że sytuacja się powtórzy i coś trzeba będzie wprowadzić do repo i z pushem pójdzie wszystko. Zatem przydałoby się przenieść zmiany do osobnej gałęzi:

git stash
git branch jakas_nazwa_galezi
git checkout jakas_nazwa_galezi
git stash pop
git commit -a

Oczywiście warto zacząć używać gałęzi, gdyż jest to bardzo silne i pomocne narzędzie. Git stash jest tylko małym pomocnikiem do pracy z branchami, ale jakże sympatycznym.

Jeśli do tej pory nie używałeś GITa – spróbuj już dziś, choćby dla zabawy.

O ile nie zacząłeś właśnie wczoraj pracy w branży, pewnie ciągnie się za Tobą kilka projektów. Support to nie jest coś co lubimy najbardziej ;) Nawet jeśli byłeś na tyle sprytny, żeby nie dać się wrobić “rozszerzony support”(o tym poniżej), to i tak zdarzają się błędy w Twoich aplikacjach, którymi musisz się zająć.

Ten ogon może Ci przeszkadzać nieco w aktualnym projekcie…

Potrzeba trochę odwagi, nieco wiary w siebie, aby postawić szefowi lub klientowi granice. Czasem może Ci pomóc Twój team leader, jeśli ma siłę i rozumie problem.

Oto kilka sposobów radzenia sobie z tym tematem (sprawdzone osobiście):

1. wydzielenie konkretnego czasu na pracę z poprawkami
   Pracując do 16, przeznacz ostatnią godzinę na poprawki. Do tego czasu nie zajmuj się nimi. Nie czytaj nawet maili ani ticketów, które dotyczą tego tematu. Zajmuj się najpierw sprawami krytycznymi, które uniemożliwiają pracę Twojemu klientowi. Jeśli jest taka potrzeba, zajmij się ważnymi sprawami następnego dnia od rana. Jeśli trzeba – rozszerz czas do dwóch godzin – bądź elastyczny, ale nie skacz od aktualnego projektu do poprawek i tak kilka razy w ciągu godziny.
2. ustal zakres Twoich obowiązków
   Każdemu z nas zdarzyło się poprawić coś w module firmy trzeciej, bo to była drobnostka. Jednak klient zaczął oczekiwać od nas konserwacji elementów (to jest właśnie “rozszerzony support”), za które nie jesteśmy odpowiedzialni. W tym momencie potrzebna jest szczera rozmowa, pokazanie co zostało zrobione z “dobroci serca” i poinformowanie, że zgłoszenia tego typu mogą zostać odrzucone.
3. zastosuj “warstwę pośrednią”
   Czasem system ciągnący się za nami w ogonie może być nieprzyjemny (odziedziczony po gorszych (oczywiście!) programistach, albo napisany przez nas, gdy byliśmy “mniej doświadczeni”) i sama myśl o tym, że trzeba się w niego zagłębić wywołuje gwałtowne reakcje. Czasem wystarczy, że klient doda w mailu słowo “znów”, albo “ciągle” przed słowami “nie działa’. Wtedy częstą reakcją na to jest gniew, który jest bardzo destrukcyjny – silnie ogranicza nasze zasoby umysłowe, w jednej chwili cofamy się kilka kroków w ewolucji i stajemy małpą, która myśli, że może albo atakować, albo uciekać. Trudno jest programować siedząć na drzewie, gdy gryzą nas pchły. W takich sytuacjach, jako team leader, możesz wystąpić w roli proxy. Spraw, żeby wszystkie maile tego nadawcy przychodziły tylko do Ciebie (albo poproś o to klienta, albo poproś nieszczęśnika o ustawienie filtrów tak, żeby nawet tych maili nie widział). Odsiej z tych maili zbędne epitety i elementy mało ważne, zacznij negocjować kwestie “rozszerzonego supportu”

.

I przede wszystkim naucz się odróżniać rzeczy ważne od reszty. Twoi szefowie (lub klienci) mogą mieć na początku pomysł, że nie lubią jak zacząłeś im odmawiać. Prawdopodobnie polubią to, że zacząłeś być skuteczny…