Ett bra dagligt Git-arbetsflöde

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.

En återkommande rutin gör samarbetet mindre beroende av vem som minns vad. Börja med ett ärende som beskriver problemet, acceptanskriterier och hur resultatet ska kontrolleras. Skapa en kortlivad gren som kopplas till ärendet, ändra bara det uppgiften kräver och skriv commits som förklarar varför något ändrades.

Granska, stagea och gör commit

GitHub Desktop

1. Kontrollera att Current Branch visar rätt feature-gren.
2. Läs ändringarna i Changes fil för fil innan du väljer vad som ska ingå.
3. Avmarkera orelaterade filer. Lägg inte in autentiseringsuppgifter, byggfiler eller lokala IDE-inställningar av misstag.
4. Skriv en tydlig sammanfattning, exempelvis Add inventory slot validation, och motivera ändringen i beskrivningen.
5. Välj Commit to feature/42-inventory. Skapa fler commits om arbetet består av separata steg.
6. Använd Push origin för att publicera grenens commits.

Git CLI

git status --short --branch
git diff --check
git diff
git add src/Inventory.cs
git diff --cached
git commit -m "Add inventory slot validation"
git push -u origin feature/42-inventory

src/Inventory.cs är en exempelväg. Välj enskilda ändringar med git add -p. Använd inte slentrianmässigt git add . om arbetskatalogen innehåller annat arbete.

Kör projektets tester

En commit bevisar inte att funktionen fungerar. Kör de tester och byggkontroller som gäller för repositoryt. I Unity behöver du även prova scener och serialisering. Infrastrukturförändringar bör valideras och gärna testas med dry run. Om CI misslyckas ska du läsa den felande loggen innan du försöker igen.

Begär kodgranskning

Öppna gärna en draft pull request tidigt för återkoppling. Beskriv ändringen, länka ärendet (på GitHub exempelvis Closes #42 när det är lämpligt), ange teststeg och bifoga bara skärmbilder som verkligen visar något viktigt. Granskaren måste kunna återskapa och kontrollera resultatet.

En trygg grundrutin är liten ändring → lokalt test → push → granskning → CI → merge → release. Sammanslagning är inte samma sak som driftsättning: kontrollera pipeline och notera vilken commit som faktiskt körs.

När är arbetet färdigt?

Kan en kollega hitta ärendet, förstå beslutet, köra kontrollerna och se vilken release som innehåller ändringen? Då har du skapat verklig spårbarhet. Läs vidare om pull requests och från ärende till release.

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