Beste versiebeheer Hosting mei 2020

Openbaarmaking: Uw steun helpt de site draaiende te houden! We verdienen een verwijzingsvergoeding voor sommige van de services die we op deze pagina aanbevelen.


Contents

Vind hosting met deze functies in Versiebeheer

  • Mercurial
  • SVN

Versiebeheer en hosting

versiebeheer hosting

Codeerders houden van coderen.

Het kan gemakkelijk zijn om er een gewoonte van te maken om simpelweg een editor te openen en zoveel mogelijk code uit te slaan.

Dit geldt met name als u aan een persoonlijk project werkt of als u de enige ontwikkelaar bent.

Het kan nog verleidelijker zijn als je een snelle programmeur bent of een baas hebt die meteen oplossingen en oplossingen wil.

Maar als je nieuwe code in productie brengt zonder een goed versiebeheersysteem, dan doe je niet echt aan softwareontwikkeling, maar aan ‘Cowboy Coding’.

hoe versiebeheer werkt

Hoe versiebeheer werkt

Versiebeheer, ook wel revisiebeheer, versiebeheer of bronbeheer genoemd, is een methode voor het volgen van de revisies die zijn aangebracht in documenten, code of andere bestanden.

Versiebeheersystemen (VCS) of versiebeheersoftware kunnen op zichzelf staande toepassingen zijn die zijn ingebouwd in toepassingen voor documentbewerking (zoals Word of Google Docs).

Ze kunnen ook worden ingebed in contentbeheersystemen (zoals WordPress of MediaWiki) of een geïntegreerde ontwikkelomgeving (IDE) zoals Visual Studio van Microsoft.

Wat doet versiebeheer??

Met versiebeheersoftware kunnen ontwikkelaars, editors en andere teamleden eerdere versies van bestanden bekijken en eerdere versies herstellen.

Versiebeheer houdt een hoofdkopie van de codebasis bij. Bij veel versiebeheersystemen kunnen meerdere parallelle kopieën van de gehele codebasis tegelijkertijd bestaan.

Elke softwareontwikkelaar heeft zijn eigen exemplaar van de codebasis: ze kunnen revisies maken zonder de masterbroncode te beïnvloeden.

Deze herzieningen worden op een gepast moment binnengebracht en samengevoegd in de hoofdbroncode.

Hoe dit samenvoegen plaatsvindt, is afhankelijk van het versiecontrolesysteem (VCS) dat wordt gebruikt.

redenen om versiebeheer te gebruiken

Redenen om versiebeheer te gebruiken

Nog niet overtuigd dat u een versiebeheersysteem nodig heeft?

Dit zijn de redenen waarom versiebeheer het waard is om te gebruiken:

  • Vrijheid om fouten te maken
  • Vrijheid om iets nieuws te proberen
  • Een volledige geschiedenis van herzieningen van uw codebasis
  • Minder onbeantwoorde vragen
  • Papieren spoor van wat er is gedaan en waarom
  • Back-ups
  • Vergemakkelijker samenwerking tussen teamleden.

Vrijheid om fouten te maken

Gebruik je ooit de UNDO-knop (CTRL-Z) tijdens het werken? Natuurlijk doe je dat. Dit is een van de belangrijkste kenmerken van moderne computers.

Wat de UNDO-knop je geeft, is de vrijheid om fouten te maken. Dit is een van de voordelen van versiebeheer – het kan zelfs het belangrijkste voordeel zijn.

Vrijheid om iets nieuws te proberen

Met versiebeheer kunt u iets uitproberen – een nieuwe oplossing, een nieuwe functie, een bugfix.

Als het niet werkt, kunt u uw code eenvoudig terugzetten naar een eerder punt of de voorgestelde herzieningen weggooien.

Die revisies zijn niet samengevoegd met de hoofdbroncode. (Het lijkt op het sparen van punten in een videogame.)

