Jak korzystać z szablonów PR GitHub

Jeśli wykonujesz jakąkolwiek pracę – niezależnie od tego, czy jest to open source czy zamknięte źródło – (chociaż wiem, że większość użytkowników czytających tę stronę jest zaangażowanych w open source), prawdopodobnie użyjesz pewnej kontroli źródła i prawdopodobnie jest to GitHub.

Dla wielu z was albo śledzicie projekt, przyczyniacie się do projektu, albo obsługujecie żądania ściągnięcia do projektu. A co z tymi projektami, nad którymi pracujesz z zespołem?

Być może twój przepływ pracy wygląda mniej więcej tak:

• tworzysz gałąź do pracy nad cechą,
• popychasz gałąź, aby szczegółowo opisać pracę, którą wykonałeś, aby recenzent mógł ją zrecenzować,
• recenzja jest scalona,
• kontynuujesz.

Ale co umieszczasz w szablonie żądania ściągnięcia? Czy za każdym razem jest tak samo, czy jest inaczej? A jeśli treść PR jest powiązana z czymś w Trello, Asanie, Basecamp lub innym systemie zarządzania projektami?

Tutaj do gry wchodzą szablony GitHub PR.

Szablony PR GitHub

Możesz przeczytać o nich wszystko na stronie, ale oto ich sedno (gra słów niezamierzona):

Trudno rozwiązać problem, gdy brakuje ważnych szczegółów. Teraz opiekunowie projektów mogą dodawać do projektów szablony problemów i pull requestów, pomagając współtwórcom udostępniać właściwe szczegóły na początku wątku

Pomysł jest prosty: tworzymy szablony problemów i pull request dla innych osób, które zapewniają poziom informacji, które muszą wypełnić przed przesłaniem problemu lub pull request.

To nam pomaga, ponieważ opiekunowie wiedzą, jakich informacji potrzebujemy, zanim się do nich zajrzy. Co więcej, może nam to pozwolić na połączenie z poprzednim wydaniem, poprzednim zgłoszeniem, przed wszystkim związanym z projektem.

Na przykład załóżmy, że pracujesz nad projektem i chcesz dołączyć następujące informacje:

• krótki opis tego, co robi PR, aby opiekun nie musiał zgadywać,
• status PR na temat tego, czy powinien być gotowy do scalenia, czy nadal jest w fazie rozwoju, ale gotowy do przeglądu,
• link do zgłoszenia w kierowniku projektu, którego dotyczy PR.

Nie mówię, że są to informacje, które są wymagane, ale są to informacje, z których korzystaliśmy i które okazały się przydatne (i miło jest widzieć, jak z czasem wprowadzane są kolejne ulepszenia ).

Ale jak tego używamy?

Strona jest dość przejrzysta, ale jest naprawdę prosta. Potrzebujesz następujących plików w katalogu projektu lub w katalogu projektu. katalog github :

• ISSUE_SZABLON
• PULL_REQUEST_TEMPLATE

Każdy z nich powinien być plikami ze znacznikami, które dokładnie opisują to, co chcesz dołączyć do swoich współtwórców, gdy tylko w jakiś sposób przyczyniają się do twojego projektu.

A potem, gdy użytkownik chce zgłosić problem lub utworzyć żądanie ściągnięcia, wyświetla monit z informacjami z szablonu.

Ładne, prawda?

To niewiele, ale…

Możesz nie sądzić, że to dużo, ale całkiem łatwo jest pomóc poprawić jakość informacji przychodzących do projektu, poprosić współtwórców o zastanowienie się nad tym, co wkładają w projekt, a następnie odpowiednio zareagować.

Ponadto pomaga tobie i reszcie zespołu zrozumieć, co ma zostać poddane przeglądowi, i przygotować się na wszelkie zmiany, które mogą pojawić się podczas pracy nad tymi projektami.