Tworzymy moduł: praca z gitem

PsLogoKorzystając z PowerShella na co dzień na ogół nie musimy przejmować się tym, jak wygląda tworzony przez nas kod. Nawet proste skrypty na upartego możemy wykorzystywać nie myśląc nawet o systemie kontroli wersji. Jeśli jednak zamierzamy tworzyć moduł, to niestety (a może stety?), bez tego rodzaju narzędzi nie ma raczej sensu kontynuować. Jest to jeszcze istotniejsze wtedy, gdy zamierzamy współtworzyć moduł: możliwość zadbania o to, by poprawiając nasz kod nie cofnąć poprawek koleżanki/kolegi, staje się jeszcze ważniejsze.

Ale nawet jeśli nad modułem pracujemy samodzielnie, to często będzie nam potrzebna możliwość „zapisania” naszego kodu po to, by jednocześnie dokonać zmian najpilniejszych. Zwykle bowiem nowe możliwości mają niższy priorytet, niż naprawianie poważnych usterek w naszym kodzie, które mogłyby doprowadzić do błędnego jego działania. Ponieważ większość projektów związanych z PowerShellem zarządzanych jest przy pomocy gita, to tego narzędzia właśnie użyjemy i w naszym projekcie.

Gałęzie

W poprzednim artykule stworzyliśmy już repozytorium, w tym spróbujemy wykorzystać jego możliwości do tego, by wprowadzać zmiany w sposób kontrolowany. Pierwszym krokiem, zaraz po utworzeniu repozytorium, powinno być zwykle utworzenie gałęzi, na której będziemy dokonywać zmian. Gałąź domyślna (master) na ogół traktowana jest jako miejsce przechowywania kodu gotowego, nadającego się do uruchamiania na produkcyjnych serwerach. Na początku skorzystaliśmy z tej gałęzi tworząc szkielet naszego modułu. Jeśli jednak zamierzamy pisać funkcje, to warto przenieść dalsza pracę do odrębnej gałęzi.

Gałąź możemy utworzyć na kilka sposobów. Osobiście preferuję wykorzystanie do tego celu polecenia git checkout:

git-checkout

Zaleta tego rozwiązania to przeniesienie się na nowoutworzoną gałąź, więc od razu możemy zacząć tworzyć nasz kod.

Odnośnie nazwy gałęzi: istnieje wiele szkół, na ogół połączonych z całym procesem, jakiego należałoby używać w trakcie z korzystania z nich (jak GitFlow). Osobiście nigdy nie zdecydowałem się na ścisłe stosowanie do którejkolwiek z nich. Zwykle po prostu umieszczam moje imię z opisem danej gałęzi. Może być to hasłowy opis (jak ‚pierwszaFunkcja’ widoczny powyżej). Na ogół umieszczam jednak ID w ramach systemu takiego jak JIRA.

Zatwierdzanie kodu

Tworzymy nowe pliki, dopisujemy treść do plików już istniejących czy usuwamy pliki, które nie będą nam dłużej potrzebne. W końcu: zatwierdzamy zmiany przy pomocy git commit. I tu może pojawić się pierwszy zgrzyt (zwłaszcza jeśli korzystamy ze starszej wersji gita i nie podaliśmy opisu zmian):

commit-i-vim

Mamy więc dwie możliwości: opanować podstawy vima, skonfigurowanie innego edytora bądź zadbanie o opis zmian w linii poleceń.

W przypadku przeprowadzanej operacji zatwierdzania zmian to pierwsze nie jest skomplikowane: wystarczy wiedzieć, jak przejść do trybu edycji (klawisz ‚i’, jak insert, bądź ‚a’ – append) i jak zapisać plik (ESC by wyjść z trybu edycji, :wq), bądź po prostu wyjść z edytora (:q!).

Nie da się ukryć, że użycie linii poleceń będzie jednak prostsze: pamiętać musimy jedynie o podaniu parametru -m i odpowiedniego ciągu znaków.

Ostatnia opcja oferowana jest nam obecnie w trakcie instalacji gita, ale sami też możemy ją ustawić przy pomocy polecenia git config:

$notepad = 'C:/Program Files (x86)/Notepad++/notepad++.exe'
$opcje = '-multiInst -notabbar -nosession -noPlugin'
git config --global core.editor "'$notepad' $opcje"
git commit
# Startuje notepad++ z możliwością uzupełnienia wiadomości
view raw notepadEdit.ps1 hosted with ❤ by GitHub

Oczywiście, nie musimy wybierać notepad++ – jeśli wolimy inny edytor, to musimy po prostu zmodyfikować parametry polecenia git config. Dla przykładu, jeśli zechcemy skorzystać z Visual Studio Code i zainstalowaliśmy tę aplikację z opcją „dodaj do ścieżki”, to konfiguracja wymaga nieco prostszej składni:

git config --global core.editor "code --wait"
view raw codeEdit.ps1 hosted with ❤ by GitHub

Kod zatwierdzony, pora przesłać go na serwer.

Podaj dalej

Zatwierdziliśmy zmiany w kodzie, ale póki co pozostają one jedynie na naszym komputerze. Oznacza to, że jeśli padnie nam dysk, ktoś „pożyczy” naszego laptopa czy zwyczajnie w trakcie czyszczenia dysku usuniemy troszkę za dużo wynik naszej pracy przepadnie bezpowrotnie.