Dit is om twee redenen handig:

  1. U zult onvermijdelijk fouten maken, dus u kunt net zo goed een manier hebben om ze gemakkelijk te corrigeren.
  2. Als je eenmaal weet dat je een manier hebt om fouten terug te draaien, wordt het veel gemakkelijker om je op onbekend terrein te wagen en risico’s te nemen met nieuwe oplossingen of ongeteste ideeën.

Volledige geschiedenis van de herzieningen die op uw codebasis zijn aangebracht

Heb je ooit gedurende een lange periode aan een project gewerkt en dan zegt iemand die het gebruikt: “Heeft de exit-knop niet een opslagwaarschuwing geactiveerd voordat de applicatie werd gesloten?”

Als een systeem lang genoeg bestaat, is het onvermijdelijk dat sommige functies worden gewijzigd en verwijderd.

Als je eenmaal weet dat je een manier hebt om fouten terug te draaien, wordt het veel gemakkelijker om je op onbekend terrein te wagen en risico’s te nemen met nieuwe oplossingen of ongeteste ideeën.

Meestal was er een reden om de functie in de eerste plaats te hebben (zelfs met functies die uiteindelijk worden verwijderd).

Er was echter ook een reden waarom een ​​bepaalde functie werd verwijderd (zelfs als de reden was dat iemand dit per ongeluk deed).

Minder onbeantwoorde vragen

Later, wanneer iemand komt opdagen en vraagt ​​naar een functie die er vroeger was, kun je heel hard proberen te onthouden wat er is gebeurd.

Of, als u versiebeheer heeft, kunt u eerdere revisies opzoeken en definitieve antwoorden geven over:

  • Wat die functie vroeger deed
  • Toen het werd verwijderd
  • Waarom het is verwijderd.

Dit is vooral handig als u:

  • Implementeer de functie opnieuw (soms kunt u de verwijderde code gewoon opnieuw implementeren!)
  • Verdedig de voortdurende uitsluiting van uw productieklare toepassingen.

Paper Trail of What Was Done and Why

Dit hangt nauw samen met de versiegeschiedenis, maar het gaat meer over ontwikkelaars en minder over functies.

Je papieren spoor is (meestal) geen letterlijk papieren spoor, maar met versiebeheer kun je dingen zien als:

  • Welke herzieningen zijn gemaakt
  • Toen er herzieningen werden gemaakt
  • Wie heeft de herzieningen gemaakt.

Dit is handig wanneer u probeert te achterhalen waarom de dingen zijn zoals ze zijn. U kunt krediet of schuld toekennen of gewoon uitzoeken wie u moet vragen over een specifieke functie of implementatie.

Back-ups

Versiegestuurde opslagplaatsen worden meestal op meerdere locaties opgeslagen.

Dit voorkomt dat uw projecten één enkele machine hebben als een catastrofaal single point of failure.

Vergemakkelijker samenwerking tussen teamleden

Als er maar één persoon aan een project werkt, kun je misschien wegkomen zonder een versiebeheersysteem te gebruiken (hoewel dit nog steeds echt een slecht idee is).

Als er echter meerdere mensen samen aan een project werken, is het risico dat mensen elkaars revisies overschrijven of incompatibele code maken (ook bekend als samenvoegconflicten) erg groot.

Als zodanig is een onmisbaar kenmerk van versiebeheersystemen (VCS) de mogelijkheid om te controleren op wederzijds incompatibele revisies van de mastercodebasis om ervoor te zorgen dat alles samenwerkt.

inzet

Implementatie en versiebeheer

Hoe verplaats je bestanden van je lokale ontwikkelmachine naar je testomgeving en tenslotte de productieomgevingen?

Sommige mensen houden gewoon een FTP-venster open en plaatsen bestanden erin als ze worden gewijzigd.

Dit is onverstandig. Het is te gemakkelijk om een ​​benodigd bestand weg te laten, en als er een onverwacht probleem is op de server, wordt het moeilijk om uw revisies ongedaan te maken.

Alle revisies tegelijk pushen

