Cartesian School CartesianSchool
Python od zera / Rozdział 23 / Issue → Branch → PR
Rozdział 23 · Część II · Planowanie SafeSort na GitHub

Pierwsza pętla: Issue → Branch → Pull Request

Issue → rozgałęzia → kod i testuje → Pull Request → CI → scalanie — pętla, która powtarza się dla większości zadań SafeSort, ale nie według sztywnej zasady "jeden Issue — jeden PR.

SafeSort · Część 2 z 6Planowanie

Issue sformułowany, teraz przeanalizujmy pełny cykl jego życia, od zadania zadania do zamknij. Ten cykl powtarza się dla większości zadań SafeSort, zaczynając od następnego części rozdziału — ale nie według sztywnej zasady „jeden Issue — jeden Pull Request”

Issuezadaniesformułowany,status ReadyGałąźzmiany statusu na InProgressKod i testypraca wodizolowana gałąźPull Requestzmiany statusu na InReviewCI i weryfikacjaautomatyczne testy+ samotestowanie FileschangedMergeIssue się zamyka,status to Done
Pełny cykl jednego zadania – od Issue do Done
Terminal
git switch -c feat/directory-scanner
# ...пишем код и тесты, коммитим изменения...
git push -u origin feat/directory-scanner

Po push otwórz repozytorium w przeglądarce i kliknij Compare & pull request, wybierz base: main, dodaj tytuł i struna Closes #1 do opisu. git pracuje z historią i Pull Request jest tworzona w interfejsie GitHub.

Closes #N zamyka Issue automatycznie — a jeden PR może zamknąć od razu kilka
Jeśli ciało Pull Request zawiera frazę w rodzaju Closes #1GitHub automatycznie zamyka Issue numer 1 w momencie łączenia tego PR — nie ma potrzeby zamykania Issue ręcznie. Nic nie stoi na przeszkodzie w zapisywaniu Closes #3, Closes #6jeśli PR rozwiązuje dwa blisko powiązane problemy jednocześnie, to właśnie tak stało się w repozytorium SafeSort z planem ruchu i obsługą konfliktów nazw.
Nie każdy Issue zamyka się po PR
Formułowanie zadania przez Issue nie zobowiązuje cię do zamknięcia go Pull Request. Jeśli praca została wykonana po drodze, jako część innego zadania lub nie wymagała żadnego kodu, można Issue zamknąć ręcznie — z komentarzem wyjaśniającym, co się wydarzyło. Prawdziwa historia projektu jest ważniejsza niż sztucznie płaska tabela „N zadań — N PR”

Następna część rozdziału przechodzi przez ten cykl naprawdę, krok po kroku, po raz pierwszy Prawdziwe zadanie — skaner katalogowy.

Oficjalna dokumentacja
About pull requests
Tłumaczenie i edukacyjna adaptacja oficjalnej dokumentacji GitHub. materiałów źródłowych – CC BY 4.0.

Krótko

  • Issue → branch → kod i testuje → Pull Request → CI, a → merge check to pełny cykl jednego zadania.
  • „Closes #N”
  • Ta seria opisuje większość zadań, które SafeSort, ale nie jest to sztywna zasada — czasem PR zamyka się kilka blisko powiązanych Issues, a niektóre zadania są zamykane bez osobnego PR.
← Back
Tworzenie Issues