Git

• Förvarstjänster: Alla jobb som berör ett Git-repo — skapa grenar, mellanlagra ändringar, göra commits, pusha eller öppna pull requests.
• Teamsamarbete: När historikens integritet är viktig och du behöver feature-branch-flöden, hotfix-arbetsflöden eller PR-redo commit-hygien som tillämpas automatiskt.
• Felsökning av historik: När du behöver spåra regressioner med git bisect, återställa förlorade commits via git reflog eller ångra ändringar på ett säkert sätt.
• Konfliktlösning: När sammanslagningar eller ombasering orsakar konflikter och agenten behöver ett strukturerat, verifierat tillvägagångssätt för att lösa dem.

• Versionskontroll som inte är Git: Om projektet använder Mercurial, SVN eller ett annat VCS kommer inte den här skickligheten kommandon att vara tillämpliga.
• Skrivskyddade analysuppgifter: Om agenten bara behöver läsa källkod utan att interagera med Git alls, tillför skickligheten onödig overhead.

Färdigheten tillämpar --force-with-lease framför --force för att förhindra att kollegors arbete skrivs över, och förbjuder force-push till delade grenar som main/master. En inbyggd säkerhetschecklista måste vara uppfylld innan någon destruktiv åtgärd utförs, såsom reset --hard eller rebase.

Inkluderar steg-för-steg-flöden för scenarierna Feature Branch och Hotfix, inklusive när man ska squasha commits, hur man synkroniserar med git fetch --all --prune och hur man taggar releaser. Utformat för att passa både trunk-baserade team och team som arbetar med gitflow-stil.

Efter att ha redigerat filer med konflikter kontrollerar skickligheten att inga konfliktmarkörer återstår med hjälp av grep, bekräftar att koden bygger korrekt och erbjuder en nödutgång via git merge --abort när en sammanslagning blir alltför komplex. Ombasering föreslås som ett alternativ när sammanslagningar blir röriga.

Täcker git reflog för att återställa förlorade commits (upp till ~90 dagar), återskapa raderade grenar via SHA, och ångra commits utan att förlora arbete med hjälp av git reset --soft. Inkluderar även ett komplett git bisect-arbetsflöde för att identifiera vilken commit som introducerade en regression.

Skickligheten kräver commit-meddelandeformatet type(scope): description med en första rad på under 72 tecken, med hjälp av standardtyper (feat, fix, docs, refactor, osv.). Detta håller historiken läsbar och kompatibel med automatiserade verktyg för ändringsloggar.

Dokumenterar och skyddar mot vanliga Git-fallgropar: frånkopplat HEAD-tillstånd, skiftlägeskänslighet mellan macOS/Windows och Linux CI, fel vid kloning av submoduler, konflikter vid stash-pop samt incheckning av stora filer eller hemligheter. Använd git add -p för detaljerad partiell staging.

En agent skapar en struktur för en ny funktion, skapar en gren från main, gör inkrementella commits med konventionella meddelanden, rebasear mot den senaste main innan uppladdning, squashar fixup-commits och öppnar en PR-redo gren — allt utan manuell Git-intervention.

När ett produktionsfel upptäcks checkar agenten ut en hotfix/-gren från main, tillämpar fixen, slår ihop den med både main och develop, taggar releasen och rensar upp grenen — i enlighet med det dokumenterade hotfix-flödet.

Agenten kör git bisect för att binärsöka genom commit-historiken och markerar commits som bra eller dåliga baserat på automatiserade testresultat, tills den identifierar exakt vilken commit som introducerade en bugg.

Under en långvarig funktions-rebase löser agenten konflikter fil för fil, verifierar att inga <<</>>>-markörer kvarstår, bekräftar att bygget lyckas och fortsätter rebasen — eller avbryter på ett kontrollerat sätt om konflikten är alltför komplex.