Als je bepaalde soorten versiebeheer gebruikt (vooral Git), kun je je revisies in één keer naar een externe server pushen. Het maakt niet uit welke omgeving – ontwikkeling, test of productie – de server afhandelt.

Als een van uw revisies op enig moment in de toekomst een probleem veroorzaakt, kunt u de revisies gemakkelijk terugdraaien zodat de dingen weer gaan werken.

Soorten versiebeheersystemen (VCS)

Er zijn in feite twee soorten versiebeheersystemen:

  • Gecentraliseerde versiebeheersystemen
  • Decentrale versiebeheersystemen.

Laten we hieronder een diepgaande blik werpen.

gecentraliseerd versiebeheer

Gecentraliseerde versiebeheersystemen

Gecentraliseerde versiebeheersystemen volgen een client-servermodel.

In deze systemen staat een enkele, master (“centrale”) set broncode op een server. Afzonderlijke bestanden waaraan wordt gewerkt, worden uitgecheckt door ontwikkelaars.

De werkkopie wordt dan ‘vergrendeld’. Anderen worden gewaarschuwd dat ze geen wijzigingen in het bestand mogen aanbrengen of zelfs verhinderen de bestanden te bewerken (of beide).

Ontwikkelaars pushen vervolgens de revisies die ze in deze bestanden hebben gemaakt terug naar de centrale broncode, de versie die wordt gebruikt voor code / software-implementaties in productieomgevingen.

Een voorbeeld van een gecentraliseerde VCS-workflow

In een gecentraliseerd versiebeheersysteem is er een centrale server (of repository) die als bron van waarheid fungeert.

Dit is ook de set codes die doorgaans in een productieklare staat wordt gehouden.

Dit betekent dat de code op elk moment zonder negatieve gevolgen naar een productieomgeving kan worden verzonden.

De workflow

Als je ergens aan moet werken, vind je de bestanden waar je aan moet werken. Vervolgens “checkt” u deze bestanden uit, wat betekent dat:

  1. U trekt een kopie naar uw lokale computer, waar u eraan kunt werken
  2. De bestanden zelf zijn beveiligd tegen bewerking door anderen in uw team

Wanneer u klaar bent met het aanbrengen van wijzigingen, kunt u deze vastleggen, inclusief een opmerking over wat u heeft gedaan.

In tegenstelling tot gedecentraliseerde systemen waar u uw wijzigingen samenvoegt (we zullen in een beetje meer praten over samenvoegingen), pusht u eenvoudig uw wijzigingen naar de centrale server. Hiermee worden de sloten vrijgegeven die u op die bestanden heeft.

gedecentraliseerd versiebeheer

Gedecentraliseerde (of gedistribueerde) versiebeheersystemen

Gedecentraliseerde / gedistribueerde versiebeheersystemen zijn systemen waarbij de betrokken softwareontwikkelaars:

  • Een volledige kopie van de volledige codebasis (in tegenstelling tot een werkkopie van geselecteerde bestanden)
  • Een geschiedenis van gemaakte revisies.

Bron van waarheid, gebruikers en knooppunten

Er is geen enkele gebruiker of knooppunt, dat is belangrijker dan enig ander knooppunt, hoewel er meestal één enkele opslagplaats is die als de oorsprong is aangewezen. (Beschouw een opslagplaats als een bestand maar met historische informatie.)

De oorsprong is vergelijkbaar met de “centrale” broncode in een gecentraliseerde VCS.

Individuele veranderingen worden, wanneer ze gereed zijn, opgegaan in de bron van de waarheid (meestal aangeduid als de hoofdtak).

Vanwege de asynchrone en onafhankelijke methode waarmee gedecentraliseerde VCS werken, samenvoegconflicten moeten door de ontwikkelaars worden opgelost voordat het samenvoegen plaatsvindt.

Op deze manier wordt voorkomen dat onverenigbare verschillen tussen het werk van twee of meer ontwikkelaars de hoofdbranch breken.

