Pull requests och kodgranskning

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 pull request (PR) föreslår att ändringar i en gren ska slås ihop med en annan. På GitLab heter motsvarande arbetsflöde merge request (MR). Granskningen handlar inte bara om diffen utan också om syfte, korrekthet, testning, felhantering, säkerhet och om andra kan underhålla lösningen.

Skapa en granskningsförfrågan

GitHub Desktop

1. Gör commit och publicera feature-grenen.
2. Välj Preview Pull Request eller Create Pull Request om valet visas.
3. Kontrollera att base är main och att din feature-gren jämförs mot den.
4. Desktop öppnar GitHub i webbläsaren där du kompletterar beskrivning, etiketter, granskare och eventuell draft-status.
5. För GitLab skapar du i stället en merge request via GitLabs webbgränssnitt.

Git CLI

git status --short --branch
git fetch origin
git log --oneline origin/main..HEAD
git diff --stat origin/main...HEAD
git push -u origin feature/42-inventory
# Valfritt med separat installerad och inloggad GitHub CLI:
gh pr create --base main --head feature/42-inventory --draft

På GitLab använder du webbgränssnittet eller den separat installerade glab. Grundprogrammet git hanterar inte GitHub-ärenden eller pull requests.

Skriv en användbar beskrivning

Förklara vad som ändrades, varför, hur det testades och vilka risker som finns. Koppla relevanta ärenden och beskriv hur fel kan återskapas. Bifoga skärmbilder när de ger granskaren förståelse. Vid migreringar behöver ordning för driftsättning och rollback dokumenteras. Publicera aldrig hemligheter i en öppen PR.

Granskning, tester och sammanslagning

Se Merge commit, squash eller rebase? för historik före/efter, fördelar och nackdelar samt skillnaden mellan lokal integration och en PR/MR.

Granskaren bör kontrollera viktiga kodvägar och specialfall. CI kan hitta byggfel och automatiska regressioner, men kan inte ersätta mänsklig granskning. Använd obligatoriska kontroller och skyddade grenar som faktiska spärrar.

Merge commit bevarar grenens sammanslagningspunkt. Squash merge samlar branchens arbete i en commit. Rebase merge placerar om commits för en mer linjär historik. Välj en teamstandard medvetet och skriv inte om andras publicerade arbete enbart för snygg historik. Kontrollera efteråt vilken commit som faktiskt driftsatts.

Fortsätt med grenar, konflikter och GitHubs Desktop-guide.

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