Agenda
| Start time | Kata |
|---|---|
| 11:00 |
|
| 11:30 |
|
| 12:20 |
|
| 13:10 |
|
| 13:50 |
|
| 14:50 |
|
| 15:40 |
|
| 16:30 |
|
| 17:20 |
|
Kata descriptions (Polish)
Git rebase
Motywacja
Rebase pozwala na zwinne manipulacje commitami w grupach. Można sobie poradzić bez tej komendy, umieszczając ręcznie odpowiednie commity w innych miejscach, lecz z rebasem zmienia się całe nasze podejście do Gita. Dla nieznających tego polecenia to "must"
Scenariusz
Zaczniemy od dwóch branchy. Przeniesiemy sobie kilka commitów w inne miejsce i spowrotem. Zmienimy przy okazji labelki (branche). Następnie poznamy sytuacje skrajne, czyli np przeniesienie brancha na samego siebie.
Git submodules
Motywacja
Kiedy rozwijamy aplikacji i uzywamy zewnatrznej biblioteki (open source albo poprostu oddzielny projekt wewnatrz naszej firmy) czesto mamy problem zaleznosci wersji. Nie chcemy czekac na kolejny release biblioteki zeby rozwinac aplikacji. Wtedy mozemy zintegrowac ta biblioteke do naszego repo jaki submodule i granulacje zaleznosci sprowadzic do konkrentych commitow: commit X aplikacji zalezy od commitu Y biblioteki.
Scenariusz
Startujemy z osobnej aplikacji i dwie biblioteki. Zintegrujemy biblioteki jaki submoduly i uzalezniamy sie od konkrentego builda. Zrobimy kilka przebiegow modyfikacji: tylko apka, tylko biblioteki, branche rownolegle dla app/biblioteki. Na koniec skazujemy biblioteki i wrocimy do zaleznosci od konkrentego release biblioteki.
Configs, handful aliases, other tips & tricks
Motywacja
Siadasz obok człowieka, żeby zrobić jakiś pair-programming albo generalnie pomóć mu w gicie, i patrzysz jak się męczy. Albo jak twierdzi że git to tylko z IDE. Zwykle znaczy to, że nie skonfigurował sobie środowiska. Git jest naprawdę dobrze zbudowany, ale człowiek który napisał te całe ""UI"" miszczem usability nie był (to nie Torvalds, Torvalds zrobił bebechy). W związku z tym, trzeba czasem sobie trochę pomóć i o tym będzie ta kata.
Scenariusz
Zaczniemy od zawartości .git/config, ustwienia kim jestem per projekt, kolorków, i domyślnego edytora, a potem pojedziemy z aliasami, różnymi fajnymi i nie tylko.
Pull & push options (push current/tracking branches, pull with rebase)
Motywacja
Czemu git pull czasami robi merge'a a czasami nie? Jak go zmusić, aby zamiast merge'a robił rebase? Czemu jak wypycham zmiany z mojego branche'a to razem z nim wypychane są wszystkie zmiany z pozostałych branche'y? Ta kata wyjaśni domyślne zachowania gita i pokaże jak je zmienić
Scenariusz
Kata będzie podzielona na dwie części: push i pull. Zaczniemy od testowania różnych konfiguracji wybierania branche'y które mają być wypchnięte. Nauczymy się jak tworzyć zdalne branche na serwerze. W drugiej części sprawdzimy kiedy git pull kończy się commitem merge'ującym oraz jak możemy go zmusić do rebase'owania
Branche i tagi
Motywacja
Czym są branche? Jak tworzone i reprezentowane są tagi i inne obiekty w GIT? Co czyni go takim wyjątkowym i jak się to ma do pozostałych systemów kontroli wersji.
Scenariusz
Zapoznamy się z obiektami reprezentującymi tagi, branche i commity w GIT. Nauczymy się jak się je tworzy, zarządza, merguje i jak najlepiej stworzyć drzewko w naszym repozytorium.
Git filter-branch
Motywacja
Chcesz upublicznić swój projekt z całą historią commitów? Niestety zawiera ona dane, których nie możesz udostępnić, takie jak adresy e-mail albo nieopatrznie zamieszczone hasła. Co wtedy? Wtedy możesz zmienić swoją historię za pomocą git filter-branch.
Scenariusz
Na przykładach zobaczymy w działaniu filtry dostępne w komendzie filter-branch. Za ich pomocą "masowo" przepiszemy historie specjalnie przygotowanych gałęzi.
Manipulating commits with amend and cherry-pick
Motywacja
Zapomniałem zacommitować jeden plik? Zrobiłem literówkę w komentarzu? Przed dokonaniem pusha możemy szybko to naprawić w sposób wygodniejszy niż z poleceniem reset. Jak utrzymując stabilny branch wydaniowy zbierać tylko poprawki bezpieczeństwa z mastera? Jak szybko pożyczyć jeden commit od kolegi? Na co trzeba wtedy uważać.
Scenariusz
Zaczniemy od amend i tego co oferuje i w jakich sytuacjach się sprawdza. Potem spróbujemy użyć i zrozumieć do czego jest cherry-pick biorąc jeden z commitów z innego brancha. Potem zobaczymy kilka w akcji. Na koniec porozmawiamy o tym kiedy NIE WOLNO tak robić.
Git-flow
Motywacja
Wszyscy wiemy jak zrobić commit na branchu i wypushować go remote repo. Ale jak poradzić sobie z kilkoma branchami? Co gdy do jednego repo commituje wielu developerów którzy pracują nad różnymi nowymi funkcjonalnościami? Do tego mamy jeszcze brancha który odzwierciedla stan aktualnej produkcji i chcemy zrobić w nim poprawkę ale tak żeby nie zgubiła się w wersji developerskiej. Gitflow odpowiada na te wszystkie problemy poprzez narzucanie sensownego modelu branchowania i dodanie kilku komend które znacznie ułatwiają połapanie się w tym całym chaosie.
Scenariusz
Nauczymy się tworzyć feature branche przy pomocy gitflowa oraz jak sprawnie się między niemi przełączać i dzielić z innymi developerami. Kolejny krok to release. Sprawdzimy jak gitflow może pomóc nam w tej sytuacji. Gdzie powinny trafić commity robione podczas release'u, Kiedy powinniśmy otagować repozytorium oraz jak cofnąć nieudany release. Na koniec poznamy zestaw komend "gitflow hotfix ...". Dowiemy się jak zarządzać poprawkami do wersji produkcyjnej i dlaczego używać do tego gitflowa zamiast samemu wykonywać merge'e i cherry-pick'i.
Git refspec (fetchowanie określonych branche'y)
Motywacja
Słów push, pull, master używasz codziennie. Ale czy czasami zdarzło Ci się używać ":" w komendach gita? Wiesz co to jest pull origin +master:master? Jak fetchować tylko interesujące Cię branche? Jak skasować zdalnego branche'a? Kata pokaże Ci to co jest refspec i jak się tego używa w najpopularniejszych komendach jak pull i push
Scenariusz
Rozpoczniemy od omówienia struktury refspec, spróbujemy znaleźć ją w konfigu naszego repo. Nauczymy się jak dużą siłę ma "+". Zrobimy kilka zdalnych branche'y w róznych refspecach i nauczymy się jak śledzić tylko te, które nas interesują.
Merging vs rebasing
Motywacja
Czym różni się merge od rebase? Dlaczego jeden z nich jest lepszy, jak to się ma do historii repozytorium i commitów?
Scenariusz
Dowiemy się jak wygląda repozytorium przed i po mergach, rebaseach. Reprezentację obiektów GITowych oraz wpływ na nasz kod i pojawianie się konfliktów.
USB workflow
Motywacja
Czasami zdarza się, że przygotowanie serwera ze zdalnym repozytorium może być niepotrzebnym overheadem, lub jest po prostu niemożliwe (np. ze względu na brak dostępu do sieci). Taka sytuacja może się wydarzyć np. na warsztatach podobnych do Git Kata. Dzięki temu, że każde repozytorium gita jest pełną kopią, to możemy wykorzystać dowolny nośnik jako nasz "serwer" z głównym repozytorium. W przypadku tego Kata naszym serwerem stanie się zwykły pendrive.
Scenariusz
Na początku zaczniemy od omówienia jak może wyglądać konfiguracja/zestaw środowisk do pracy z repozytorium na USB. Następnie szybko zestawimy takie środowisko dla przykładowych maszyn i założymy repozytorium. Kolejne kroki to będzą przykładem jak może wyglądać praca/wymiana dancyh poprzez repozytorium na USB.
Przyjmowanie zmian ze świata, lokalne ficzer branche, odratowanie stasha po dropie
Motywacja
Gdy pracujemy świat nie śpi. Inni programiści dokonują zmian i czasem okoliczności zmuszają nas do uwzględniania ich przed dokonaniem pusha do mastera. W Subversion update przy niefortunnym commicie kolegi mógł zapewnić nam godziny dodatkowej pracy. Mając Gita jesteśmy w dużo lepszej sytuacji. Celem katy jest odpowiedź na pytania: Co to jest stash? Co to są lokalne ficzer branche? Dlaczego warto ich używać? Jak naprawić blokera na produkcji mając rozgrzebany nowy ficzer?
Scenariusz
Zaczniemy od sposobów radzenia sobie z przyjmowaniem do siebie zmian commitowanych przez inne osoby w sytuacji, kiedy nasz kawałek nie jest jeszcze gotowy i nie chcemy/nie możemy go wysłać do zdalnego repozytorium. Następnie zobaczymy dlaczego zamiast na masterze warto pracować na lokalnych ficzer branchach i jak szybko przejść od zaplanowanej pracy do ""gaszenia pożaru na produkcji"". Jako bonus zobaczymy, co zrobić jak przypadkiem zamiast ""stash pop"" wpisze nam się ""stash drop"". Uwaga. Kata częściowo zazębia się z "Merging & Rebasing".
Undoing changes
Motywacja
"Oops, ten commit nie miał tak wyglądać", "Zapomniałem o jednym pliku", "Źle rozwiązałem ten konflikt". Jak zmienić message, jak odwrócić commit, jak zmienić historię? Ta kata nauczy Cię jak wyjśc obronną ręką z sytuacji, w których coś poszło nie tak
Scenariusz
Zaczniemy od najprostszej zmiany ostatniego commita. Potem będziemy je odwracać - jeden lub kilka. Nauczymy się też usuwać commit z historii przy użyciu reset i rebase -i. Zakończymy reflogiem, który pomoże nam w naprawdę trudnych chwilach :) Jeśli starczy czasu przejdziemy przez git clean i git checkout --
Git rerere
Motywacja
Git rerere, czyli "Reuse Recorder Resolution" pozwala zaoszczędzić dużo czasu spędzonego nad mozolnym rozwiązywaniem konfliktów w GIT. Kata nie tylko nauczy Cię jak włączyć i korzystać z tej opcji, ale pokaże Ci jak to wszystko działa i w jakich sytuacjach ta opcja może Ci zaoszczędzić mnóstwo czasu
Scenariusz
Rozpoczniemy z kilkoma skonfliktowanymi ze sobą branche'ami, które będziemy chcieli zmerge'ować. Sprawdzimy ile czasu spędzimy nad rozwiązaniem wszystkich konfliktów. Następnie skorzystamy z rerere i zobaczymy co się zmieni. Kata zakończy się pokazaniem jak mechanizm rerere działa pod spodem, jakie ma wady i zalety. Zakończymy odpowiedzią na pytanie: "Jak pracować w grupie, aby mieć jak najmniej konfliktów"
Bebechy gita: katalog .git i jak to działa
Motywacja
Początkujący gitowcy często narzekają, że polecenia nie mają sensu, a sam git jest zakręcony jak słoik. Tymczasem bebechy gita są banalnie proste i super skuteczne. To tylko API jest delikatnie mówiąc przekombinowane. Jeśli poznać zawartość katalogu .git i co się w nim dzieje, można dużo lepiej zrozumieć gita i jego API. W sytuacji awaryjnej, pomoże nam to odzyskać dane i lub zrobic to co chcemy, gdy w innej sytuacji musielibyśmy najpierw nauczyć się nowej komendy (potencjalnie niebezpiecznej).
Scenariusz
Przejdziemy przez zawartość katalogu .git i zobaczymy co gdzie leży, jak się uzupełnia, jak modyfikować gita bez używania poleceń (edytorem tekstu) i co z tego wszystkiego wynika (np. jak się przestać bać, robić prosty backup, albo zrozumieć git reset). Ponadto przedstawione zostaną obiekty w gicie dzięki poznaniu których zrozumiemy dlaczego jest jednym z najlepszych systemów kontroli wersji.
Git bisect
Motywacja
Uwaga: pełne uczestnictwo w tej kacie wymaga zainstalowanego mavena lub gradle
Czasami, nawet pomimo używania continous integration i testów automatycznych, pojawia się w projekcie tajemnicza regresja. Co gorsza, nikt z zespołu nie ma pomysłu, co ją mogło spowodować. Wtedy z pomocą przychodzi nam komenda git bisect.
Scenariusz
Na specjalnie przygotowanych gałęziach zobaczymy jak znaleźć commita, który "popsuł" coś w projekcie. Najpierw regresji będziemy szukać za pomocą testów ręcznych. Potem na gałęzi zawierającej tysiąc commitów znajdziemy problematyczną zmianę wpisując w konsoli tylko jedną komendę.
Git-svn
Motywacja
Pracujesz nad projektem, która nadal korzysta z SVN. A twój szef oraz twoi koledzy są niechętni do wprowadzania zmian. Natomiast, Ty jako innowator chcesz korzystać z bardziej zwinnych technik programowania. Git daje Ci taką możliwość! Wykorzystaj dostępną infrastrukturę w połączeniu z mocą Gita.
Scenariusz
Zaczniemy od przygotowania repozytorium Git na bazie już istniejącego repozytorium SVN. Przećwiczymy pracę na branchach, dodawnie oraz usuwanie tagów. Nauczymy się jak należy pullować i pushować do repozytoriów SVN oraz czego nie należy robić wykorzystując git-svn. Jako uzupełnienie wspominmy o obsługiwanych właściwościach repozytoriów SVN.
Fish shell & git prompt
Motywacja
Masz linuxa? Używasz basha? Ta kata jest dla Ciebie! Poznasz bash++ czyli konsolę fish i jej wsparcie dla gita. Po tej kacie nie będziesz już zastanawiał się na jakim branche'u pracujesz, czy jesteś w trakcie rebase'a a może rozwiązujesz jakiś konflikt w trakcie merge'a. Przestaniesz używać git status do sprawdzenia, czy wszystko co scommitowałeś zostało wypchnięte do upstreama.
Scenariusz
Kata będzie podzielona na dwie części: fish i git+fish. Zaczniemy od instalacji konsoli fish. Omówimy jej przewagę nad bashem. Druga część to włączenie funkcji git_prompt, tune'owanie jej zachowania i stworzenie swojego własnego prompta.
Praca z serwisami: github, bitbucket
Motywacja
Do pracy przy projektach komercyjnych zazwyczaj będziesz wykorzytywał(a) repozytorium, które będzie umieszczone w wewnętrznej sieci twojej firmy/klienta. Jeśli jednak chciał(a)byś pobawić się w wolnym czasie jakimś prywatnym lub otwartym projektem, np. nad stworzyć fajną grę, to serwer z repozytorium umożliwiającym synchronizację pomiędzy różnymi programistami (lub pomiędzy twoim różnymi maszynami) może znacznie ułatwić Ci zabawę. Dzięki serwisom github i bitbucket nie musisz samodzielnie stawiać własnego serwera Git.
Scenariusz
W tej kacie skupimy się nie tylko na omówieniu i przedstawieniu w jaki sposób zestawić sobie środowisko do pracy z serwisem github i bitbucket, ale też postaramy się zobaczyć jaki inne zalety (poza samym trzymaniem historii naszych zmian) oferują nam te serwisy. Ponadto zobaczymy w jaki sposób można jednocześnie korzystać z obu serwisów pracując nad jednym projektem.
Patches
Motywacja
Czy zastanawiałeś się jak wygląda praca nad projektami OpenSource, takimi jak linux-kernel, OpenWrt, czy Proxmox? Okazuje się, że pull request nie zawsze jest najlepszym i najwygodniejszym rozwiązaniem. Z pomocą przychodzą wbudowane narzędzia: format-patch, email-patch i am.
Scenariusz
Naczymy się jak korzystać z wyżej wymienionych narzędzi zamiast standardowych pull requestów.
Git rebase -i
Motywacja
Interaktywny rebase w Gicie pozwala na bardzo zwinne operowanie strukturą historii w poukładany i prosty sposób. Kata ma za zadanie pokazać jak posługiwać się instrukcją, jakie mamy możliwości i na co uważać.
Scenariusz
Zaczynamy od przełożenia jednego commita na inny branch. Następnie przekładamy zakres commitów. Później przekładamy brancha. Kolejny etap to zmiana kolejności commitów, usuniecie jednego z nich. Na koniec dowiemy się kiedy i jak robić zamieszanie w historii, a kiedy nie wolno.
reset vs. revert
Motywacja
Pomyłki się zdarzają się nawet najlepszym. Ci mniej doświadczeni popełniają je znacznie częściej. Jeżeli tylko zachowamy spokój w zdecydowanej większości przypadków możemy eleganko (i bez śladu) odwrócić niepożądane operacji wykonane na repo lokalnym. Jeżeli zdarzy się już push na serwer zdalny nie wszystkie chwyty są nadal dozwolone, ale wciąż możemy odwrócić nasze zmiany.
Scenariusz
Przyjrzymy się dwóm podejściom do naprawiania niechcianej sytuacji w repozytorium. Nauczymy się cofać niechciane commity, nieudane merge oraz usuwać ""śmieci"" wrzucone do repo zdalnego przez niedoświadcoznego kolegę. Dowiemy się czym różnią się od siebie, jakie mają wady i zalety oraz kiedy powinniśmy (a kiedy nie możemy) ich stosować. Uwaga. Kata w sporej części zazębia się z ""Undoing changes"".