SVN naar Git - voorbereiden op de migratie

De migratiescripts van Atlassian

Als je een abrupte transitie naar Git wilt maken, zijn de migratiescripts van Atlassian een goede keuze. Deze scripts bieden alle tools die je nodig hebt om je bestaande SVN-repository's betrouwbaar om te zetten naar Git-repository's. De resulterende native Git-geschiedenis zorgt ervoor dat je na de overstap geen problemen meer hebt met de SVN-naar-Git interoperabiliteit.

We hebben een complete technische handleiding gemaakt om deze scripts te gebruiken om je hele codebase om te zetten naar een verzameling Git-repository's. In deze handleiding wordt alles uitgelegd, van het extraheren van SVN-auteursinformatie tot het reorganiseren van niet-standaard SVN-repositorystructuren.

Plug-in SVN Mirror for Stash (nu Bitbucket)

SVN Mirror for StashSVN Mirror for Stash is een Bitbucket-plug-in waarmee je eenvoudig een hybride codebase kunt onderhouden die zowel met SVN als Git werkt. In tegenstelling tot de migratiescripts van Atlassian, kun je met SVN Mirror for Stash Git en SVN tegelijkertijd gebruiken voor hetzelfde project, zolang je wilt.

Deze compromisoplossing is een geweldige optie voor grotere bedrijven. Het maakt een incrementele acceptatie van Git mogelijk door verschillende teams hun workflows te laten migreren wanneer het hen uitkomt.

Wat is Git-SVN?

De git-svn-tool is een interface tussen een lokale Git-repository en een externe SVN-repository. Met Git-svn kunnen ontwikkelaars lokaal code schrijven en commits maken met Git, en ze vervolgens naar een centrale SVN-opslagplaats pushen met gedrag in de stijl van svn commit. Dit zou tijdelijk moeten zijn, maar is nuttig als er nog discussie is over de overstap van SVN naar Git.

git svn is een goede optie als je niet zeker bent over de overstap naar Git en een aantal van je ontwikkelaars Git-opdrachten wilt laten verkennen zonder een volledige migratie uit te voeren. Het is ook perfect voor de trainingsfase. In plaats van een abrupte transitie kan je team dit eenvoudig uitvoeren met lokale Git-opdrachten voordat ze zich zorgen hoeven te maken over samenwerkingsworkflows.

Let op: git svn zou slechts een tijdelijke fase van je migratieproces moeten zijn. Aangezien het nog steeds afhankelijk is van SVN voor de backend, kan het niet gebruikmaken van de krachtigere Git-functies, zoals branching of geavanceerde samenwerkingsworkflows.

Implementatiestrategieën

Het migreren van je codebase is maar één aspect van de overstap naar Git. Je moet ook bedenken hoe je Git wilt introduceren bij degenen die achter de codebase zitten. Externe consultants, interne Git-kampioenen en pilotteams zijn de drie belangrijkste strategieën om je devteam over te laten stappen naar Git.

Externe Git-consultants

Git-consultants kunnen in principe het migratieproces voor je afhandelen tegen een kleine vergoeding. Dit heeft het voordeel dat ze een Git-workflow aanmaken die perfect is afgestemd op je team, zonder dat je er tijd in hoeft te investeren om het zelf allemaal uit te zoeken. Ze stellen je ook trainingsmateriaal van experts ter beschikking terwijl je team Git leert te gebruiken. Atlassian Partners zijn professionals als het gaat om de migratie van SVN naar Git en kunnen je helpen een Git-consultant te vinden.

Aan de andere kant is het zelf ontwerpen en implementeren van een Git-workflow een geweldige manier voor je team om de interne werking van hun nieuwe ontwikkelingsproces te leren begrijpen. Dit voorkomt dat je team niet weet waar het over gaat wanneer je consultant eenmaal vertrokken is.

Interne Git-kampioenen

Een Git-kampioen is een ontwikkelaar binnen je bedrijf die er veel zin in heeft om Git te gaan gebruiken. Het inzetten van een Git-kampioen is een goede optie voor bedrijven met een sterke ontwikkelaarscultuur en enthousiaste programmeurs die het prettig vinden om vroege gebruikers te zijn. Het idee is om een van je engineers in staat te stellen een Git-expert te worden, zodat ze een Git-workflow kunnen ontwerpen die is afgestemd op je bedrijf en als intern consultant kunnen fungeren wanneer het tijd is voor de transitie van de rest van het team naar Git.

