Distribuerad versionskontroll

Inom mjukvaruutveckling är distribuerad versionskontroll (även känd som distribuerad versionskontroll ) en form av versionskontroll där hela kodbasen , inklusive dess fullständiga historik , speglas på varje utvecklares dator. Jämfört med centraliserad versionskontroll möjliggör detta automatisk hanteringsförgrening och sammanslagning , snabbar upp de flesta operationer (förutom att trycka och dra), förbättrar möjligheten att arbeta offline och förlitar sig inte på en enda plats för säkerhetskopiering. Git , världens mest populära versionskontrollsystem, är ett distribuerat versionskontrollsystem.

År 2010 beskrev mjukvaruutvecklingsförfattaren Joel Spolsky distribuerade versionskontrollsystem som "möjligen det största framsteg inom mjukvaruutvecklingsteknologi under de [senaste] tio åren".

Distribuerad vs. centraliserad

Distribuerade versionskontrollsystem (DVCS) använder en peer-to-peer- strategi för versionskontroll, i motsats till klient-server- metoden för centraliserade system. Distribuerad revisionskontroll synkroniserar arkiv genom att överföra korrigeringar från peer till peer. Det finns ingen enskild central version av kodbasen; istället har varje användare en arbetskopia och hela ändringshistoriken.

Fördelarna med DVCS (jämfört med centraliserade system) inkluderar:

  • Tillåter användare att arbeta produktivt när de inte är anslutna till ett nätverk.
  • Vanliga operationer (som commits, visningshistorik och återställning av ändringar) är snabbare för DVCS, eftersom det inte finns något behov av att kommunicera med en central server. Med DVCS är kommunikation endast nödvändig när förändringar delas mellan andra kamrater.
  • Tillåter privat arbete, så att användare kan använda sina ändringar även för tidiga utkast som de inte vill publicera. [ citat behövs ]
  • Arbetskopior fungerar effektivt som fjärrbackuper, vilket undviker att förlita sig på en fysisk maskin som en enda felpunkt.
  • Tillåter att olika utvecklingsmodeller används, som att använda utvecklingsgrenar eller en befälhavare/löjtnant-modell.
  • Tillåter centraliserad kontroll av "releaseversionen" av projektet [ citat behövs ]
  • På FOSS- programvaruprojekt är det mycket lättare att skapa en projektgaffel från ett projekt som har stannat på grund av ledarskapskonflikter eller designmotsättningar.

Nackdelar med DVCS (jämfört med centraliserade system) inkluderar:

  • Initial utcheckning av ett arkiv är långsammare jämfört med utcheckning i ett centraliserat versionskontrollsystem, eftersom alla grenar och revisionshistorik kopieras till den lokala maskinen som standard.
  • Bristen på låsmekanismer som är en del av de flesta centraliserade VCS och som fortfarande spelar en viktig roll när det kommer till icke sammanslagbara binära filer som grafiska tillgångar eller för komplexa enfils binära eller XML-paket (t.ex. kontorsdokument, PowerBI-filer, SQL Server Data Tools BI-paket, etc.). [ citat behövs ]
  • Ytterligare lagring krävs för att varje användare ska ha en fullständig kopia av den fullständiga kodbashistoriken.
  • Ökad exponering av kodbasen eftersom varje deltagare har en lokalt sårbar kopia. [ citat behövs ]

Vissa ursprungligen centraliserade system erbjuder nu vissa distribuerade funktioner. Team Foundation Server och Visual Studio Team Services är nu värd för centraliserade och distribuerade versionskontrollarkiv via värd för Git.

På liknande sätt erbjuder vissa distribuerade system nu funktioner som mildrar problemen med utcheckningstider och lagringskostnader, till exempel Virtual File System for Git utvecklat av Microsoft för att fungera med mycket stora kodbaser, vilket exponerar ett virtuellt filsystem som endast laddar ner filer till lokal lagring som de behövs.

Arbetsmodell

