Rozdział 23 · Część V · Sprawdzamy i automatyzujemy

GitHub: używać Issue, branch i Pull Request

Spójrzmy na Pull Request #20, który przeszedł test, został połączony i zamknięty Issue #9.

SafeSort · Część 5 z 6

Git i GitHub→Planowanie→Projekt→Wdrożenie→Testy i CI→Premiera

Część II już rozłożyła pętlę Issue → rozgałęzienie → kod → Pull Request → CI → scalanie Więcej informacji można znaleźć na stronach 23-proj-17. Teraz zastosuj ten schemat do zakończonej zmiany SafeSort: Issue #9 «Add duplicate detection». Tym razem przeanalizujemy sam Pull Request.

LOCAL GIT	GITHUB
git switch -c feat/duplicate-detection	Issue #9 opisuje to zadanie
Edycja + pytest lokalna	usunięta gałąź pojawi się po push
git add + git commit	Pull Request porównuje wątek do main
git push -u origin feat/duplicate-detection	Conversation, Commits, Checks, Files changed
po merge: git fetch / pull	review merge decyzja zamknięcie Issue

Granica przecina się na git push: lokalne commity stać się odległą gałęzią. Issue i Pull Request są GitHub obiektami, i switch, edycja, testy, staging i commit się dzieją lokalnie. Po merge lokalny Git poznaje nowy stan poprzez fetch/pull.

Issue #9 w Project

Issue #9 wcześniej dodano w Project „SafeSort: pierwsza wersja”. Na stronie 23-proj-09 już widzieliśmy, jak Issues trafiają do Project. Poniżej pokazano formularz GitHub z polami nagłówka, opisu i metadanych.

Formularz do tworzenia nowego Issue na GitHub: polu nagłówka, opisie, pasku bocznym Assignees/Labels/Type — Formularz Issue w GitHub, w którym sformułowano Issue #9 repozytorium SafeSort.

Oddział feat/duplicate-detection

Prace nad Issue #9 prowadzono w odosobnionej gałęzi. Ta sama technika była stosowana w każdy punkt kontrolny Część IV:

Terminal

git switch -c feat/duplicate-detection
# ...пишем код и тесты, коммитим изменения...
git push -u origin feat/duplicate-detection

Pull Request #20: Co uratowało GitHub

Przyjrzyjmy się danym repozytorium Cartesian-School/safesort:

Field PR #20	Znaczenie w rzeczywistości
Nagłówek	feat: add duplicate detection with byte-level confirmation
Gałąź → main	feat/duplicate-detection → main
Commits	1 zobowiązanie; cały Issue #9 mieści się w jednej logicznej zmianie
Files changed	2 pliki: src/safesort/duplicates.py (+113), tests/test_duplicates.py (+144)
Conversation	„Closes #9”
Checks	test: pass, 11s (workflow safesort-tests.yml)
Review	w edukacyjnym PR nie było osobnego reviewer; to fakt historyczny, a nie model do pracy zespołowej
Decyzja o fuzji	Merged zwykłym merge commit 01989e0c, ani squash, ani rebase

Cztery zakładki i dwa różne rodzaje sprawdzania

Tab	Na jakie pytanie odpowiada
Conversation	tego, co było omawiane, co Issue jest zamykane, jaki jest rezultat review
Commits	z jakich zapisanych kroków składa się gałąź?
Checks	przeszły automatyczne workflow i testy
Files changed	co dokładnie proponuje się dodać, zmienić lub usunąć

Reviewer czyta zmiany i może zostawić comment, wybierz Approve lub Request changes. CI odpowiedzi "czy zdałeś automatyczne kontrole?", a osoba odpowiada: "czy ta zmiana powinna być zaakceptowana?". Ani jedno z tych Zielony Checks nie zastępuje review inżynieryjnego, ani review nie zastępuje powtarzalnych testów.

zakładka Files changed tym repozytorium Pull Request Cartesian-School/safesort: dodanym plikom duplicates.py, Merged status — Pull Request SafeSort „Add duplicate detection with byte-level confirmation”, zamykający Issue nr 9.

Jeden PR nie zawsze odpowiada jednemu Issue

PR #20 pokazuje prosty przypadek: jedna gałąź, jeden commit, jeden Issue, automatycznie zamknięty frazą Closes #9 podczas scalania. W historii SafeSort pojawiają się również inne warianty: jeden PR może zamknąć dwa powiązane Issue (strony 23-11 i 23-14 pokazują taki przykład), i Issues zamknięte ręcznie bez oddzielnego PR wcale (strony 23-20 i 23-22).

PR można otworzyć zanim kod będzie w pełni gotowy

Pull Request nie musi przesyłać już ukończonych prac. Można je otworzyć wcześniej, aby omówić podejście lub uzyskać tymczasowe opinie, i wyraźnie oznaczyć jako szkic. Czekanie „aż wszystko będzie idealne”

Krótko

PR #20 pokazuje ten sam cykl Issue, gałęzi i Pull Request, który został podzielony w części II.
Files changed, Commits, Checks i Conversation pokazują 2 pliki, 1 commit, zielony check, oraz „Closes #9”
Jeden PR może zamknąć kilka Issues; Issue można też zamknąć ręcznie bez PR.