Migrera till Git från centraliserad versionskontroll

Att migrera ett team till Git från centraliserad versionskontroll kräver mer än att bara lära sig nya kommandon. För att stödja distribuerad utveckling lagrar Git filhistorik och greninformation på ett annat sätt än ett centraliserat versionskontrollsystem. Planering och implementering av en lyckad migrering till Git från ett centraliserat versionskontrollsystem kräver att du förstår dessa grundläggande skillnader.

Microsoft har hjälpt till att migrera många interna team och kunder från centraliserade versionskontrollsystem till Git. Den här upplevelsen har tagit fram följande vägledning baserat på metoder som konsekvent lyckas.

Steg för lyckad migrering

För en lyckad migrering bör teamen:

• Utvärdera aktuella verktyg och processer.
• Välj en Git-förgreningsstrategi.
• Besluta om och hur du ska migrera historikdata.
• Underhåll det tidigare versionskontrollsystemet.
• Ta bort binära filer, körbara filer och verktyg från källkontrollen.
• Träna team i Git-begrepp och -metoder.
• Testa migreringen till Git.

Utvärdera aktuella verktyg och processer

Att ändra versionskontrollsystem stör naturligtvis utvecklingsarbetsflödet med nya verktyg och metoder. Den här störningen kan vara en möjlighet att förbättra andra aspekter av DevOps-processen.

Teams bör överväga att använda följande metoder när de migrerar till det nya systemet:

• Kontinuerlig integrering (CI) där varje incheckning utlöser ett bygg- och testpass. CI hjälper till att identifiera defekter tidigt och ger ett starkt säkerhetsnät för projekt.

• Nödvändiga kodgranskningar innan du checkar in kod. I Git-förgreningsmodellen är pull-begärandekodgranskning en del av utvecklingsprocessen. Kodgranskningar kompletterar CI-arbetsflödet.

• Kontinuerlig leverans (CD) för att automatisera distributionsprocesser. Ändring av versionskontrollverktyg kräver ändringar i distributionsprocessen, så en migrering är ett bra tillfälle att införa en modern versionspipeline.

Välj en Git-förgreningsstrategi

Innan du migrerar kod bör teamet välja en förgreningsstrategi.

I Git gör kortlivade ämnesgrenar att utvecklare kan arbeta nära huvudgrenen och integrera snabbt, vilket undviker sammanslagningsproblem. Två vanliga ämnesgrensstrategier är GitFlow och en enklare variant, GitHub Flow.

Git avråder från långlivade, isolerade funktionsgrenar, vilket tenderar att fördröja sammanslagningar tills integreringen blir svår. Genom att använda moderna CD-tekniker som funktionsflaggor kan team snabbt integrera kod i huvudgrenen, men ändå hålla pågående funktioner dolda för användarna tills de är klara.

Team som för närvarande använder en långlivad funktionsgrensstrategi kan använda funktionsflaggor innan de migreras till Git. Att använda funktionsflaggor förenklar migreringen genom att minimera antalet grenar som ska migreras. Oavsett om de använder funktionsgrenar eller funktionsflaggor bör team dokumentera mappningen mellan äldre grenar och nya Git-grenar, så att alla förstår var de ska genomföra sitt nya arbete.

Bestäm om du vill migrera historik

Teams kan frestas att migrera sin befintliga källkodshistorik till Git. Flera verktyg hävdar att de migrerar en fullständig historik över alla grenar från ett centraliserat verktyg till Git. En Git-commit passar relativt bra ihop med den ändringsuppsättning eller incheckningsmodell som det tidigare versionskontrollverktyget använde.

Den här mappningen har dock vissa allvarliga begränsningar.

• I de flesta centraliserade versionskontrollsystem finns grenar som mappar på lagringsplatsen. Huvudgrenen kan till exempel vara en mapp med namnet /trunk, och andra grenar är mappar som /branch/one och /branch/two. På en Git-lagringsplats innehåller grenar hela lagringsplatsen, så en 1:1-översättning är svår.

• I vissa versionskontrollsystem är en tagg eller etikett en samling som kan innehålla olika filer i trädet, även filer i olika versioner. I Git är en tagg en ögonblicksbild av hela lagringsplatsen vid en viss tidpunkt. En tagg kan inte representera en delmängd av lagringsplatsen eller kombinera filer i olika versioner.

• De flesta versionskontrollsystem lagrar information om hur filer ändras mellan versioner, inklusive detaljerade ändringstyper som byt namn, ta bort borttagning och återställning. Git lagrar versioner som ögonblicksbilder av hela lagringsplatsen och metadata om hur filer som har ändrats inte är tillgängliga.

Dessa skillnader innebär att en fullständig historikmigrering i bästa fall blir förlustfylld och eventuellt vilseledande. Med tanke på förlust, ansträngningen och den relativa sällsyntheten i att använda historik rekommenderar vi att de flesta team undviker att importera historik. Teamen bör i stället utföra en tipsmigrering och endast ta med en ögonblicksbild av den senaste grenversionen till Git. För de flesta team spenderas tid bäst på områden i migreringen som har högre avkastning på investeringar, till exempel att förbättra processer.

Underhålla det gamla versionskontrollsystemet