Jak się tego ustrzec? Oczywiście, przesłać nasze zmiany na serwer! Posłuży nam do tego polecenie git push. Zanim jednak prześlemy dane na serwer warto zadbać o pewien element konfiguracji. Wygodniej bowiem przesyłając zadbać o to, by gałąź zdalna była przez naszego gita „śledzona”. W ten sposób będziemy mieli informację o tym, jak bardzo nasza lokalna gałąź różni się od zdalnej.

Zwykle korzystam w tym celu z ustawienia opcji push.default to current, oraz z polecenia git push -u. Alternatywnie możemy podać docelową gałąź na zdanym serwerze korzystając z parametru –set-upstream polecenia git push:

# Jeśli chcemy zawsze "przesyłać" na gałąź o tej samej nazwie
git config --global push.default current
git push -u
# Alternatywnie, ustawiamy upstream na piechotę...
git push --set-upstream origin nazwaZdalna
view raw gitPush.ps1 hosted with ❤ by GitHub

Efekt finalny będzie taki, że jeśli pojawią się nowe zmiany w naszej lokalnej kopii, to będziemy mogli zauważyć tę różnicę:

git-pusz-ten-kod

Ostatni krok to moment, gdy skończyliśmy pracę nad kodem i chcemy go dołączyć do produkcyjnej wersji naszego modułu. Temu posłuży tak zwany „pull request”.

Łączymy gałązki

Po wytężonej pracy przychodzi wreszcie czas na zebranie owoców. Nasz kod został napisany, pierwsza funkcja jest już w zasadzie gotowa, chcielibyśmy dodać ją do tworzonego przez nas modułu. Co w tej sytuacji powinniśmy uczynić?

Na upartego gałęzie łączyć możemy lokalnie, bez żadnej kontroli, a następnie przesyłać zmiany z naszego komputera na gałąź master. Wadą tego rozwiązania jest to, że tracimy możliwość sprawdzenia, co tak naprawdę uległo zmianie.

O wiele lepszym rozwiązaniem jest skorzystanie z funkcjonalności, którą oferują wszystkie narzędzia „opakowujące” gita w wygodne GUI: pull request (wybaczcie, nie podejmę próby tłumoczenia tego na naszą piękną mowę Winking smile). Jest to funkcjonalność, dzięki której możemy poprosić o zmiany w produkcyjnym kodzie oferując przygotowane przez nas uprzednio zmiany. Zwykle (w większych organizacjach) taka zmiana wymaga kontroli innego członka zespołu. Bywa, że dodatkowo przeprowadzane będą automatycznie testy, by sprawdzić, czy kod działa poprawnie (do testów wrócimy w jednym z przyszłych artykułów). Zmiana będzie mieć swój tytuł, opis, sprawdzających, zmiany w kodzie. Zwykle do zmian dodawać można komentarze, nierzadko skutkujące dodatkowymi zmianami. Jakie są z tego korzyści? Przytoczę tylko kilka:

  • większa kontrola nad produkcyjnym kodem
  • jeśli kod opisuje nasze systemy, zyskujemy swoiste narzędzie do kontroli zmian w środowisku produkcyjnym
  • uczymy się od siebie nawzajem rozmaitych technik pisania kodu w PowerShellu i możemy przedyskutować wszystko to, co powoduje różnicę zdań
  • poznajemy lepiej dodawany do środowiska produkcyjnego kodu – na koniec co najmniej dwie osoby powinny zaznajomić się z dodawanym kodem, spada „bus factor”

Oto jak taki Pull Request wygląda na platformie GitHub:

pull-rekłest

Oczywiście, zależnie od wybranej przez nas platformy wyglądać będzie inny. Ważne, że tego rodzaju akcje są zapisywane. Za kilka miesięcy możemy więc sprawdzić, kiedy jakieś zmiany zostały wprowadzone do naszego kodu. Bezcenna wiedza, kiedy chcemy na przykład usunąć skutki poważnej usterki w naszym kodzie.

~ - autor: Bartek Bielawski w dniu 13 czerwca, 2020.

Komentarze 3 to “Tworzymy moduł: praca z gitem”

  1. Calkiem spoko. Byloby super jakbys zrobil post o tym z uwzględnieniem VS studio code. Do tego dodatki typu gitlens, gitgraph i objasnic jakos na projekcie krok po kroku, to byloby bega super. Brakuje mi np. tez w internecie jakis takich przykladow z zycia wzietych zeby osoba co nigdy nie pracowala przy projekcie druzynowym z kodem np. w PS mogla zobaczyc jak wyglada taka wspolpraca, wlasnie wiecej rzeczy z tymi pull requestami etc. To naprawde byloby super.

    • Jezeli chodzi o gita, to na poczatek zawsze man od gita. W miare sensownie wyjasnia te pojecia.

    • Dzięki za komentarz! 🙂 Przyznam, że nie korzystam z VS code (poza rozwiązywaniem konfliktów – o tym pewnie wspomnę w jednym z kolejnych postów w cyklu). Z gitlens i gitgraph też raczej nie. Sugestię o obszerniejszym poście z pull request/ współpracą w ramach projektu dopisuje do planu cyklu – faktycznie, fajnie byłoby spiąć całość opisem „z życia wziętym”… 🙂

Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Wyloguj /  Zmień )

Zdjęcie na Google

Komentujesz korzystając z konta Google. Wyloguj /  Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Wyloguj /  Zmień )

Zdjęcie na Facebooku

Komentujesz korzystając z konta Facebook. Wyloguj /  Zmień )

Połączenie z %s

 
%d blogerów lubi to: