Genomgång: från ärende till release

↑

CLI-exempel märkta Bash fungerar i Git Bash på Windows 10 och Windows 11 eller Bash på Linux, med Git installerat. Bash-tilldelningar som DEFAULT_BRANCH=main är kommandotolkens syntax; kör exemplen i Git Bash i stället för att klistra in dem i PowerShell eller Kommandotolken.

Exemplet använder ett påhittat spelprojekt. Teamet vill förhindra att föremål dupliceras när en spelare återansluter till en multiplayer-session. Vi håller main skyddad och spårar exakt vilken ändring och release som löste felet. Principerna fungerar även för API:er, Unity-projekt och dokumentationswebbplatser.

1. Ärendet och acceptanskriterierna

Skapa Issue #42: Inventory duplicates after reconnect. Beskriv reproduktionssteg, förväntat beteende och acceptanskriterier: två återanslutningar får inte skapa fler än en instans av varje server-auktoritativt föremål; ett automatiskt test ska täcka fallet; tidigare sparad data ska fortfarande gå att läsa. Lägg ärendet i GitHub Projects med Ready, High och Gameplay.

Kontrollera att lokala ändringar är sparade. Byt till main, hämta senaste ändringarna, välj Current Branch → New Branch, skriv fix/42-reconnect-duplicates och skapa från main. Publicera grenen när första ändringen är klar.

git status --short --branch
git switch main
git pull --ff-only origin main
git switch -c fix/42-reconnect-duplicates
git branch --show-current

Kontrollera att arbetskatalogen är ren innan du byter gren. Namnen är exempel och kommandon ska köras i ett repository du själv kontrollerar.

3. Implementera en avgränsad rättning

Skriv först ett regressionstest för återanslutningen. Ändra sedan föremålens synkronisering så att serverns item-ID, inte ordningen i meddelandet, avgör om ett föremål redan finns. Undvik att samtidigt skriva om orelaterade menyer eller nätverkskod. Kör tester och prova flödet manuellt.

GitHub Desktop
Git CLI

Läs diffen i Changes, markera endast relevanta filer och gör en commit med rubriken Prevent duplicate items during reconnect. Använd Push origin. Kontrollera i History att ändringen motsvarar ärendets omfattning.

git diff --check
git diff
git add src/Inventory.cs tests/InventoryTests.cs
git diff --cached
git commit -m "Prevent duplicate items during reconnect"
git push -u origin fix/42-reconnect-duplicates

Filvägarna är exempel. Anpassa dem till projektet och kör de verkliga testerna före push.

4. Granskning och pull request

Skapa en pull request via GitHub Desktop som öppnar GitHub i webbläsaren, eller använd GitHub-webben eller den autentiserade gh-klienten. Koppla Closes #42 när det är lämpligt, beskriv testningen och ange eventuell migreringsrisk. Begär granskning, vänta på obligatoriska kontroller och svara på feedback. För GitLab används en merge request med samma kvalitetsmål.

5. Merge och verifierad release

Slå ihop till skyddad main efter godkännande. Kontrollera att CI passerar, notera release-ID och verifiera exakt vilken commit som körs i miljön. Att flytta projektkortet till Done bevisar inte att driftsättningen lyckades. Koppla release, pipeline och commit så att informationen kan hittas senare.

6. Om ett nytt fel upptäcks

Identifiera första felande driftsättning och jämför dess SHA med den senaste kända fungerande versionen. Granska PR-historik och använd git bisect i en ren klon om orsaken är oklar. Skapa en separat granskad rättning eller revert, kör tester och driftsätt det kontrollerade resultatet. Dokumentera händelsen i ärendet.

Spårbarhetsövning: Kan du gå från Issue #42 till gren, commits, granskning, pipeline och driftsatt SHA, och sedan tillbaka? Om inte saknas en länk i arbetsflödet.

Fortsätt med historik och återställning och GitHub Projects.

Grennamn: main används som exempel. Använd master eller projektets verkliga standardgren där det behövs. Se Git-begrepp.