Under och efter en migrering kan utvecklare fortfarande behöva åtkomst till den tidigare versionskontrollhistoriken. Även om den tidigare versionskontrollhistoriken blir mindre relevant över tid är det fortfarande viktigt att kunna referera till den. Strikt reglerade miljöer kan ha specifika juridiska krav och granskningskrav för versionskontrollhistorik.

Särskilt för team som bara utför en tipsmigrering rekommenderar vi starkt att du underhåller det tidigare systemet på obestämd tid. Ange det gamla versionskontrollsystemet till skrivskyddat när du har migrerat.

Stora utvecklingsteam och reglerade miljöer kan placera sökvägar i Git som pekar tillbaka till det gamla versionskontrollsystemet. Ett enkelt exempel är en textfil som läggs till som den första commit i roten på ett Git-repositorium, före tip-migreringen, och som pekar på URL:en för den gamla versionskontrollservern. Om många grenar migreras bör en textfil i varje gren förklara hur grenarna migrerades från det gamla systemet. Sökvägar är också användbara för utvecklare som börjar arbeta med ett projekt efter att det har migrerats och inte är bekanta med det gamla versionskontrollsystemet.

Ta bort binära filer och verktyg

Gits lagringsmodell är optimerad för versionshantering av textfiler och källkod, som är kompakta och mycket komprimerbara. Binära filer är vanligtvis stora och när de läggs till på en lagringsplats finns de kvar i lagringsplatsens historik och i varje framtida klon. På grund av hur Git lagrar historik bör utvecklare undvika att lägga till binära filer till lagringsplatser, särskilt binärfiler som är mycket stora eller som ändras ofta. Att migrera till Git är en möjlighet att ta bort dessa binärfiler från kodbasen.

Vi rekommenderar också att du exkluderar bibliotek, verktyg och skapar utdata från lagringsplatser. Använd i stället pakethanteringssystem som NuGet för att hantera beroenden.

Tillgångar som ikoner och konstverk kan behöva justeras med en viss version av källkoden. Små, sällan ändrade tillgångar som ikoner sväller inte upp historiken och du kan inkludera dem direkt i en lagringsplats. Om du vill lagra stora eller ofta föränderliga tillgångar använder du LFS-tillägget (Git Large File Storage). Mer information om hur du hanterar stora filer i GitHub finns i Hantera stora filer. Information om Azure-lagringsplatser finns i Hantera och lagra stora filer i Git.

Tillhandahålla utbildning

En av de största utmaningarna med att migrera till Git är att hjälpa utvecklare att förstå hur Git lagrar förändringar och hur åtaganden bildar utvecklingshistorik. Det räcker inte att förbereda ett fuskark som mappar gamla kommandon till Git-kommandon. Utvecklare måste sluta tänka på versionskontrollhistoriken när det gäller en centraliserad, linjär modell och förstå Gits historikmodell och incheckningsgrafen.

Människor lär sig på olika sätt, så du bör tillhandahålla flera typer av utbildningsmaterial. Live, labbbaserad utbildning med en expertinstruktör fungerar bra för vissa människor. Pro Git-boken är en utmärkt utgångspunkt som är tillgänglig gratis online.

Tillgängliga kostnadsfria praktiska utbildningar är:

• Introduktion till versionskontroll med Git-utbildningsväg .
• Snabbstarten Kom igång med Git i Azure Repos .
• GitHubs Git- och GitHub-utbildningsresurser.

Organisationer bör arbeta för att identifiera Git-experter i team, ge dem möjlighet att hjälpa andra och uppmuntra andra teammedlemmar att ställa frågor till dem.

Testa migreringen

När teamen uppdaterar sina processer, analyserar sin kod och tränar sina medlemmar är det dags att migrera källkoden. Oavsett om du utför en tipsmigrering eller migrerar historik är det viktigt att göra en eller flera testmigreringar till en testlagringsplats. Innan du gör en slutlig migrering måste du se till att:

• Alla kodfiler migreras.
• Alla grenar är tillgängliga.
• Det finns inga herrelösa binärfiler på lagringsplatsen.
• Användarna har rätt behörighet att hämta och push-överföra.
• Byggen lyckas och alla tester godkänns.

Migrera koden

Utför den slutliga migreringen under icke-arbetstimmar, helst mellan milstolpar när det finns naturlig stilleståndstid. Migrering i slutet av en sprint kan orsaka problem medan utvecklare försöker slutföra arbetet. Försök att migrera under en helg, när ingen behöver checka in.

Planera för en bestämd övergång från det gamla versionskontrollsystemet till Git. Att försöka köra flera system parallellt innebär att utvecklare kanske inte vet var eller hur de ska checka in. Sätt det gamla versionskontrollsystemet till skrivskyddat läge för att undvika förvirring. Utan detta skydd kan en andra migrering som omfattar interimsändringar vara nödvändig.

Den faktiska migreringsprocessen varierar beroende på vilket system du migrerar från. Information om hur du migrerar från Team Foundation Version Control finns i Migrera från TFVC till Git.

Checklista för migrering

Teamarbetsflöden:

Förgreningsstrategi:

History:

Binärfiler och verktyg:

Träning:

Kodmigrering:

Nästa steg

• Migrera till Azure DevOps från Team Foundation Server
• Så här mappar TFVC-kommandon och arbetsflöden till Git