I've started writing this thing in polish some time ago, so it is in Polish. If you don't speak it, please let me know, I'll rewrite it to English right away.
Chciałbym w tej prezentacji przedstawić parę podstawowych koncepcji mających ułatwić i usystematyzować pracę z istniejącymi lub nowymi repozytoriami git z wykorzystaniem GitFlow, git hooków i Husky'iego.
Problem: Większość projektów nad którymi przychodzi nam pracować czy to komercyjnie, czy w społeczności opensource, ma to do siebie że rzadko pracuje się w pojedynkę. Repozytorium git staje się miejscem, z którego korzysta naraz wiele osób, i jak to w takich przypadkach bywa - prędzej czy później pojawia się bałagan. Git flow i git hooki to narzędzia dzięki którym, małym nakładem czasu (pieniędzy) można ten bałagan okiełznać, a przy umiarkowanym zaangażowaniu zasobów wyeliminować w przyszłości. Chciałbym, aby ta prezentacja dostarczyła tym, którzy o ich istnieniu nie wiedzą - narzędzi, a tym którzy te narzędzia znają - motywacji do ich stosowania.
Plan:
Problemy codzienności przy kolaboracji wielu osób w jednym repozytorium git
Dlaczego w ogóle potrzebujemy zasad pracy w repozytorium?
Czym brak takich zasad może skutkować?
Dlaczego pomimo szczerych chęci i zaufania, potrzebujemy technologii i narzędzi które będą pilnować porządku w repo?
Git Flow
Szybki recap samej metodologii
Jakie problemy próbuje to rozwiązać i z jakim skutkiem - w skrócie co to nam w zasadzie daje?
Techniczne strony wykorzystania Git Flow w CLI i popularnych GUI dla git
Git Hooks
Czym są hooki w git, i po co istnieją
Jak wygląda podstawowa implementacja Git Hooków
"Życiowe" przykłady wykorzystania hooków w zapobieganiu częstym "niesubordynacjom" w repozytorium
Husky (ale też inne rozwiązania) ułatwiające implementację git hooków
Podstawowe informacje o sposobach implementacji
Przykłady, przykłady.
Dyskusja - przykładowe "starting points"
Gdzie kończy się rozsądna organizacja repozytorium a zaczyna ograniczanie wydajności i komfortu pracy poprzez narzucanie nierozsądnych wymagań?
A czy to działa w zdalnym repo? Jak to jest z hookami na serwerze?
Kiedy na prawdę warto pomysleć o sformalizowaniu wymogów dla commitów trafiających do naszefgo repo? Czy to tylko kwestia wielkości repozytoruum i ilości "kontrybutorów"?
Dla kogo ta prezentacja:
Nie ma co ukrywać - przede wszystkim dla mnie. Uczestniczę w poznańskich meetuach jako słuchacz od jakiegoś czasu i czuję że mógłbym i bardzo chciałbym przyłożyć się do tego od tej bardziej aktywnej strony, ale też sprawdzić się przed większą i na pewno bardziej wymagającą publicznością. A jeśli idzie o publiczność - to chciałbym żeby to wystąpienie z jednej strony dało coś ludziom zaczynającym swoją karierę (a tych, wnosząc po dyskusjach "przy piwie" na meetupach, jest całkiem spora grupa) a z drugiej strony - żeby starzy wyjadacze raz że nie posnęli w trakcie, a dwa - może włączyli się do dyskusji albo zainspirowali się jakimś, zdawałoby się oczywistym konceptem. Jestem świadom tego jak to jest trudne, ale bardzo chciałbym żeby .w trakcie prezentacji pojawił się jakis dialog. Git jest zagadnieniem z kótrym pracuje praktycznie każdy, niezaleznie od technologii i doświadczenia, i każdy ma coś do powiedzenia. Wierze że dzieki temu uda się rozkręcić dyskusję jeśli nie w trakcie prezentacji, to po niej. Uważam, że wielką mocną stroną tematu jest to że może dotyczyć każdego, nie zważając na technologię, obszar biznesowy pracy, doświadczenie czy rolę w zespole.
Organizacyjnie:
Nie wiem jak wyglądają plany na wystąpienia przed końcem roku. Do końca listopada nie ma mnie w Polsce, w grudniu planuję mieć wyjątkowo dużo czasu wolnego więc mógłbym coś przygotować i zaprezentować - plan jest w głowie, wypadałoby go przelać na jakieś mnie ulotne medium. Zakładając że temat zostałby uznany za ciekawy (lub, minimalnie haniebny dla dotychczasowego poziomu meetupu), chętnie przygotuję i przedstawię go przed końcem roku, lub na początku nadchodzącego. Mogę to zrobić w języku polskim lub angielskim - nie robi mi to żadnej różnicy (ten issue jest po polsku, ale jeśli jest potrzeba przepiszę to na język Szekspira).
jablpiotrek
commented
5 years ago
Chciałbym w tej prezentacji przedstawić parę podstawowych koncepcji mających ułatwić i usystematyzować pracę z istniejącymi lub nowymi repozytoriami git z wykorzystaniem GitFlow, git hooków i Husky'iego.
Problem: Większość projektów nad którymi przychodzi nam pracować czy to komercyjnie, czy w społeczności opensource, ma to do siebie że rzadko pracuje się w pojedynkę. Repozytorium git staje się miejscem, z którego korzysta naraz wiele osób, i jak to w takich przypadkach bywa - prędzej czy później pojawia się bałagan. Git flow i git hooki to narzędzia dzięki którym, małym nakładem czasu (pieniędzy) można ten bałagan okiełznać, a przy umiarkowanym zaangażowaniu zasobów wyeliminować w przyszłości. Chciałbym, aby ta prezentacja dostarczyła tym, którzy o ich istnieniu nie wiedzą - narzędzi, a tym którzy te narzędzia znają - motywacji do ich stosowania.
Plan:
Dlaczego w ogóle potrzebujemy zasad pracy w repozytorium?
Czym brak takich zasad może skutkować?
Dlaczego pomimo szczerych chęci i zaufania, potrzebujemy technologii i narzędzi które będą pilnować porządku w repo?
Szybki recap samej metodologii
Jakie problemy próbuje to rozwiązać i z jakim skutkiem - w skrócie co to nam w zasadzie daje?
Techniczne strony wykorzystania Git Flow w CLI i popularnych GUI dla git
Czym są hooki w git, i po co istnieją
Jak wygląda podstawowa implementacja Git Hooków
"Życiowe" przykłady wykorzystania hooków w zapobieganiu częstym "niesubordynacjom" w repozytorium
Podstawowe informacje o sposobach implementacji
Przykłady, przykłady.
Gdzie kończy się rozsądna organizacja repozytorium a zaczyna ograniczanie wydajności i komfortu pracy poprzez narzucanie nierozsądnych wymagań?
A czy to działa w zdalnym repo? Jak to jest z hookami na serwerze?
Kiedy na prawdę warto pomysleć o sformalizowaniu wymogów dla commitów trafiających do naszefgo repo? Czy to tylko kwestia wielkości repozytoruum i ilości "kontrybutorów"?
Dla kogo ta prezentacja: Nie ma co ukrywać - przede wszystkim dla mnie. Uczestniczę w poznańskich meetuach jako słuchacz od jakiegoś czasu i czuję że mógłbym i bardzo chciałbym przyłożyć się do tego od tej bardziej aktywnej strony, ale też sprawdzić się przed większą i na pewno bardziej wymagającą publicznością. A jeśli idzie o publiczność - to chciałbym żeby to wystąpienie z jednej strony dało coś ludziom zaczynającym swoją karierę (a tych, wnosząc po dyskusjach "przy piwie" na meetupach, jest całkiem spora grupa) a z drugiej strony - żeby starzy wyjadacze raz że nie posnęli w trakcie, a dwa - może włączyli się do dyskusji albo zainspirowali się jakimś, zdawałoby się oczywistym konceptem. Jestem świadom tego jak to jest trudne, ale bardzo chciałbym żeby .w trakcie prezentacji pojawił się jakis dialog. Git jest zagadnieniem z kótrym pracuje praktycznie każdy, niezaleznie od technologii i doświadczenia, i każdy ma coś do powiedzenia. Wierze że dzieki temu uda się rozkręcić dyskusję jeśli nie w trakcie prezentacji, to po niej. Uważam, że wielką mocną stroną tematu jest to że może dotyczyć każdego, nie zważając na technologię, obszar biznesowy pracy, doświadczenie czy rolę w zespole.
Organizacyjnie: Nie wiem jak wyglądają plany na wystąpienia przed końcem roku. Do końca listopada nie ma mnie w Polsce, w grudniu planuję mieć wyjątkowo dużo czasu wolnego więc mógłbym coś przygotować i zaprezentować - plan jest w głowie, wypadałoby go przelać na jakieś mnie ulotne medium. Zakładając że temat zostałby uznany za ciekawy (lub, minimalnie haniebny dla dotychczasowego poziomu meetupu), chętnie przygotuję i przedstawię go przed końcem roku, lub na początku nadchodzącego. Mogę to zrobić w języku polskim lub angielskim - nie robi mi to żadnej różnicy (ten issue jest po polsku, ale jeśli jest potrzeba przepiszę to na język Szekspira).