Vergeleken met een externe consultant heeft dit het voordeel dat je Git-kennis intern blijft. Het vraagt echter om een grotere tijdsinvestering om die Git-kampioen op te leiden, en het risico bestaat dat de verkeerde Git-workflow wordt gekozen of deze verkeerd wordt geïmplementeerd.

Pilotteams

De derde optie om over te stappen naar Git is om het te testen in een pilotteam. Dit werkt het beste als je een klein team hebt dat aan een relatief geïsoleerd project werkt. Dit zou nog beter kunnen werken door externe consultants te combineren met interne Git-kampioenen in het pilotteam voor een geslaagde combinatie.

Dit heeft het voordeel dat je een buy-in van je hele team vereist, en beperkt ook het risico dat je de verkeerde workflow kiest, aangezien het input van het hele team vereist bij het ontwerpen van het nieuwe ontwikkelingsproces. Met andere woorden, het zorgt ervoor dat ontbrekende stukjes sneller worden gevonden dan wanneer een consultant of kampioen de nieuwe workflow zelf ontwerpt.

Aan de andere kant betekent het inzetten van een pilotteam meer training vooraf en tijd die verloren gaat aan opzetten: in plaats van dat één ontwikkelaar een nieuwe workflow uitstippelt, is er een heel team dat mogelijk tijdelijk minder productief kan zijn terwijl ze vertrouwd raken met hun nieuwe workflow. Deze kortdurende last is echter absoluut de winst op lange termijn waard.

Beveiliging en rechten

Toegangsbeheer is een aspect van Git waarbij je fundamenteel moet heroverwegen hoe je je codebase beheert.

In SVN sla je doorgaans je volledige codebase op in één centrale repository en beperk je vervolgens de toegang per map tot verschillende teams of personen. In Git is dit niet mogelijk: ontwikkelaars moeten de volledige repository ophalen om ermee te kunnen werken. Je kunt gewoonlijk niet een subset van de repository ophalen, zoals dat wel kan met SVN. Rechten kunnen alleen worden verleend aan volledige Git-repository's.

Dit betekent dat je je grote, monolithische SVN-repository moet opsplitsen in verschillende kleine Git-repository's. We hebben dit eigenlijk uit de eerste hand ervaren hier bij Atlassian toen ons ontwikkelingsteam van Jira naar Git migreerde. Al onze Jira-plug-ins werden vroeger opgeslagen in een enkele SVN-repository, maar na de migratie kwam elke plug-in in zijn eigen repository terecht.

Onthoud dat Git is ontworpen om codebijdragen van duizenden onafhankelijke Linux-ontwikkelaars veilig te integreren. Je kunt dus elk soort toegangsbeheer instellen dat je team nodig heeft. Dit kan er echter voor zorgen dat je op een andere manier naar je bouwcyclus moet kijken.

Als je je zorgen maakt over het behoud van afhankelijkheden tussen je nieuwe verzameling Git-repository's, vind je een laag voor afhankelijkheidsbeheer bovenop Git misschien nuttig. Een laag voor afhankelijkheidsbeheer helpt bij het opbouwen van een project, want naarmate een project groeit, heb je 'caching' nodig om sneller te kunnen bouwen. Een lijst van aanbevolen tools voor de laag voor afhankelijkheidsbeheer voor elke technologiestack is te vinden in dit handige artikel: Git en projectafhankelijkheden.

Een repository voor elke ontwikkelaar

Als ontwikkelaar is de grootste verandering waar je je aan moet aanpassen het gedistribueerde karakter van Git. In plaats van een enkele centrale repository heeft elke ontwikkelaar zijn eigen exemplaar van de volledige repository. Dit is een ingrijpende verandering van de manier waarop je samenwerkt met je medeprogrammeurs.

In plaats van een SVN-repository uit te checken met svn checkout en een werkkopie te krijgen, kloon je de volledige Git-repository naar je lokale apparaat met git clone.

Samenwerking vindt plaats door branches tussen repository's te verplaatsen met git push, git fetch of git pull. Het delen van gegevens gebeurt gewoonlijk op branch-niveau in Git, maar kan op commit-niveau worden gedaan, vergelijkbaar met SVN. Maar in Git vertegenwoordigt een commit in plaats daarvan de volledige status van het hele project in plaats van bestandswijzigingen. Aangezien je in zowel Git als SVN branches kunt gebruiken, is het belangrijke verschil hier dat je lokaal kunt committeren met Git, zonder je werk te delen. Dit stelt je in staat om vrijer te experimenteren en effectiever offline te werken, en versnelt bijna alle opdrachten met betrekking tot versiebeheer.