Een voorbeeld van een gedecentraliseerde VCS-workflow

In deze sectie behandelen we het proces van het gebruik van een gedecentraliseerd versiebeheersysteem.

De vereiste vertakking en samenvoeging maken het gebruik van dergelijke systemen iets gecompliceerder dan de gecentraliseerde tegenhangers.

Ermee beginnen

U kunt op twee manieren aan de slag gaan:

  • U kunt een nieuwe repository initialiseren op uw dev-machine
  • Je kunt een bestaande repository klonen.

Welke optie u ook kiest, u krijgt altijd een volledige kopie van de broncode op uw computer.

Verschillende versies van de code worden filialen genoemd, met de bron van de waarheid en de versie die wordt verzonden naar een productie die de mastertak wordt genoemd. Bij het gebruik van gedistribueerde VCS is het een goede gewoonte om de mastertak te allen tijde gereed te houden voor productie-implementatie.

Veranderingen maken

Elke keer dat u een of meer bestanden wilt wijzigen, maakt u een nieuwe branch aan. Zoals de naam al aangeeft, is een branch een uitloper van de hoofdcode.

Het aantal wijzigingen dat u in een filiaal opneemt, kan variëren.

Het kan zijn dat u slechts een kleine wijziging aanbrengt, of dat u maanden van wijzigingen op één enkele tak bewaart.

Normaal gesproken zou u (op zijn minst) ervoor zorgen dat alle wijzigingen betrekking hebben op één functie.

Het proces van het opslaan van een wijziging wordt genoemd begaan.

Voor elke commit die je maakt, moet je notities toevoegen over wat je hebt gedaan – je VCS zou automatisch moeten opmerken dat jij de persoon was die de wijziging heeft gepleegd en wanneer.

Commits beheren

Na verloop van tijd zul je een logboek kunnen zien van alle gemaakte toezeggingen, wanneer ze zijn gemaakt en door wie.

Commits hebben de bonusfunctie dat u uw wijzigingen slechts een klein beetje tegelijk kunt terugdraaien.

Dit veronderstelt dat je meerdere commits hebt gemaakt en niet slechts één grote commit aan het einde van je project).

Je kunt commits zien als afdelingen van branches.

Hoewel branches wijzigingen bevatten die betrekking hebben op een bepaalde functie, zijn commits de kleinere wijzigingen die samen de volledige functie-update worden.

Duwende takken

Vestigingen zijn ook handig om uw werk te delen.

Stel dat u met verschillende anderen werkt en dat u allemaal bijdraagt ​​aan één opslagplaats.

Nou, als je je werk wilde delen (misschien wil je de code die je hebt geschreven beoordeeld), dan kun je gewoon de branch pushen waar je aan hebt gewerkt in plaats van de hele repository.

Uw werk verzenden

Wanneer u aan het lezen bent om uw werk te verzenden, kunt u beginnen met het samenvoegen, waarbij iemand (meestal niet uzelf) uw feature-branch in de master-branch samenvoegt.

Het algemene proces is als volgt:

  1. Je pusht je branch naar de centrale repository en vraagt ​​om het in de master branch te trekken
  2. Iemand anders beoordeelt uw filiaal en als alles er goed uitziet, voltooien ze de samenvoeging.

Merk op dat versiebeheersystemen de reviewer alleen toestaan ​​om samen te voegen als uw voorgestelde wijzigingen niet in strijd zijn met iets dat al is samengevoegd in de hoofdbranch.

Als dit niet het geval is, moet u de samenvoegingsconflicten oplossen en uw verzoek bijwerken.

vergelijkingsversie controlesystemen

Vergelijkende en contrasterende gedistribueerde (gedecentraliseerde) versus gecentraliseerde versiebeheersystemen

Wat zijn de belangrijkste verschillen tussen een gedecentraliseerd / gedistribueerd versiebeheersysteem en een gecentraliseerd versiebeheersysteem?

Het meest voor de hand liggende verschil tussen gecentraliseerde en gedecentraliseerde VCS is in termen van toegang en gemak.