Den distribuerade modellen lämpar sig generellt sett bättre för stora projekt med delvis oberoende utvecklare, såsom Linux-kärnprojektet, eftersom utvecklare kan arbeta självständigt och skicka in sina ändringar för sammanfogning (eller avslag). Den distribuerade modellen gör det flexibelt möjligt att använda anpassade arbetsflöden för källkodsbidrag. Integratörens arbetsflöde är det mest använda. I den centraliserade modellen måste utvecklare serialisera sitt arbete, för att undvika problem med olika versioner.

Central- och filialförvar

I ett verkligt distribuerat projekt, som Linux , underhåller varje bidragsgivare sin egen version av projektet, med olika bidragsgivare som är värd för sina respektive versioner och drar in ändringar från andra användare efter behov, vilket resulterar i en allmän konsensus från flera olika noder. Detta gör också processen att "forking" lätt, eftersom allt som krävs är att en bidragsgivare slutar acceptera pull-förfrågningar från andra bidragsgivare och låter kodbaserna gradvis växa isär.

Detta arrangemang kan dock vara svårt att upprätthålla, vilket resulterar i att många projekt väljer att gå över till ett paradigm där en bidragsgivare är den universella "uppströms", ett arkiv från vilket förändringar nästan alltid hämtas. Under detta paradigm är utvecklingen något recentraliserad, eftersom varje projekt nu har ett centralt arkiv som informellt betraktas som det officiella arkivet, som hanteras av projektunderhållarna kollektivt. Medan distribuerade versionskontrollsystem gör det enkelt för nya utvecklare att "klona" en kopia av alla andra bidragsgivares arkiv, i en central modell, klona nya utvecklare alltid det centrala arkivet för att skapa identiska lokala kopior av kodbasen. Under detta system synkroniseras kodändringar i det centrala arkivet periodiskt med det lokala arkivet, och när utvecklingen är klar bör ändringen integreras i det centrala arkivet så snart som möjligt.

Organisationer som använder detta centraliseringsmönster väljer ofta att vara värd för det centrala arkivet på en tredjepartstjänst som GitHub , som inte bara erbjuder mer tillförlitlig drifttid än lagringsplatser med egen värd, utan också kan lägga till centraliserade funktioner som problemspårare och kontinuerlig integration .

Dra förfrågningar

Bidrag till ett källkodsförråd som använder ett distribuerat versionskontrollsystem görs vanligtvis med hjälp av en pull-begäran , även känd som en merge-begäran . Bidragsgivaren begär att projektunderhållaren drar källkodsändringen, därav namnet "pull request". Underhållaren måste slå samman pull-begäran om bidraget skulle bli en del av källbasen.

Utvecklaren skapar en pull-begäran för att meddela underhållare om en ny ändring; en kommentarstråd är associerad med varje pull-begäran. Detta möjliggör fokuserad diskussion om kodändringar . Inlämnade pull-förfrågningar är synliga för alla med åtkomst till arkivet. En pull-begäran kan accepteras eller avvisas av underhållare.

När pull-begäran har granskats och godkänts, slås den samman med arkivet. Beroende på det etablerade arbetsflödet kan koden behöva testas innan den inkluderas i den officiella versionen. Därför innehåller vissa projekt en speciell gren för att slå samman oprövade pull-förfrågningar. Andra projekt kör en automatiserad testsvit på varje pull-begäran, med hjälp av ett kontinuerligt integrationsverktyg som Travis CI , och granskaren kontrollerar att all ny kod har lämplig testtäckning.

Historia

De första DVCS-systemen med öppen källkod inkluderade Arch , Monotone och Darcs . DVCS med öppen källkod var dock aldrig särskilt populära förrän Git och Mercurial släpptes .

BitKeeper användes i utvecklingen av Linux-kärnan från 2002 till 2005. Utvecklingen av Git , nu världens mest populära versionskontrollsystem, föranleddes av beslutet från företaget som fick BitKeeper att återkalla den fria licensen som Linus Torvalds och några andra Linux-kärnutvecklare hade tidigare utnyttjat.

Se även

externa länkar

Hämtad från " https://en.wikipedia.org/w/index.php?title=Distributed_version_control&oldid=1134292917 "