Het is echter belangrijk om te begrijpen dat een externe repository geen directe link is naar de repository van iemand anders. Het is gewoon een bladwijzer die voorkomt dat je elke keer de volledige URL opnieuw hoeft in te voeren wanneer je met een externe repository werkt. Totdat je uitdrukkelijk een branch naar een externe repository pullt of pusht, werk je in een geïsoleerde omgeving.

De andere grote verandering voor SVN-gebruikers zijn de begrippen 'lokale' en 'externe' repository's. Lokale repository's bevinden zich op je lokale computer, en alle andere repository's worden externe repository's genoemd. Het belangrijkste doel van een externe repository is om je code toegankelijk te maken voor de rest van het team, en daarom wordt er in die bestanden niet actief ontwikkeld. Lokale repository's bevinden zich op je lokale computer. Daar voer je al je softwareontwikkeling uit.

Wees niet bang voor branching of samenvoegingen

In SVN commit je code door de bestanden in je werkkopie te bewerken en vervolgens svn commit uit te voeren om de code naar de centrale repository te sturen. Alle anderen kunnen die wijzigingen vervolgens in hun eigen werkkopieën pullen met svn update. SVN-branches worden meestal gereserveerd voor grote, langlopende aspecten van een project, omdat een fusie een gevaarlijke procedure is waarop het project kan stuklopen.

De basisworkflow voor ontwikkeling van Git is heel anders. In plaats van gebonden te zijn aan een enkele ontwikkelingslijn (bijv. trunk/), draait het leven om branches en samenvoegen.

Als je aan iets in Git wilt beginnen te werken, creëer en bekijk je een nieuwe branch met git checkout -b . Dit geeft je een speciale ontwikkelingslijn waar je code kunt schrijven zonder je zorgen te hoeven maken dat het invloed heeft op iemand anders in je team. Als je iets kapot maakt dat niet meer te repareren valt, gooi je de branch gewoon weg met git branch -d . Als je iets nuttigs bouwt, dien je een pull request in met de vraag om de branch samen te voegen met de main-branch.

Potentiële Git-workflows

Bij het kiezen van een Git-workflow is het belangrijk om rekening te houden met de behoeften van je team. Een eenvoudige workflow kan de ontwikkelingssnelheid en flexibiliteit maximaliseren, terwijl een complexere workflow kan zorgen voor meer consistentie en controle over werk in uitvoering. Je kunt de hieronder vermelde algemene benaderingen aanpassen en combineren om aan je behoeften en de verschillende rollen in je team te voldoen. Een core developer kan functie-branches gebruiken terwijl een aannemer bijvoorbeeld vanuit een vertakking werkt.

• Een gecentraliseerde workflow komt het best overeen met veelvoorkomende SVN-processen, dus het is een goede optie om mee te beginnen.
• Voortbouwend op dat idee kunnen ontwikkelaars met behulp van een workflow voor functie-branches hun werk in uitvoering geïsoleerd houden en belangrijke gedeelde branches beschermen. Functie-branches vormen ook de basis voor het beheren van wijzigingen via pull-aanvragen.
• Een Gitflow-workflow is een formelere, gestructureerde uitbreiding op functie-branches, waardoor het een geweldige optie is voor grotere teams met duidelijk gedefinieerde releasecycli.
• Overweeg tot slot een workflow voor vertakking als je maximale isolatie en controle over wijzigingen nodig hebt, of als veel ontwikkelaars bijdragen aan één repository.

Maar als je als professioneel team echt het meeste uit Git wilt halen, moet je de workflow van de functie-branch overwegen. Dit is een echt gedistribueerde workflow die zeer veilig, ongelooflijk schaalbaar en uiterst flexibel is.

Je team overzetten naar Git kan een hele klus zijn, maar dat hoeft niet zo te zijn. In dit artikel werden enkele veelgebruikte opties geïntroduceerd om je bestaande codebase te migreren, Git implementeren in je ontwikkelingsteams en om te gaan met beveiliging en rechten. We hebben ook de grootste uitdagingen geïntroduceerd waarop je ontwikkelaars voorbereid moeten zijn tijdens het migratieproces.

Hopelijk heb je nu een solide basis om gedistribueerde ontwikkeling in je bedrijf te introduceren, ongeacht de omvang of de huidige ontwikkelingswerkwijzen.