Nadelen van een gecentraliseerd systeem

Je kunt een gecentraliseerd systeem zien als verwant aan het openen van een gedeelde Dropbox-map via een webbrowser.

Omgekeerd is toegang tot een gedistribueerd systeem het equivalent van het synchroniseren van een gedeelde, gemeenschappelijke Dropbox-map met uw eigen computer.

Met een gecentraliseerd systeem moeten uw gebruikers, voordat ze kunnen beginnen met bewerken:

  • Toegang tot de centrale bronbestanden
  • Download de werkkopie die ze nodig hebben
  • Bekijk de werkkopie zodat ze zijn vergrendeld en niet door anderen kunnen worden bewerkt.

Bestanden in een gedistribueerd systeem

Met een gedistribueerd systeem zijn de bestanden al precies daar waar je ze nodig hebt.

Dit komt omdat een van de eerste stappen om een ​​gedistribueerd systeem in te stellen is om alle bestanden, evenals de versiegeschiedenis, naar uw lokale ontwikkelingswerkstation te klonen.

Het klonen van een repository is analoog aan het kopiëren van een bestand – onthoud echter dat repository’s aanvullende historische informatie bevatten.

Wanneer u klaar bent om te beginnen met werken, hoeft u alleen maar de bestanden die u naar uw computer hebt ‘getrokken’ te openen.

Het hebben van alle bestanden die u lokaal nodig heeft, is een enorm voordeel in termen van snelheid en efficiëntie.

De enige keer dat u met de server moet communiceren, is door er een bestand uit te halen of er een bestand naar terug te pushen.

Doorslaggevende voordelen en nadelen van een gedistribueerd systeem

Met deze asynchrone methode kunnen gebruikers ook verschillende revisies lokaal uitvoeren voordat ze beslissen over de volgende stap:

  • Hun revisies doorgeven aan alle anderen die aan het project werken (door naar de oorspronkelijke tak te duwen en de revisies binnen te halen)
  • Hun revisies verzenden om teamleden te selecteren voor beoordeling voordat ze zichtbaar worden voor het hele team.

Een groot nadeel van een gedistribueerde VCS is echter de hoeveelheid ruimte die een lokale repository nodig heeft.

Afhankelijk van de grootte van uw project kunnen individuele opslagplaatsen die u naar uw computer hebt gekloond, veel ruimte in beslag nemen.

Dit probleem wordt versterkt als u meerdere opslagplaatsen moet klonen voor een enkele (of zelfs meerdere) projecten.

Waarom zijn deze nadelen?

Als u kijkt naar het grote aantal tekstbestanden, afbeeldingsbestanden, video’s en logbestanden, kan dit problematisch zijn, vooral voor mensen met een budgetwerkstation.

Voor gebruikers met dergelijke beperkingen is een gecentraliseerde VCS wellicht een betere optie, aangezien gebruikers alleen de bestanden hoeven te verwijderen die ze nodig hebben, niet de volledige set broncode en de bijbehorende revisiehistorie.

gedecentraliseerde opties versiebeheer

Gedistribueerde versiebeheersysteemopties

Bij het kiezen van een versiebeheersysteem (VCS), wat zijn de opties die voor u beschikbaar zijn?

Welke moet je kiezen?

In de volgende secties zullen we verschillende populaire gedistribueerde versiebeheersystemen behandelen, evenals verschillende populaire gecentraliseerde versiebeheersystemen.

Hopelijk helpt dit u bij het kiezen van een optie die bij uw behoeften past. Zo niet, dan zou deze lijst u moeten helpen om snel te beginnen met zoeken naar de optie die werkt!

Laten we beginnen met enkele van de meest populaire gedistribueerde opties die beschikbaar zijn.

Bazaar

Bazaar is het versiebeheersysteem dat wordt gesponsord door Canonical, geschreven in Python.

Als een platformonafhankelijk, open source-project kunnen gebruikers op macOS, Linux en Windows dit product gebruiken.

