Projekt opensource – GitHub cz. 2

GitFlow

Jak wygląda tworzenie aplikacji? W skrócie: programista tworzy nowy branch na podstawie głównego brancha (zwykle głównego brancha developerskiego develop), wprowadza zmiany na nowy branch i po zakończeniu tworzy Pull requesta. Po zaakeptowaiu Pull requesta, zmiany trafiają na główny branch develop.

W celu optymalizacji pracy na branchach, warto wypracować model pracy, który nazywa się GitFlow. Tzn., że nowe branche powinny mieć odpowiednie nazewnictwo. Jeśli tworzymy branch do nowej funkcjonalności, powinien mieć on nazwę feature/feature_name. Jeśli branch będzie dotyczył naprawy jakiegoś błędu, nazwa powinna wyglądać tak: hotfix/hotfix_name.

Należy również pamiętać o tym, żeby gałąź master (produkcyjna) była
co jakiś czas synchronizowana z gałęzią develop (developerską).
Wszystkie commity z developa w pewnym momencie powinny być mergowane na mastera – z reguły podczas tworzenia nowej wersji.

Wersjonowanie aplikacji

Podczas rozwijania aplikacji, warto tworzyć nowe wersje (tzw. releasy) na głównej gałęzi (master). Powinny być one tworzone w ramach zakończenia pewnego etapu projektu, gdy na głównym branchu master uzbierały się zmiany.

Numeracja standardowo ma 3 składowe: wersję MAJOR, wersję MINOR i wersję PATCH (X.Y.Z). W aplikacji DAC podczas tworzenia aktualnych releasów uznałam, że wersja PATCH nie jest potrzebna i zastosowałam tylko dwuelementowy wzór wersjonowania. W przyszłości, gdy nie będą ciągle wrzucane nowe funkcjonalności, ale poprawki, zapewne zastosuję wzorzec trzyelementowy.


Issue template

Muszę przyznać szczerze, że w projekcie DevAdventCalendar nie utworzyłam takiego pliku, ponieważ większość issue tworzyłam sama. Jednak widzę potencjał w tej funckjonalności – więcej można poczytać na help.github.com.

Contributors

Można do projektu dodać współkoderów:

Dodatkowo w README.md lub w osobnym pliku CONTRIBUTING.md warto podać instrukcję kontrybucji dla zainteresowanych osób:

Ciekawostka na koniec

Okazuje się, że serwis ten wspiera również zarządzanie projektem przez tablice Kanbanowe.

Niestety nie miałam okazji skorzystać wcześniej z tej funkcjonalności, ponieważ tablicę kanbanową utworzyłam w Trello – ale o tym osobny wpis.


Podoba Ci się to, co tworzę? Chcesz dostawać informacje o:
– wydarzeniach, które organizuję lub wspieram (np. konferencje, meetupy, webinary)
– inicjatywach, które organizuję lub wspieram (np. GeekWeekWro, DevAdventCalendar)
– moich prelekcjach, kursach i szkoleniach
– wyróżnionych artykułach z mojego bloga

0% SPAMu, 100% informacji! Krótko i na temat.

Jedna uwaga do wpisu “Projekt opensource – GitHub cz. 2

  1. Pingback: Git rename branch – programmer-girl

Dodaj komentarz