Lös merge-konflikter utan dataförlust

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 konflikt uppstår när Git inte själv kan kombinera två historiker, ofta för att samma rader har ändrats i olika grenar eller för att en gren raderat en fil som den andra redigerat. En konflikt betyder att du måste fatta ett beslut, inte att Git ska tvingas vidare. Verktyget kan inte veta vilket beteende teamet vill ha.

Innan du börjar

Testa grenen, spara lokala ändringar och hämta målgrenens senaste historik. Gör en säker kopia av värdefullt arbete innan mer avancerade historikändringar. Följ teamets regel för merge eller rebase. Rebase ändrar commit-ID:n och är olämpligt på delade grenar utan samordning.

GitHub Desktop

1. Välj feature-grenen och använd Fetch origin.
2. Under Current Branch använder du funktionen för att mergea main in i din gren, om teamet använder merge.
3. Om Desktop visar konflikter öppnar du filerna i den editor som är konfigurerad.
4. Kombinera de ändringar som ska finnas kvar, spara och markera konflikterna som lösta.
5. Slutför merge, kör tester och använd Push origin.

Välj inte slentrianmässigt att behålla en hel fil när båda grenarnas ändringar behövs.

Git CLI

git status --short --branch
git fetch origin
git merge origin/main
# Vid konflikt: läs status och redigera filerna omsorgsfullt.
git status
git diff --check
git add path/to/resolved-file
git commit
# För att avbryta en oavslutad merge, om det är säkert:
# git merge --abort

git merge --abort gäller bara en pågående merge och bör användas med förståelse för lokala ändringar. Filvägen är ett exempel.

Konfliktmarkörer

Git kan lägga in <<<<<<<, ======= och >>>>>>> för att visa två varianter. Det är inte giltig slutlig kod. Redigera filen till den önskade sammanslagningen och ta bort markörerna. Kontrollera även tester, beroenden och genererade filer.

Säker återhämtning

Om du tappar överblicken, avbryt arbetet och läs git status. Ta hjälp hellre än att återställa historiken på chans. Säkra ospårat arbete innan destruktiva operationer. Använd inte git reset --hard eller git push --force som rutinlösningar: de kan radera lokalt arbete eller ersätta gemensam historik.

Läs GitHubs konfliktreferens och fortsätt med historik och återställning.

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