Voor gebruikers die bekend zijn met Concurrent Version System (CVS) of Subversion (SVN), zullen Bazaar-opdrachten er hetzelfde uitzien.

Bazaar, in tegenstelling tot sommige van de andere gedistribueerde VCS, kun je het gebruiken met of zonder een centrale repository of server waar de hoofdbroncode-set leeft.

Het integreert ook goed met andere VCS – u kunt wijzigingen doorvoeren in SVN en u kunt bestanden lezen die worden bijgehouden door Git of Mercurial.

U kunt de geschiedenis van Bazaar ook exporteren naar vele andere systemen.

Fossiel

Fossil is een platformonafhankelijk, gedistribueerd versiebeheersysteem dat ook functies bevat voor:

  • Bug-tracking
  • Wiki’s
  • Bloggen.

Fossil wordt geleverd met een ingebouwde webinterface die gedetailleerde wijzigingsgeschiedenis en projectstatusinformatie weergeeft.

Het doel van deze interface is verminder de complexiteit inherent betrokken bij het volgen van projecten en het verbeteren van een gebruiker omgevingsbewustzijn in de codebasis.

Overeenkomsten met Bazaar

Net als Bazaar vereist Fossil niet dat je een centrale server gebruikt, maar als je dat doet, zal de samenwerking tussen je teamleden gemakkelijker zijn.

Fossil gebruikt SQLite-databases om de inhoud op te slaan.

Git

Git is een versiebeheersysteem gemaakt door de “vader van Linux”, Linus Torvalds.

Hoewel Git een prominente plaats inneemt in de wereld van softwareontwikkeling, kan het worden gebruikt om veranderingen in elk type bestandsset bij te houden.

Al met al, Git geeft prioriteit aan prestaties.

Dit is belangrijk wanneer gedistribueerde versiebeheersystemen het volgende vereisen:

  • De eerste opname van alle projectbestanden (niet alleen degene waaraan wordt gewerkt)
  • Data-integriteit
  • Ondersteuning voor niet-lineaire workflows.

Git op verschillende platforms

Hoewel Git is ontwikkeld met Linux, is het een platformonafhankelijke oplossing.

Elk project wordt doorgaans beheerd in een individuele repository. (Onthoud dat een repository in wezen een map is, maar met een logboek van wijzigingen).

Bestanden voor grote projecten worden soms opgesplitst in meerdere opslagplaatsen.

Git wordt meestal gebruikt in combinatie met een soort webgebaseerde hostingservice.

Dit is de methode waarmee meerdere medewerkers hun werk kunnen delen, evenals de originele broncode en de wijzigingen die door hun collega’s zijn aangebracht, kunnen ophalen.

GitHub

Een van de meest voorkomende webgebaseerde hostingservices die voor Git worden gebruikt, is GitHub (ter wille van het feit is GitHub de grootste bron van broncode ter wereld).

Naast het ondersteunen van alle functies voor versiebeheer en broncodebeheer van Git, biedt GitHub:

  • Toegangscontrole tools
  • Tools voor het volgen van bugs
  • Beheer van functieverzoeken
  • Taakbeheer / productiviteitstools
  • Wiki’s.

U kunt zelfs eenvoudige webpagina’s genereren en hosten met GitHub.

Hoewel GitHub zowel openbare als privé-opslagplaatsen biedt, brengt het gebruik van een privé-opslagplaats kosten met zich mee (terwijl een openbare opslagplaats gratis is).

Dit komt overeen met de toewijding van GitHub aan open source-code.

Bitbucket

Bitbucket is de bijdrage van Atlassian aan de wereld van webgebaseerde hosting voor Git- (en Mercurial-) gebruikers.

Naast zijn gratis accounts biedt Bitbucket meer functierijke commerciële plannen.

Voor sommige gebruikers is Bitbucket een betere optie dan GitHub, aangezien Bitbucket niets verandert als je een privérepository gebruikt.

