Jak pracować z GitHub?

Praca z różnymi gałęziami.

Główną gałęzią w projekcie jest master, do której dostarczane powinny być funkcjonalności gotowe do release. Elementy release oznaczają te funkcjonalności, które zostały przetestowane, zweryfikowane i mogą zostać dostarczone do klienta końcowego.

Kolejną ważną gałęzią jest development, jest to pierwszy etap weryfikacji pracy nad funkcjonalnościami. Do tej gałęzi dostarczamy elementy (funkcjonalności) z którymi skończyliśmy pracować, które powinna zweryfikować osoba druga (przykładowo: poprzez code review).

Ważnymi gałęziami również będą gałęzie feature/*, gdzie * oznacza nazwę danej gałęzi realizującej pewną funkcjonalność. Nazwa powinna być na tyle krótka, żeby nie zajmować dużo miejsca, a jednocześnie mówiąca wszystko o realizowanej funkcjonalności. Przykładowo feature/create-user-account.

Kolejnymi gałęziami będą gałęzie fix/*, gdzie * oznacza nazwę danej gałęzi poprawiającej pewną funkcjonalności. Nazwa powinna być na tyle krótka, żeby nie zajmować dużo miejsca, a jednocześnie mówić wszystko o wprowadzanej poprawce do funkcjonalności. Przykładowo fix/create-user-account.

Następnie wprowadzamy gałęzie refactor/*, gdzie * oznacza nazwę danej gałęzi refaktoryzującej pewną funkcjonalności. Nazwa powinna być na tyle krótka, żeby nie zajmować dużo miejsca, a jednocześnie mówić wszystko o wprowadzanych poprawkach w jakości kodu danej funkcjonalności. Przykładowo refactor/create-user-account.

Jeżeli w Trello będzie można wykorzystać mechanizm generowania identyfikatorów do tytułu danego zadania, to zamiast nazwy własnej dla gałęzi feature, fix, refactor będziemy używać właśnie tych identyfikatorów (TODO: sprawdzenie możliwości Trello od strony generowania zadań).

Tworzenie pull (merge) requestów.

Każda osoba przed wystawieniem dowolnego pull (merge) request powinna wykonać pewną listę kroków. Podstawowymi elementami, które zawsze powinno być wykonane są:

1. Upewnienie się, że w pull request znajdują się wszystkie zmiany, które chcemy dostarczyć.
2. Upewnienie się, że funkcjonalności, które dostarczamy działają poprawnie, zgodnie z przyjętymi założeniami zadania.
3. Upewnienie się, że formatowanie kodu zgadza się z formatowaniem kodu wykorzystywanym przez pozostałych członków zespołu.
4. W przypadku, gdy stosujemy testy jednostkowe/integracyjne/inne w projekcie, testy te zawsze powinny być uruchamiane przed pull requestem.
5. W przypadku, gdy wykorzystujemy TsLint (projekt Angular), upewniamy się, że dostosowaliśmy się do zasad przedstawianych przez to narzędzie.
6. Upewnienie się, że zarówno commit'y jak i pull request ma odpowiednio opisany komentarz, tak aby osoba go sprawdzająca wiedziała co się zmieniło bez zaglądania w kod (co zostało zaimplementowane). Kod powinien informować tylko o sposobie implementacji.
7. ... (TODO: ewentualne dodanie kolejnych kroków podstawowej weryfikacji swojego pull (merge) request)

Oczywiście, poza weryfikacją powyższych kroków, można ustalić swoje własne tak, aby drugiej osobie lżej się czytało naszego pull (merge) request i nie musiała pamiętać o wszystkich rzeczach sama.

Podstawowe komendy Git.

GitHub - Git CheatSheet PL

Do nauki Git'a jest wiele materiałów w internecie, lepszych, gorszych, płatnych, darmowych. Warto coś poczytać, jeżeli ktoś nie do końca Git'a czuje.