Na początku, gdy zaczynamy projekt opensource, musimy ustalić, gdzie będziemy trzymać kod. W moim przypadku decyzja była prosta – GitHub. Założyłam więc na własnym profilu repozytorium DevAdventCalendar.

Sprawy organizacyjne

Pierwszą rzeczą, jaką należy zrobić po utworzeniu nowego repozytorium, jest utworzenie plików README.md i LICENSE (przykład). Dzięki temu wiadomo, jaka aplikacja będzie w repozytorium i jaką ma licencję.

Później należy pomyśleć o tym, jak chcemy zarządzać projektem. Czy każdy może robić commity i je mergować? Czy ma być jakaś weryfikacja wrzucanych zmian? Z własnego doświadczenia wiem, że przydają się wtedy Pull requesty i odpowiednie ustawienia projektu. Dzięki temu obniżamy prawdopodobieństwo wrzucenia złego kodu do repozytorium.

Pull requesty

Warto utworzyć pliku PULL_REQUEST_TEMPLATE.md (przykład), który posłuży wszystkim tworzącym pull requesty. Dzięki niemu podczas tworzenia nowego PR, od razu będą mieli gotowy do wypełnienia szablon:

Dzięki temu, przy tworzeniu PR, automatycznie wypełniany jest szablon, który użytkownik musi tylko wypełnić.

Co ważne, w części Motivation and Context najlepiej podlinkować konkretny issue, z którym wiąże się nasz task:

Dzięki temu w momencie, gdy zmergujemy PR do naszego głównego brancha, w historii Issue będzie widać flagę Merged mówiącą o tym, że zmiany dotyczące tego issue zostały zmergowane:

To bardzo ułatwia zarządzaniem zadaniami – wtedy wiadomo, że można np. zamknąć Issue (nie trzeba szukać, czy na pewno odpowiedni PR został zmergowany).

Przykładowy PR:

Branche

Jak każdy chyba wie, mamy branch master. Jest to domyślny branch, na którym powinniśmy trzymać działające wersje aplikacji. Na potrzeby developmentu należy utworzyć osobny branch, np. develop. To do niego będą mergowane wszystkie Pull requesty.

Jeśli wszystko będzie działać, zmiany z brancha develop będą wrzucane na branch master.

Ustawienia repozytorium

Najważniejsze ustawienia dotyczą branchy:

Główny branch to domyślnie master. Można również ustawić develop, wtedy nie trzeba będzie w każdy PR go zmieniać. Jak kto woli.

To, co jest bardzo ważne, to protection rules. To w nich można ustawić, żeby np. PR bez akceptacji przez drugą osobę (czyli Code Review) nie mógł zostać zmergowany. Według mnie to podstawowa zasada.

Można podejść do tematu jeszcze bardziej rygorystycznie i np. ustawić aż 2 osoby sprawdzające, a nie jedną.

Podoba mi się też ostania opcja – włączenie restrykcji również dla administratora. W tej chwili (gdy ta opcja jest wyłączona) będąc administratorem projektu mogę sama sobie zaakceptować PR i zmergować go. Nie jest to pożądane (bo nawet administratorzy się mylą), ale czasami się przydaje.