Gratis accounts krijgen een onbeperkt aantal privérepository’s, hoewel het aantal bijdragers is beperkt.

Bitbucket wordt meestal gezien als de optie voor professionele ontwikkelaars werken met eigen broncode.

Het belangrijkste gebruik is voor code en code review, hoewel Bitbucket wel wat extra’s biedt zoals:

  • Documentatie
  • Wiki
  • Statische websitefuncties.

GitLab

GitLab is een beheerder van door Git gecreëerde opslagplaatsen die een zelf-gehoste optie of een webgebaseerde service biedt. GitLab biedt Wiki-gerelateerde functies en tools, evenals probleemopsporingsfunctionaliteit.

Gitlab Zelf-gehoste en volledig-gehoste abonnementen

GitLab biedt vier verschillende zelf-gehoste oplossingsplannen:

  • Core: voor kleine teams of persoonlijke projecten (Core is volledig gratis te gebruiken)
  • Starter: voor persoonlijke projecten of kleine teams die professionele ondersteuning willen.
  • Premium: voor teams die hoge beschikbaarheid, hoge prestaties of 24/7 ondersteuning nodig hebben.
  • Ultiem: voor grote ondernemingen behoefte aan extra beveiligings- en compliancefunctionaliteit.

Bent u niet geïnteresseerd in self-hosting, dan kunt u kiezen voor de volledig gehoste versie van Git. Voor elk zelf gehost plan is er een bijbehorend gehost plan:

  • Core → Gratis
  • Voorgerecht → Brons
  • Premium → Zilver
  • Ultimate → Goud

Feature Parity Between Gitlab Plans

GitLab zorgt ervoor dat de gelijkheid van functies tussen de zelf-gehoste en volledig gehoste abonnementen (dat wil zeggen, de functies die worden aangeboden aan die op het Starter-abonnement zijn dezelfde als die op het Bronze-plan).

Een privérepository nodig?

Voor degenen onder u die een privérepository (of meerdere privérepository’s) nodig hebben, zou u GitLab sterk kunnen overwegen.

Voor deze situaties is GitLab goedkoper dan GitHub en sneller dan Bitbucket (hoewel je kilometers natuurlijk kunnen variëren afhankelijk van variabelen die specifiek zijn voor jouw situatie).

Mercurial

Mercurial is een platformonafhankelijk gedistribueerd versiebeheersysteem dat:

  • Zeer performant
  • Makkelijk schaalbaar
  • Geschikt voor zowel platte tekst als binaire bestanden
  • Geavanceerd in zijn vertakkings- en samenvoegmogelijkheden.

Ondanks de complexiteit die dergelijke functies met zich meebrengen, streven de ingenieurs er nog steeds naar een conceptueel eenvoudig product met een gebruiksvriendelijke, geïntegreerde webinterface te verzenden.

Hoewel de opdrachtregel de belangrijkste methode is waarmee een gebruiker met Mercurial communiceert, zijn er veel grafische gebruikersinterface (GUI) -extensies beschikbaar en bieden veel geïntegreerde ontwikkelomgevingen (IDE) ingebouwde ondersteuning voor Mercurial-integratie.

gecentraliseerde opties voor versiebeheer

Opties voor gecentraliseerd versiebeheersysteem

De volgende versiebeheersystemen zijn enkele van de meest populaire gecentraliseerde opties die beschikbaar zijn.

Concurrent Versions System (CVS)

Concurrent Versions System (CVS) is een gratis versiebeheersoftware.

De oorsprong van CVS ligt in een reeks shell-scripts die halverwege 1986 is verzonden.

CVS wordt niet langer onderhouden (de laatste keer dat de ontwikkelaars een nieuwe release uitbracht was 2008), maar je zult nog steeds een aantal mensen vinden die CVS gebruiken.

Houd er bij het gebruik van CVS rekening mee dat de gebruikte terminologie enigszins verschilt van die van andere versiebeheersystemen.

Een set gerelateerde bestanden wordt bijvoorbeeld een module genoemd, terwijl de reeks modules die een CVS-server beheert de repository wordt genoemd.

CVS noemt de bestanden die door ontwikkelaars worden uitgecheckt de werkkopie, sandbox of werkruimte.

Revisies van de werkkopie worden via commits naar de repository gestuurd, terwijl updaten het proces is van het verkrijgen van de wijzigingen die nu in de repository aanwezig zijn.

Subversion (SVN)

Apache’s Subversion (SVN) is een open source versiebeheer / revisiecontrolesysteem.

We vermeldden dat het Concurrent Versions System (CVS) nog steeds enkele gebruikers heeft, maar CVS is sinds 2008 niet bijgewerkt.

Als zodanig is Subversion ontworpen om te werken als en wordt het vaak gebruikt als een (meestal) compatibel alternatief / opvolger van CVS.

Wat Subversie de moeite waard maakt?

Hoewel gedistribueerde systemen zoals Git de meeste aandacht lijken te krijgen in de wereld van versiebeheersystemen, wordt Subversion vaak gebruikt, vooral in de open-sourcecommunity.

Subversion is oorspronkelijk in 2000 ontwikkeld als alternatief voor CVS, maar met bugfixes en extra functies die niet in CVS te vinden waren.

Een van de grootste voordelen van Subversion is de ingebouwde functionaliteit, fijnmazige toestemmingen systeem.

U kunt de toegang tot bestanden en mappen per gebruiker beperken.

Bovendien is Subversion een goede optie voor diegenen die binaire bestanden en andere activa willen die in dezelfde repository’s zijn opgeslagen als de broncode (vooral als je een groot aantal van deze binaire bestanden hebt).

Gebruiksvriendelijk en doelmarkt

Ten slotte mag u niet afleiden dat er een leercurve is als het gaat om versiebeheersystemen.

Subversie kan zijn makkelijker voor mensen (vooral niet-technische gebruikers) om te leren en te begrijpen dan andere versiebeheersystemen.

Ten slotte is Subversion een goede optie voor bedrijven die actief zijn in zwaar gereguleerde industrieën.

Hoewel u elk versiebeheersysteem zeker kunt hacken om de audittrails te behouden, moet u ervoor zorgen dat uw bedrijf voldoet aan de toepasselijke voorschriften.

SVN wordt als enterprise-grade systeem geleverd met de functieset die nodig is om dit proces voor u gemakkelijker te maken.

Team Foundation Server (TFS)

Team Foundation Server (TFS) is de bijdrage van Microsoft aan de wereld van versiebeheersystemen.

TFS bevat ook functies voor:

  • Rapportage
  • Beheer van vereisten
  • Project management
  • Testen en beheerfuncties vrijgeven.

In wezen bevat TFS alles wat u nodig heeft om alle aspecten van de levenscyclus van softwareontwikkeling te beheren.

Waar wordt TFS voor gebruikt?

TFS kan worden gebruikt met veel verschillende geïntegreerde ontwikkelomgevingen (IDE’s).

Het is speciaal gebouwd voor gebruik met Visuele studio of Verduistering.

U kunt TFS zelf hosten of u kunt zich abonneren op de gehoste versie genaamd Visual Studio Team Services.

Bovendien is TFS een van de weinige producten met ingebouwde uitbreidbaarheid.

Je kunt zeker andere systemen hacken om te presteren zoals je wilt als het in strijd is met de manier waarop het product is ontworpen, maar TFS maakt dit proces veel eenvoudiger.

Overzicht

Er zijn veel verschillende versiecontrolesystemen en hoewel ze allemaal versiecontrole iets anders implementeren, is het belangrijk dat u er een gebruikt.

Het verschil tussen Git, CVS en SVN is niet zo groot als het verschil tussen niet hebben of hebben van een versiebeheersysteem.

Loop geen catastrofaal verlies van uw broncode in gevaar – gebruik vandaag nog een versiebeheersysteem!

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map