Werkingsprincipes van versiebeheersystemen. Al het werk in Git gebeurt in een repository die alle werkbestanden bevat.

Stuur uw goede werk in de kennisbank is eenvoudig. Gebruik het onderstaande formulier

Studenten, afstudeerders, jonge wetenschappers die de kennisbasis gebruiken in hun studie en werk zullen je zeer dankbaar zijn.

geplaatst op http://www.allbest.ru/

Ministerie van Onderwijs en Wetenschappen van de Russische Federatie

Federale staatsbegroting educatief

Hoger Beroepsonderwijsinstituut

"TOMSK STAAT UNIVERSITEIT

BESTURINGSSYSTEMEN EN RADIO-ELEKTRONICA (TUSUR)

Afdeling Radio Engineering Systems (RTS)

cursus werk

op de cursus "Informatietechnologie"

VERSIE BESTURINGSSYSTEMEN

Studenten gr.121-3 Korolev D.O.,

Kuleshov MV, Sadov DA, Taimasov S.S.

Hoofd Nozdrevatykh B.F.

Cursussen 46s., 31 fig., 2 tabellen, bronnen.

VERSIE CONTROLESYSTEEM, GIT, SVN, MERCURIAL.

In dit cursuswerk worden de meest populaire versiebeheersystemen besproken.

Het doel van het werk is om kennis te maken met versiebeheersystemen, hun werk, installatie en configuratie te begrijpen.

Tijdens het werk werden drie soorten versiecontrolesystemen geïnstalleerd met hun configuratie en testen van werk.

Als resultaat worden drie volledig gebruiksklare versiebeheersystemen, tabellen waarin de functies van deze systemen worden vergeleken en een verklarende woordenlijst gegeven van termen die worden gebruikt bij het werken met programma's.

Het cursuswerk is gedaan in de Microsoft Word 2010-teksteditor en gepresenteerd in gedrukte en elektronische vorm.

interface voor versiebeheersysteem

Invoering

3.1 Aan de slag met het project

3.2 Dagelijkse werkcyclus

3.3 Takken

3.4 Versies samenvoegen

3.5 Conflicten en hun oplossing

3.6 Vergrendelingen

3.7 Projectversies, tags

4.1 Lokale versiebeheersystemen

4.2 Gecentraliseerd model

5.1.1 Systeemvereisten

5.1.2 Concept

5.1.3 Aan de slag

5.2.1 Systeemvereisten

5.2.2 Installatie

5.2.3 Basisconcept

5.2.4 Een kluis maken

5.2.5 Een project importeren

5.2.7 Wijzigingen aanbrengen

5.2.8 Nieuwe bestanden toevoegen

5.2.9 Wijzigingen ongedaan maken

5.3.1 Systeemvereisten

5.3.2 Begrip

5.3.3 Aan de slag

Gevolgtrekking

bijlage A

bijlage B

bijlage B

Invoering

Tegenwoordig, in een wereld met een groot aantal complexe systemen, is het nodig om elektronische documenten in verschillende stadia van hun ontwikkeling te wijzigen. Tijdens zijn bestaan ​​kan een elektronisch document aan een groot aantal wijzigingen onderhevig zijn. Het komt echter vaak voor dat verder werk niet alleen de nieuwste versie van het document vereist, maar ook verschillende eerdere versies.

Natuurlijk kunt u verschillende versies van het vereiste document opslaan, maar deze methode is inefficiënt. We moeten er veel tijd en moeite in steken, speciale aandacht is nodig en de kans op fouten is groot. Bovendien moeten we een enorme hoeveelheid bijna identieke documenten opslaan.

Als gevolg hiervan zijn er softwaretools ontwikkeld die dit mechanisme vereenvoudigen. Deze tools worden versiebeheersystemen genoemd. Er zijn verschillende van dit soort systemen, die elk onder bepaalde gebruiksomstandigheden relevant zijn.

Het belangrijkste idee van versiebeheersystemen is om alle aangebrachte wijzigingen te onthouden, evenals de opmerkingen van de gebruikers die ze hebben aangebracht. Daarna wordt duidelijk wie, wanneer en wat er is veranderd, waarom en waarom. En, belangrijker nog, al deze wijzigingen kunnen vervolgens worden teruggedraaid naar elk moment in de tijd.

In overeenstemming met het doel, is het noodzakelijk om de volgende taken op te lossen:

Definieer het concept van een versiebeheersysteem;

Begrijpen hoe dergelijke systemen werken;

Overweeg installatie- en opstartregels;

Analyseren van bestaande versiebeheersystemen;

Overweeg de belangrijkste soorten van dit soort systemen.

De taken van het werk bepaalden de structuur ervan. Het cursuswerk bestaat uit vijf hoofdstukken, inleiding, conclusie, literatuurlijst en toepassingen.

1. Concept versiebeheersysteem

Versiebeheersysteem (VCS) -- software om het werken met veranderende informatie te vergemakkelijken. Het versiebeheersysteem stelt u in staat om meerdere versies van hetzelfde document op te slaan, indien nodig terug te keren naar eerdere versies, te bepalen wie en wanneer deze of gene wijziging heeft aangebracht.

2. Een versiebeheersysteem gebruiken

Dergelijke systemen worden meestal gebruikt bij softwareontwikkeling, zodat de broncodes van de ontwikkelde programma's kunnen worden opgeslagen. Met VCS kunnen ontwikkelaars eerdere versies van bestanden uit de ontwikkeling opslaan en ze daar ophalen. Het slaat de versie-informatie van elk bestand (en de volledige structuur van het project) op in een verzameling, gewoonlijk een repository genoemd. Maar desalniettemin kunnen deze systemen worden gebruikt in andere kennisgebieden, waaronder een groot aantal vaak veranderende elektronische documenten. Ze worden bijvoorbeeld steeds vaker gebruikt in CAD, meestal als onderdeel van productgegevensbeheersystemen (PDM). Versiebeheer wordt gebruikt in configuratiebeheertools.

Het gebruik van VCS is zeker verplicht voor de ontwikkelaar als het project groter is dan een paar honderd regels, of als er meerdere ontwikkelaars aan het project samenwerken.

Versiebeheersystemen lossen de volgende problemen op:

Opslag van bestandsversies;

Mogelijkheid om eerdere versies van opgeslagen bestanden op te halen;

Wijzigingen bekijken die zijn aangebracht tussen de versies die in het verzoek zijn gespecificeerd;

3. Typische systeemwerking:

Elke VCS heeft zijn eigen specifieke kenmerken op het gebied van commandoset, gebruikersbediening en beheer. De algemene werkwijze voor de meeste VCS's is echter volledig stereotiep. Hier wordt aangenomen dat het project, wat het ook mag zijn, al bestaat en dat de repository wordt gehost op de server waartoe de ontwikkelaar toegang krijgt.

3.1 Aan de slag met het project

De eerste actie die een ontwikkelaar moet uitvoeren, is het bekijken van een werkkopie van het project of het deel ervan waaraan moet worden gewerkt. Deze actie wordt uitgevoerd met behulp van de standaardversie checkout-opdracht (checkout of clone) of een speciale opdracht die daadwerkelijk dezelfde actie uitvoert. De ontwikkelaar specificeert de versie die moet worden gekopieerd, standaard wordt de nieuwste (of de keuze van de beheerder als hoofdversie) meestal gekopieerd.

Het extractiecommando brengt een verbinding tot stand met de server en kopieert het project in de vorm van een boomstructuur van mappen en bestanden naar de computer van de ontwikkelaar. Een gangbare praktijk is om de werkkopie te dupliceren: naast de hoofddirectory met het project wordt er ook nog een kopie ervan naar de lokale schijf geschreven. Tijdens het werken aan een project wijzigt de ontwikkelaar alleen de bestanden in de hoofdwerkkopie. De tweede lokale kopie wordt opgeslagen als referentie, zodat u op elk moment kunt bepalen zonder contact op te nemen met de server welke wijzigingen zijn aangebracht aan een bepaald bestand of project als geheel en van welke versie de werkkopie is gemaakt; in de regel leidt elke poging om deze kopie handmatig te wijzigen tot fouten in de VCS-software.

3.2 Dagelijkse werkcyclus

Met enkele variaties, bepaald door de kenmerken van het systeem en de details van het geaccepteerde bedrijfsproces, ziet een typische werkcyclus voor ontwikkelaars tijdens de werkdag er als volgt uit:

1) Het bijwerken van de werkkopie. Naarmate er wijzigingen worden aangebracht in de hoofdversie van het project, wordt de werkkopie op de computer van de ontwikkelaar ouder: de discrepantie met de hoofdversie van het project neemt toe. Dit vergroot het risico op tegenstrijdige wijzigingen. Daarom is het handig om de werkkopie zo dicht mogelijk bij de huidige hoofdversie te houden, waarvoor de ontwikkelaar zo vaak mogelijk een updatebewerking op de werkkopie uitvoert.

2) Projectwijziging. De ontwikkelaar past het project aan door de daarin opgenomen bestanden in de werkkopie te wijzigen in overeenstemming met de projecttaak. Dit werk wordt lokaal gedaan en vereist geen oproepen naar de VCS-server.

3) Wijzigingen corrigeren. Nadat de volgende fase van het werk aan de taak is voltooid, voert de ontwikkelaar zijn wijzigingen door (commit) en draagt ​​ze over naar de server, hetzij naar de hoofdtak, als het werk aan de taak volledig is voltooid, of naar een afzonderlijke ontwikkelingstak van deze taak . De videorecorder kan de ontwikkelaar vragen om de werkkopie bij te werken voordat deze wordt vastgelegd. Als er ondersteuning is voor uitgestelde wijzigingen (rekken) in het systeem, kunnen wijzigingen zonder committen worden overgedragen naar de server. Als het goedgekeurde beleid om in de VCS te werken dit toelaat, kan het vaststellen van wijzigingen niet dagelijks worden uitgevoerd, maar pas na voltooiing van het werk aan de taak; in dit geval worden alle wijzigingen die aan de taak zijn gekoppeld, alleen opgeslagen in de lokale werkkopie van de ontwikkelaar totdat het werk is voltooid.

3.3 Takken

U kunt kleine correcties in het project maken door de werkkopie direct te bewerken en de wijzigingen vervolgens direct door te voeren naar de hoofdtak (trunk) op de server. Bij het uitvoeren van enig werk van enige significante omvang wordt deze volgorde echter onhandig: het ontbreken van tussentijdse wijzigingen op de server maakt het niet mogelijk om aan iets in een groepsmodus te werken, bovendien neemt het risico van het verliezen van wijzigingen tijdens lokale ongevallen toe en de mogelijkheid om te analyseren en terug te keren naar vorige is verloren code-opties binnen dit werk. Daarom is het voor dergelijke wijzigingen de gebruikelijke praktijk om vertakkingen (tak) te maken, een versie van een nieuwe versie van het project of een deel ervan te maken, waarbij de ontwikkeling parallel wordt uitgevoerd met wijzigingen in de hoofdversie. Wanneer het werk waarvoor de vertakking is gemaakt is voltooid, wordt de vertakking opnieuw geïntegreerd in de hoofdvertakking. Dit kan gedaan worden met een merge-commando, of door een patch te maken die de wijzigingen bevat die tijdens de ontwikkeling van de branch zijn gemaakt en die patch toe te passen op de huidige hoofdversie van het project.

3.4 Versies samenvoegen

Drie soorten bewerkingen die in bronbeheer worden uitgevoerd, kunnen ertoe leiden dat wijzigingen moeten worden samengevoegd:

Het bijwerken van de werkkopie;

Wijzigingen herstellen;

Vestigingen samenvoegen.

Elk systeem heeft een automatisch samenvoegmechanisme dat werkt op basis van de volgende principes:

Wijzigingen kunnen bestaan ​​uit het wijzigen van de inhoud van een bestand, het maken van een nieuw bestand of nieuwe map, het verwijderen of hernoemen van een reeds bestaand bestand of map in het project;

Als twee wijzigingen betrekking hebben op verschillende en niet-gerelateerde bestanden en/of mappen, kunnen ze altijd automatisch worden samengevoegd. Hun samenvoeging is dat de wijzigingen die in elke versie van het project zijn aangebracht, worden gekopieerd naar de samengevoegde versie;

Het maken, verwijderen en hernoemen van bestanden in projectmappen kan automatisch worden samengevoegd, tenzij ze met elkaar in strijd zijn. In dit geval worden de wijzigingen die in elke versie van het project zijn aangebracht, gekopieerd naar de samengevoegde versie.

De conflicten zijn meestal:

Het verwijderen en wijzigen van hetzelfde bestand of dezelfde map;

Het verwijderen en hernoemen van hetzelfde bestand of dezelfde map;

Creatie in verschillende versies van een bestand met dezelfde naam en verschillende inhoud;

Wijzigingen binnen hetzelfde tekstbestand die in verschillende versies zijn gemaakt, kunnen worden samengevoegd als ze zich op verschillende plaatsen in dit bestand bevinden en elkaar niet overlappen. In dit geval worden alle aangebrachte wijzigingen opgenomen in de samengevoegde versie;

Wijzigingen binnen hetzelfde bestand, tenzij het een tekstbestand is, zijn altijd tegenstrijdig en kunnen niet automatisch worden samengevoegd.

In alle gevallen is de basisversie voor de merge de versie waarin de splitsing van de samengevoegde versies is gemaakt. Als dit een commit-bewerking is, dan zal de basisversie de versie zijn van de laatste update vóór de commit, als update, dan de versie van de vorige update, als merge branches, dan de versie waarin de corresponderende branch is gemaakt. Dienovereenkomstig zijn de overeenkomende wijzigingensets de wijzigingensets die zijn gemaakt van de basis naar de huidige versie in alle samengevoegde varianten.

De overgrote meerderheid van moderne versiecontrolesystemen is voornamelijk gericht op softwareontwikkelingsprojecten waarin het belangrijkste type bestandsinhoud tekst is. Dienovereenkomstig zijn de mechanismen voor het automatisch samenvoegen van wijzigingen gericht op de verwerking van tekstbestanden.

Bij het bepalen van de toelaatbaarheid van het samenvoegen van wijzigingen binnen hetzelfde tekstbestand, werkt een typisch regel-voor-regel tekstvergelijkingsmechanisme (een voorbeeld van de implementatie ervan is het GNU diff-systeemhulpprogramma), dat de samengevoegde versies vergelijkt met de basisversie en een lijst met wijzigingen, dat wil zeggen toegevoegde, verwijderde en vervangen reeksen regels . De gevonden sets van gewijzigde strings die elkaar niet kruisen, worden als compatibel beschouwd en het samenvoegen gebeurt automatisch. Als er wijzigingen in de samengevoegde bestanden zijn die van invloed zijn op dezelfde regel van het bestand, leidt dit tot een conflict. Dergelijke bestanden kunnen alleen handmatig worden samengevoegd. Alle bestanden, behalve tekst, zijn binair vanuit het oogpunt van VCS en staan ​​automatische samenvoeging niet toe.

3.5 Conflicten en hun oplossing

De situatie waarin, wanneer verschillende versies worden samengevoegd, de daarin aangebrachte wijzigingen elkaar kruisen, wordt een conflict genoemd. In het geval van een conflict tussen wijzigingen kan het versiebeheersysteem niet automatisch een samengevoegd project maken en is het genoodzaakt contact op te nemen met de ontwikkelaar. Zoals hierboven vermeld, kunnen er conflicten optreden in de stadia van het doorvoeren van wijzigingen, het bijwerken of samenvoegen van branches. In alle gevallen, wanneer een conflict wordt gedetecteerd, wordt de bijbehorende bewerking beëindigd totdat deze is opgelost.

Om een ​​conflict op te lossen, biedt het systeem de ontwikkelaar over het algemeen drie opties voor conflicterende bestanden: basis, lokaal en server. Tegenstrijdige wijzigingen worden ofwel aan de ontwikkelaar getoond in een speciale programmamodule voor het samenvoegen van wijzigingen, of eenvoudig gemarkeerd met speciale opmaakrecht in de tekst van het samengevoegde bestand.

Conflicten in het bestandssysteem zijn gemakkelijker op te lossen: alleen het verwijderen van een bestand kan in strijd zijn met een van de andere bewerkingen, en de volgorde van de bestanden in de map doet er niet toe, dus de ontwikkelaar kan alleen kiezen welke bewerking hij in de samengevoegde versie wil behouden .

3.6 Vergrendelingen

Het vergrendelingsmechanisme stelt een van de ontwikkelaars in staat om alleen een bestand of een groep bestanden voor eigen gebruik te gebruiken om er wijzigingen in aan te brengen. Zolang het bestand is vergrendeld, blijft het alleen-lezen voor alle andere ontwikkelaars en elke poging om wijzigingen aan te brengen wordt door de server afgewezen. Technisch gezien kan het blokkeren op verschillende manieren worden georganiseerd. Typerend voor moderne systemen is het volgende mechanisme:

Bestanden die moeten worden vergrendeld, zijn gemarkeerd met een speciale "afsluitbare" vlag;

Als een bestand als vergrendeld is gemarkeerd, ontvangt het, wanneer een werkkopie van de server wordt opgehaald, het alleen-lezen-attribuut op het lokale bestandssysteem, wat voorkomt dat het per ongeluk wordt bewerkt;

Een ontwikkelaar die een vergrendeld bestand wil wijzigen, roept een speciaal vergrendelingscommando (lock) aan met de naam van dit bestand. Dit commando resulteert in het volgende:

1. de server controleert of het bestand al is vergrendeld door een andere ontwikkelaar; als dit het geval is, mislukt het vergrendelcommando.

2. het bestand op de server is gemarkeerd als "geblokkeerd", met de identificatie van de ontwikkelaar die het heeft geblokkeerd en de opgeslagen blokkeringstijd;

3. Als de vergrendeling op de server succesvol was, wordt het alleen-lezen attribuut verwijderd uit het werkkopiebestand op het lokale bestandssysteem, zodat u het kunt gaan bewerken.

Als tijdens bedrijf blijkt dat het bestand niet gewijzigd hoeft te worden, kan het het ontgrendelcommando (unlock , slot vrijgeven). Alle wijzigingen aan het bestand worden verwijderd, het lokale bestand keert terug naar een alleen-lezen status, het kenmerk "vergrendeld" wordt uit het bestand op de server verwijderd en andere ontwikkelaars kunnen dit bestand wijzigen;

Na voltooiing van het werk met het vergrendelde bestand, legt de ontwikkelaar de wijzigingen vast. Meestal wordt de blokkering automatisch opgeheven.

3.7 Projectversies, tags

Het versiebeheersysteem zorgt voor de opslag van alle bestaande varianten van bestanden en als gevolg daarvan alle varianten van het project als geheel die hebben plaatsgevonden sinds het begin van de ontwikkeling ervan. Maar het concept van "versie" in verschillende systemen kan op twee verschillende manieren worden geïnterpreteerd.

Sommige systemen ondersteunen bestandsversiebeheer. Dit betekent dat elk bestand dat in het project verschijnt een eigen versienummer krijgt. Elke keer dat een ontwikkelaar wijzigingen aanbrengt die van invloed zijn op een bestand, wordt het overeenkomstige deel van de vastgelegde wijzigingen toegepast op het bestand en krijgt het bestand een nieuw, meestal het volgende op volgorde, versienummer.

Voor andere systemen verwijst het begrip "versie" niet naar een enkel bestand, maar naar de hele repository. Een nieuw aangemaakte lege repository heeft versie 1 of 0, elke commit zorgt ervoor dat dit aantal toeneemt. Het versienummer van een enkel bestand bestaat hier niet echt.

Beide opties zijn echter niet erg handig. Voor handiger taggen van projectversies ondersteunen versiebeheersystemen het concept van tags.

Een tag is een symbolisch label dat kan worden gekoppeld aan een bepaalde versie van een bestand en/of map in een repository. Met behulp van het juiste commando kunnen alle of een deel van de projectbestanden die aan bepaalde voorwaarden voldoen, een bepaald label krijgen. Op deze manier is het mogelijk om de versie van het project te identificeren door de status ervan op een gewenst moment vast te leggen. In de regel is het tagging-systeem vrij flexibel en kunt u niet-simultane versies van bestanden en mappen taggen met één tag. Hiermee kunt u op een willekeurige manier een "versie van het project" bouwen.

4.1 Lokale versiebeheersystemen

De meest geprefereerde VCS voor het bijhouden van woningontwikkelingen is het lokale type. Om dit probleem op te lossen zijn er speciale VCS ontwikkeld met een eenvoudige database waarin alle lokale bestanden zijn opgeslagen.

Figuur 4.1 Schema van lokale SCR

Een van de meest populaire VCS van dit type is RCS, dat nog steeds op veel computers is geïnstalleerd.

4.2 Gecentraliseerd model

Traditionele versiecontrolesystemen gebruiken een gecentraliseerd model waarbij er één documentopslagplaats is die wordt beheerd door een speciale server die de meeste versiecontrolefuncties uitvoert. Een gebruiker die met documenten werkt, moet eerst de versie van het document die hij nodig heeft uit de repository halen; meestal wordt er een lokale kopie van het document gemaakt, de zogenaamde "werkkopie". De nieuwste versie kan worden verkregen, of een van de vorige, die kan worden geselecteerd op versienummer of aanmaakdatum, soms op basis van andere criteria. Nadat de gewenste wijzigingen in het document zijn aangebracht, wordt de nieuwe versie in de repository geplaatst. In tegenstelling tot het simpelweg opslaan van een bestand, wordt de vorige versie niet gewist, maar blijft ook in de repository en kan daar op elk moment worden opgehaald.

Dergelijke systemen, zoals CVS, Subversion en Perforce, hebben een centrale server die alle versiebestanden opslaat en een aantal clients die kopieën van de bestanden ervan ontvangen. Dit is al jaren de standaard voor versiebeheersystemen.

Figuur 4.2 Gecentraliseerd versiebeheerschema

Deze aanpak heeft veel voordelen, vooral ten opzichte van lokale SLE. Zo weet iedereen wie wat doet in het project. Beheerders hebben duidelijke controle over wie wat kan doen, en natuurlijk is het beheer van CSCC veel eenvoudiger dan lokale databases op elke client.

Er zijn echter een aantal ernstige nadelen aan deze benadering. De meest voor de hand liggende is dat de gecentraliseerde server het zwakke punt van het hele systeem is. Als de server een uur uitvalt, kunnen ontwikkelaars een uur lang niet communiceren en kan niemand een nieuwe versie van hun werk opslaan. Als de schijf met de centrale database is beschadigd en er is geen back-up, dan verlies je werkelijk alles - de hele geschiedenis van het project, behalve misschien een paar werkende versies die zijn opgeslagen op werkende machines van gebruikers. Lokale VCS hebben hetzelfde probleem: als de hele geschiedenis van het project op één plek wordt opgeslagen, loop je het risico alles te verliezen.

4.3 Gedistribueerde versiebeheersystemen

Dergelijke systemen gebruiken een gedistribueerd model in plaats van het traditionele client-servermodel. Over het algemeen hebben ze geen gecentraliseerde opslagplaats nodig: de volledige geschiedenis van documentwijzigingen wordt op elke computer in lokale opslag opgeslagen en, indien nodig, worden individuele fragmenten van de lokale opslaggeschiedenis gesynchroniseerd met een vergelijkbare opslag op een andere computer. Daarom, in het geval dat de server waardoor het werk uitviel, elke client-repository terug naar de server kan worden gekopieerd om de database te herstellen. In sommige van deze systemen bevindt de lokale opslag zich direct in de werkkopiemappen.

Afbeelding 4.3 Gedistribueerd SLE-model

Wanneer een gebruiker van zo'n systeem normale acties uitvoert, zoals het uitchecken van een specifieke versie van een document, een nieuwe versie maken, enzovoort, werkt hij met zijn lokale kopie van de repository. Naarmate er wijzigingen worden aangebracht, beginnen de opslagplaatsen van verschillende ontwikkelaars te verschillen en wordt het noodzakelijk om ze te synchroniseren. Een dergelijke synchronisatie kan worden uitgevoerd door patches of zogenaamde sets tussen gebruikers uit te wisselen.

Het beschreven model komt logischerwijs dicht in de buurt van het creëren van een aparte branch voor elke ontwikkelaar in een klassiek versiebeheersysteem. Het verschil is dat tot het moment van synchronisatie andere ontwikkelaars van deze branche het niet zien. Zolang de ontwikkelaar alleen zijn eigen branch verandert, heeft zijn werk geen invloed op andere projectdeelnemers en vice versa. Na voltooiing van een apart deel van het werk, worden de wijzigingen die aan de branches zijn aangebracht, samengevoegd met de hoofd (algemene) branch. Zowel bij het samenvoegen van branches als bij het synchroniseren van verschillende repositories zijn versieconflicten mogelijk. In dit geval bieden alle systemen een of andere methode voor het detecteren en oplossen van samenvoegconflicten.

Vanuit het oogpunt van de gebruiker onderscheidt een gedistribueerd systeem zich door de noodzaak om een ​​lokale repository te creëren en de aanwezigheid van twee extra commando's in de commandotaal: het commando om een ​​repository te ontvangen van een externe computer en de repository over te brengen naar een externe computer . Het eerste commando voegt de wijzigingen van de externe en lokale repository's samen en pusht het resultaat naar de lokale repository; de tweede daarentegen voegt de wijzigingen van de twee repository's samen, zodat het resultaat in een remote repository wordt geplaatst. In de regel kunt u met merge-commando's in gedistribueerde systemen kiezen welke wijzigingensets worden overgebracht naar of uit een andere repository worden gehaald, merge-conflicten direct tijdens de bewerking of nadat deze is mislukt oplossen, een onvoltooide merge opnieuw proberen of hervatten. Gewoonlijk lukt het alleen om uw wijzigingen door te voeren naar de repository van iemand anders als er geen conflicten zijn. Als er conflicten ontstaan, moet de gebruiker de versies eerst samenvoegen in hun repository en ze pas daarna overdragen aan anderen.

Over het algemeen wordt aanbevolen om het werken met het systeem zo te organiseren dat gebruikers altijd of overwegend samenvloeien in hun eigen repository. Dat wil zeggen, in tegenstelling tot gecentraliseerde systemen, waar gebruikers hun wijzigingen naar een centrale server overbrengen wanneer ze dat nodig achten, is het in gedistribueerde systemen natuurlijker om versies samen te voegen door degene die het resultaat moet krijgen (bijvoorbeeld een ontwikkelaar die een build beheert server).

De belangrijkste voordelen van gedistribueerde systemen zijn hun flexibiliteit en veel grotere (vergeleken met gecentraliseerde systemen) autonomie van een individuele werkplek. De computer van elke ontwikkelaar is in feite een onafhankelijke en complete server, vanaf dergelijke computers is het mogelijk om een ​​willekeurig systeem in structuur en complexiteit te bouwen door de gewenste synchronisatievolgorde in te stellen.

De nadelen van gedistribueerde systemen zijn onder meer een toename van de benodigde hoeveelheid schijfgeheugen: elke computer moet een volledige versiegeschiedenis opslaan, terwijl in een gecentraliseerd systeem meestal alleen een werkkopie op de computer van de ontwikkelaar wordt opgeslagen, dat wil zeggen een stukje de repository op een bepaald moment en de aangebrachte wijzigingen. Een minder voor de hand liggend maar vervelend nadeel is dat het bijna onmogelijk is om een ​​deel van de functionaliteit van gecentraliseerde systemen in een gedistribueerd systeem te implementeren. Deze:

- Een bestand of een groep bestanden vergrendelen (om een ​​teken van een slot op te slaan, hebt u een openbare en constant online centrale server nodig). Dit dwingt je tot het nemen van bijzondere administratieve maatregelen als je moet werken met binaire bestanden die niet geschikt zijn voor automatisch samenvoegen;

- Een specifiek bestand of een groep bestanden volgen;

- Uniforme doorlopende nummering van versies van het systeem en/of bestanden, waarbij het versienummer monotoon oploopt. In gedistribueerde systemen moet u het doen met lokale versie-aanduidingen en tags gebruiken waarvan het doel wordt bepaald door een overeenkomst tussen ontwikkelaars of bedrijfsnormen van het bedrijf;

- Lokaal werk van de gebruiker met een aparte, kleine steekproef van een aanzienlijke opslagcapaciteit en interne complexiteit op een externe server.

We kunnen de volgende typische situaties onderscheiden waarin het gebruik van een gedistribueerd systeem merkbare voordelen biedt:

- Periodieke synchronisatie van meerdere computers beheerd door één ontwikkelaar. Het gebruik van een gedistribueerd systeem elimineert de noodzaak om een ​​van de computers als server toe te wijzen;

- Gezamenlijk werken aan het project van een kleine geografisch verspreide groep ontwikkelaars zonder de toewijzing van gemeenschappelijke middelen. Net als in het vorige geval wordt het werkschema geïmplementeerd zonder de hoofdserver en wordt de relevantie van de repositories gehandhaafd door periodieke synchronisatie volgens het "elk met elk" -schema;

Een groot gedistribueerd project, waarvan de deelnemers lange tijd aan hun eigen deel kunnen werken, terwijl ze geen permanente verbinding met het netwerk hebben. Zo'n project kan een gecentraliseerde server gebruiken waarmee kopieën van al zijn leden worden gesynchroniseerd. Het is ook mogelijk om zonder "groeps"-servers te werken, dan synchroniseren de ontwikkelaars van één groep de wijzigingen onderling, waarna een van hen de wijzigingen doorstuurt naar de centrale server.

5. Voorbeelden van versiebeheersystemen

5.1 git

5.1.1 Systeemvereisten

git werkt onder de volgende besturingssystemen: Windows, Linux en Mac OS.

Om Git op Windows te installeren hoef je alleen maar het exe-bestand van het installatieprogramma te downloaden van de projectpagina op GitHub en het uit te voeren.Na de installatie heb je zowel een consoleversie (inclusief een SSH-client) als een standaard grafische versie.

5.1.2 Concept

git is een gedistribueerd versiebeheersysteem. Daarin kunnen bestanden een van de volgende drie statussen hebben: vastgelegd, gewijzigd en voorbereid. "Toegewezen" betekent dat het bestand al in uw lokale database is opgeslagen. Gewijzigde bestanden zijn bestanden die zijn gewijzigd maar nog niet zijn vastgelegd. Staging-bestanden zijn gewijzigde bestanden die zijn gemarkeerd voor opname in de volgende vastlegging.

In projecten die Git gebruiken, zijn er dus drie delen: de Git-directory (Git-directory), de werkdirectory (werkdirectory) en het staging-gebied.

De Git-directory is waar Git de metadata en objectdatabase van je project opslaat.Dit is het belangrijkste onderdeel van Git en wordt gekopieerd wanneer je een repository van een andere machine kloont.

De werkdirectory is een kopie van een specifieke versie van het project die uit de database is gehaald. Deze bestanden worden uit een gecomprimeerde database in de Git-directory gehaald en op schijf geplaatst zodat u ze kunt bekijken en bewerken.

Het staging-gebied is een normaal bestand, meestal opgeslagen in de Git-directory, dat informatie bevat over wat er in de volgende commit moet gaan. Soms een index (index) genoemd, maar meer recentelijk is het standaard geworden om het het staging-gebied te noemen ( staging-gebied ).

De standaard workflow met Git ziet er ongeveer zo uit:

1. U brengt wijzigingen aan in bestanden in uw werkdirectory.

2.Bereid bestanden voor door hun snapshots toe te voegen aan het voorbereide bestandengebied.

3. Maak een commit die de voorbereide bestanden uit de index haalt en ze in de Git-directory plaatst voor permanente opslag.

Als de werkende versie van het bestand overeenkomt met de versie in de Git-directory, wordt het bestand als vastgelegd beschouwd. Als het bestand is gewijzigd, maar toegevoegd aan het voorbereide gegevensgebied, wordt het voorbereid. Als het bestand is gewijzigd nadat het uit de database is verwijderd, maar niet is voorbereid, dan wordt het als gewijzigd beschouwd.

5.1.3 Aan de slag

Allemaal werken in Git gebeurt in een repository die alle bestanden van een taak bevat. U kunt op verschillende manieren een repository maken.

1. Via het contextmenu. Om dit te doen, klikt u met de rechtermuisknop in de gewenste map en selecteert u Git Init Here.

Afbeelding 5.1.1 Een repository maken met behulp van het contextmenu

2. De opdrachtregel gebruiken. Om dit te doen, selecteert u in de gewenste map Git Bash in het contextmenu. Er wordt een opdrachtregel geopend waarin we een repository maken met behulp van het Git Init-commando.

Afbeelding 5.1.2 Een repository maken met behulp van de opdrachtregel

Als je nog nooit git hebt gebruikt, moet je eerst je naam en e-mailadres invoeren met respectievelijk bijna de volgende commando's:

git config --global user.name "Uw naam"

git config --global user.email [e-mail beveiligd]

De aangemaakte repository zal een .git directory bevatten. Om een ​​bestand aan de repository toe te voegen, hoeft u het alleen maar naar uw werkmap te kopiëren. Laten we het ex.txt-bestand toevoegen aan de repository. Gebruik het git status commando om er zeker van te zijn dat Git het bestand heeft gezien.

Afbeelding 5.1.3 Een bestand toevoegen en controleren in de repository

Verder, om een ​​bestand onder versiebeheer toe te voegen, is het de moeite waard om dit bestand te indexeren en de eerste wijziging door te voeren. Dit kan gedaan worden met een paar git add commando's die de te indexeren bestanden specificeren, en dan git commit.

Afbeelding 5.1.4 Een bestand toevoegen onder versiebeheer

Het git status-commando is het belangrijkste hulpmiddel dat wordt gebruikt om te bepalen welke bestanden zich in welke staat bevinden.

Gebruik het git add "bestandsnaam" commando om te beginnen met het bijhouden (versiebeheer) van een nieuw bestand. Dit commando neemt als parameter een pad naar een bestand of map, als het een map is, voegt het commando recursief alle bestanden in de gegeven map toe (indexeert).

Git commit -m "comment" - een commando om een ​​commit te maken, een wijziging vast te stellen.

Herhaal de vorige bewerking via de Git Gui GUI. Selecteer hiervoor het item Git Gui in het contextmenu.

Afbeelding 5.1.5

Selecteer in het geopende venster "Een nieuwe repository maken". Vervolgens specificeren we de directory waarin we de repository willen plaatsen.

Afbeelding 5.1.6 Een repository maken in Git Gui

Voeg het Ex.txt-bestand toe aan de map. Klik vervolgens op de knop "Herlezen". Om een ​​bestand aan het versiebeheersysteem toe te voegen, moet u op de knop "Alles voorbereiden" klikken. Het Ex.txt-bestand moet van het venster Gewijzigd naar het venster Voorbereid worden verplaatst. De knop "Opslaan" wordt gebruikt om de wijziging vast te leggen.

5.1.5 Een kopie maken van de repository

Tegenwoordig heb je een enorm aantal hostingopties om uit te kiezen, allemaal met hun eigen voor-en nadelen.

In deze sectie zullen we het proces van het aanmaken van een account en een nieuw project op GitHub doorlopen, zodat je een idee krijgt van de zaken die erbij komen kijken.

GitHub is tegenwoordig de grootste Git-hostingsite voor open source-projecten en een van de weinige die tegelijkertijd zowel openbare als privéhosting biedt.

Het eerste dat u moet doen, is een account aanmaken en uw repository maken op http://github.com/plans.

Vervolgens voeren we in de Git-opdrachtregel de opdrachten in die we al kennen:

Git toevoegen ex.txt

Git commit -m "commentaar"

Git remote origin toevoegen https://github.com/Arbuz-z-z/MyHomework.git

Git push -u origin master

Het git remote add commando is voor het toevoegen van remote repositories, en het git push commando is voor het pushen van lokale wijzigingen naar een remote server.

Afbeelding 5.1.7

Voer de gebruikersnaam en het wachtwoord in die tijdens de registratie zijn opgegeven:

Afbeelding 5.1.8

Nu wordt ons project gehost op GitHub, in de repository - MyHomework met het bestand Tusur.txt en we kunnen er een link naar geven aan iedereen met wie we het project willen delen.

Afbeelding 5.1.9 GitHub-repository

5.2 SchildpadSVN

5.2.1 Systeemvereisten

TortoiseSVN draait onder Windows XP (met Service Pack 3) of hoger en is beschikbaar in zowel 32-bits als 64-bits versies. Het installatieprogramma voor 64-bits Windows bevat ook een 32-bits onderdeel.

5.2.2 Installatie

TortoiseSVN wordt geleverd als een eenvoudig te gebruiken installatieprogramma.

5.2.3 Basisconcept

Opslag. Subversion gebruikt een centrale database die alle versiebestanden met hun volledige geschiedenis bevat. Deze database wordt een repository genoemd. De repository bevindt zich meestal op een bestandsserver waarop Subversion is geïnstalleerd en levert op verzoek gegevens aan Subversion-clients (bijv. TortoiseSVN). Als u een back-up maakt, maak dan een back-up van uw kluis, aangezien deze het origineel is van al uw gegevens.

Werkend exemplaar. Dit is precies waar je werkt. Elke ontwikkelaar heeft zijn eigen werkkopie, ook wel sandbox genoemd, op zijn lokale computer. U kunt de nieuwste versie van bestanden uit de kluis halen, er lokaal aan werken zonder met iemand anders te communiceren, en als u zeker bent van de wijzigingen, kunt u die bestanden weer vastleggen in de kluis. De werkkopie bevat niet de geschiedenis van het project, maar bevat een kopie van alle bestanden die in de kluis waren voordat je begon met het aanbrengen van wijzigingen.

TortoiseSVN is een extensie voor Windows Explorer, dus je moet eerst Explorer starten.

Afbeelding 5.2.1 Weergave in Verkenner

5.2.4 Een kluis maken

Voor dit project hebben we een repository nodig die op een veilige locatie is gemaakt en een Subversion-server om het te beheren. We zullen de lokale repository-functie van Subversion gebruiken, die directe toegang geeft tot een repository die op uw harde schijf is gemaakt en geen server vereist.

Laten we eerst een nieuwe lege map op de pc maken. Het kan overal zijn, maar in dit werk gaan we het s:\svn_repos noemen. Klik nu met de rechtermuisknop op de nieuwe map en selecteer TortoiseSVN > Maak hier een winkel aan in het contextmenu. De winkel die in de map is gemaakt, is klaar voor gebruik. We zullen ook een interne mappenstructuur maken door op de knop "Mapstructuur maken" te klikken.

Afbeelding 5.2.2 Een repository maken

Afbeelding 5.2.3 door de repository bladeren

5.2.5 Een project importeren

Op dit moment hebben we een repository, maar die is momenteel helemaal leeg. Laten we aannemen dat we een set bestanden in E:\\TortoiseSVN hebben die we willen toevoegen. Laten we naar de TortoiseSVN-map in Verkenner gaan en er met de rechtermuisknop op klikken. Selecteer nu TortoiseSVN > Importeren... waardoor een dialoogvenster verschijnt.

Afbeelding 5.2.4 Importvenster

De Subversion-repository is toegankelijk via een URL waarmee we overal op internet naar de repository kunnen verwijzen. In dit geval moeten we verwijzen naar onze lokale repository, die de URL file:///s:/svn_repos heeft, waaraan we onze TortoiseSVN-projectnaam toevoegen.

Een ander belangrijk kenmerk van dit dialoogvenster is het venster Bericht importeren, waar we een bericht kunnen toevoegen over wat we aan het doen zijn. Wanneer we de geschiedenis van het project moeten bekijken, zullen deze berichten een waardevolle hulp zijn om te zien welke wijzigingen zijn aangebracht en wanneer.

5.2.6 Een werkkopie uitchecken

Nu hebben we een project in onze repository en we moeten een werkkopie maken voor ons dagelijkse werk. Het is vermeldenswaard dat het importeren van een map niet automatisch van die map een werkkopie maakt. Subversion gebruikt de term "Checkout" om een ​​nieuwe werkkopie te maken. We gaan de TortoiseSVN-map uit onze repository extraheren naar een ontwikkelmap met de naam e:\\TortoiseSVN\svn_repos. Laten we deze map maken, er met de rechtermuisknop op klikken en TortoiseSVN > Uitchecken... Voer de URL in om uit te checken, in dit geval file:///s:/svn_repos/TortoiseSVN, en klik op OK. Onze ontwikkelmap zal zich vullen met bestanden uit de repository.

Deze map ziet er anders uit dan een gewone map. Elk bestand heeft een groene vlag in de linkerhoek. Dit zijn de TortoiseSVN status iconen die alleen in de werkkopie aanwezig zijn. Groene status betekent dat het bestand niet verschilt van de versie van het bestand in de repository.

5.2.7 Wijzigingen aanbrengen

Je kunt aan het werk. In de map TortoiseSVN beginnen we met het wijzigen van bestanden - stel dat we wijzigingen aanbrengen in de TortoiseSVN.docx-bestanden. Merk op dat de pictogrammen op deze bestanden nu rood zijn, wat aangeeft dat de wijzigingen lokaal zijn aangebracht.

Door met de rechtermuisknop op een van de gewijzigde bestanden te klikken, selecteert u TortoiseSVN > Verschillen. De TortoiseSVN-tool voor het vergelijken van bestanden wordt gestart en laat je precies zien welke regels in de bestanden zijn gewijzigd.

Afbeelding 5.2.5 Bestandsvergelijking

Laten we nu de repository bijwerken. Deze actie heet Wijzigingen vastleggen. Klik met de rechtermuisknop op de TortoiseSVN-map en selecteer TortoiseSVN > Vastleggen. Er verschijnt een vastleggingsdialoogvenster met een lijst van gewijzigde bestanden en naast elk ervan staat een vinkje. We kunnen slechts een paar bestanden uit de lijst selecteren om vast te leggen.

Afbeelding 5.2.6 Bestanden herstellen

5.2.8 Nieuwe bestanden toevoegen

Tijdens het werken aan een project hebben we nodig: nieuwe bestanden toevoegen, stel dat we nieuwe functies in een bestand hebben toegevoegd en hulp in een bestaand bestand hebben toegevoegd. Klik met de rechtermuisknop op de map en selecteer TortoiseSVN > Toevoegen. Het dialoogvenster Toevoegen toont alle bestanden zonder versienummer en we kunnen de bestanden selecteren die we willen toevoegen. Een andere manier om bestanden toe te voegen is door met de rechtermuisknop op het bestand zelf te klikken en TortoiseSVN > Toevoegen te selecteren.

Als we nu de commit-map openen, wordt het nieuwe bestand weergegeven als "Toegevoegd" en het bestaande bestand als "Gewijzigd".

5.2.9 Wijzigingen ongedaan maken

Een kenmerk dat alle revisiecontrolesystemen gemeen hebben, is het kenmerk waarmee we wijzigingen die we in het verleden hebben aangebracht, ongedaan kunnen maken.

Als we wijzigingen willen verwijderen die we nog niet hebben vastgelegd en het gewenste bestand willen herstellen in de vorm waarin het was voordat de wijzigingen begonnen, selecteer dan het commando TortoiseSVN > Wijzigingen verwijderen. Deze actie maakt onze wijzigingen ongedaan en retourneert de vaste versie van het bestand waarmee we zijn begonnen. Als we slechts enkele van de wijzigingen willen intrekken, kunnen we de TortoiseMerge-tool gebruiken om de wijzigingen te bekijken en selectief gewijzigde rijen te verwijderen.

Als we een specifieke revisie ongedaan willen maken, beginnen we met de logdialoog en zoeken we de problematische revisie. Selecteer de opdracht Contextmenu > Wijzigingen van deze revisie ongedaan maken en die wijzigingen worden ongedaan gemaakt.

5.2.10 Kenmerken van TortoiseSVN. Shell-integratie

TortoiseSVN integreert rechtstreeks in de Windows-shell (d.w.z. Verkenner). Dit betekent dat u kunt werken met de tools die u al kent en niet elke keer naar een andere applicatie hoeft over te schakelen als u versiebeheerfunctionaliteit nodig heeft!

En je hoeft niet eens Explorer te gebruiken. De contextmenu's van TortoiseSVN werken in veel andere bestandsbeheerders en dialoogvensters voor het openen van bestanden die in de meeste standaard Windows-toepassingen worden gebruikt. U moet zich er echter van bewust zijn dat TortoiseSVN oorspronkelijk is ontworpen als een extensie voor Windows Verkenner en dat andere toepassingen mogelijk niet volledig kunnen worden geïntegreerd, bijvoorbeeld pictogramoverlays worden mogelijk niet weergegeven.

De status van elk versiebestand en elke map wordt weergegeven met een klein vinkje boven het hoofdpictogram. Zo zie je in één oogopslag de status van je werkkopie.

5.2.11 Grafische gebruikersinterface

Wanneer je een lijst met wijzigingen aan een bestand of map bekijkt, kun je op een revisie klikken om de opmerkingen voor die vastlegging te zien. Er is ook een lijst met gewijzigde bestanden beschikbaar - dubbelklik gewoon op een bestand om precies te zien welke wijzigingen zijn aangebracht.

Het commit-dialoogvenster is een lijst met alle bestanden en mappen die in de vastlegging zullen worden opgenomen. Elk lijstitem heeft een selectievakje zodat je precies kunt selecteren wat je in de vastlegging wilt opnemen. Bestanden zonder versiebeheer kunnen ook in deze lijst worden weergegeven, zodat u niet vergeet een nieuw bestand of nieuwe map aan de vastlegging toe te voegen.

Alle Subversion-commando's zijn beschikbaar in het contextmenu van de Verkenner. TortoiseSVN voegt daar zijn eigen submenu toe.

5.3 Mercurial

5.3.1 Systeemvereisten

P Mercurial-pakketten zijn beschikbaar voor elk populair besturingssysteem: Windows, Mac OS, Linux (Ubuntu, Debian, Fedora, OpenSUSE, Gentoo), Solaris.

De beste versie van Mercurial voor Windows is TortoiseHg, te vinden op http://tortoisehg.org. Met dit pakket kunt u de opdrachtregel en een grafische gebruikersinterface gebruiken.

5.3.2 Begrip

Mercurial is een gedistribueerd (gedecentraliseerd) versiebeheersysteem. Dit betekent dat de workflow er doorgaans als volgt uitziet:

1. Een nieuwe repository wordt aangemaakt op een personal computer (door een bestaande repository te klonen, een nieuwe aan te maken, enz.);

2. Bestanden worden gewijzigd/toegevoegd/verwijderd in de werkdirectory van deze repository;

3. De wijzigingen worden vastgelegd in deze repository (dat wil zeggen, in de lokale repository op de personal computer);

4. Stappen 2 en 3 worden zo vaak herhaald als nodig is;

5. Indien nodig worden wijzigingen gesynchroniseerd met andere repositories: de wijzigingensets van anderen worden getrokken (pull) en/of die van henzelf gegeven (push).

Dat wil zeggen, al het dagelijkse werk vindt plaats in de lokale repository, en wanneer dat nodig is, worden de resultaten van hun werk naar een of meer andere repositories gestuurd. U kunt het aantal stappen verminderen bij het werken met externe opslagplaatsen door Mercurial zo in te stellen dat wijzigingen automatisch naar andere opslagplaatsen worden doorgevoerd wanneer een vastlegging wordt gedaan.

5.3.3 Aan de slag

U kunt in Mercurial werken via het contextmenu van de verkenner, het werkruimtevenster TortoiseHg Workbench (het programma maakt een geschikte snelkoppeling bij de installatie) of de opdrachtregel met behulp van de hg-opdracht.

5.3.4 Een repository maken en werken met bestanden

In Mercurial gebeurt alles in een repository. De projectrepository bevat alle bestanden die "behoren" tot het project, evenals de revisiegeschiedenis van die bestanden. Er zijn drie verschillende manieren om een ​​repository aan te maken.

Om een ​​repository aan te maken via het contextmenu van de verkenner, klikt u met de rechtermuisknop op de gewenste map en selecteert u het juiste item.

Afbeelding 5.3.1 Een repository maken

In het venster dat verschijnt, kunt u de locatie van de repositorymap bevestigen en de aangemaakte repository openen in de werkomgeving.

Afbeelding 5.3.2 Locatie van opslagplaatsmap

Op dezelfde manier wordt de repository rechtstreeks in het TortoiseHg Workbench-venster gemaakt: de File \ New repository-reeks roept het bovenstaande venster met dezelfde naam aan. Gebruik op de opdrachtregel de opdracht hg init om een ​​repository in de huidige map te maken<имя хранилища>. De aangemaakte repository zal de .hg-directory bevatten.

Afbeelding 5.3.3 Een repositorymap maken via de opdrachtregel

Als we bestaande bestanden aan de repository willen toevoegen, kopiëren we ze naar de werkdirectory en gebruiken we het hg add-commando om Mercurial te vertellen om ze te gaan bekijken. Laten we het bestand aan de repository toevoegen en een nieuwe revisie maken.

Afbeelding 5.3.4 Een bestand toevoegen aan de repository en een nieuwe revisie maken

Zorg ervoor dat Mercurial het opgeslagen bestand ziet. Het status commando toont de status van de werkkopie in vergelijking met de status van de lokale repository. Mercurial laat zien dat het het bestand example.txt ziet, maar dit bestand is nog niet in broncodebeheer (het "?"-teken links van de bestandsnaam). Om Mercurial te vertellen dat er een versie van moet worden gemaakt, voert u hg add uit. Er verschijnt een "A"-teken links van de bestandsnaam, wat betekent dat het bestand readme.txt wordt toegevoegd aan het versiebeheersysteem bij de volgende commit (wanneer een nieuwe revisie wordt gemaakt), die wordt uitgevoerd door de hg-commit opdracht.

De opdracht hg commit kan de eerste keer mislukken. Mercurial registreert uw naam en adres bij elke revisie, zodat u of andere gebruikers contact kunnen opnemen met de auteur van elke wijziging. Om de gebruikersnaam in te stellen, moet u wijzigingen aanbrengen in het hgrc-bestand dat zich in de .hg-directory in de werkdirectory bevindt. De initiële inhoud van dit bestand zou er ongeveer zo uit moeten zien:

# Dit is een Mercurial-configuratiebestand.

gebruikersnaam = Voornaam Achternaam [e-mail beveiligd]

De regel "" declareert een sectie van het configuratiebestand. U kunt "gebruikersnaam =..." lezen als "stel de waarde van de gebruikersnaamvariabele in de ui-sectie in". Secties gaan door tot de start van nieuwe secties. Lege regels en regels die beginnen met "#" worden genegeerd. U kunt elke tekst als gebruikersnaam gebruiken, aangezien deze informatie voor andere mensen is en niet voor Mercurial om te interpreteren. In het bovenstaande voorbeeld werd hiervoor een algemene conventie gebruikt: een combinatie van naam en e-mailadres.

Wanneer we wijzigingen doorvoeren, neemt Mercurial ons mee naar een teksteditor om een ​​opmerking in te voeren met een beschrijving van de wijzigingen die we in die wijzigingenset hebben aangebracht. Zo'n beschrijving wordt een wijzigingsbericht genoemd (wijzigingsbeschrijving, revisiebeschrijving). Dit zal een record zijn voor lezers van wat we hebben gedaan en waarom, en zal worden uitgevoerd wanneer we het hg log-commando uitvoeren nadat we klaar zijn met het publiceren van de revisie.

De editor die wordt geopend wanneer u het hg commit-commando uitvoert, bevat een lege regel en enkele regels die beginnen met "HG:".

HG: Voer een commit-bericht in. Regels die beginnen met "HG:" worden verwijderd.

HG: Laat bericht leeg om vastlegging af te breken.

HG: --

HG:gebruiker:gebruiker

HG: tak "standaard"

HG: voorbeeld.txt gewijzigd

Mercurial negeert regels die beginnen met "HG:". Het gebruikt ze alleen om ons te vertellen naar welke bestanden het wijzigingen zal schrijven. Het wijzigen of verwijderen van deze regels heeft geen enkele invloed. Als u van gedachten verandert over het publiceren van wijzigingen terwijl u een opmerking bewerkt, sluit dan gewoon de editor af zonder het bestand dat u aan het wijzigen bent op te slaan. Dit veroorzaakt geen wijzigingen in de repository of de werkdirectory.

De opdracht hg log drukt standaard alleen de eerste regel van de wijzigingsbeschrijving af. Daarom is het beter om een ​​opmerking te schrijven, zodat de eerste regel gescheiden is. Er zijn geen vaste regels voor de rest van de revisiebeschrijving. Mercurial zelf verwerkt of bekommert zich niet om de inhoud van het wijzigingsbericht, hoewel uw project regels kan hebben die bepaalde opmaak afdwingen.

Laten we deze bewerkingen herhalen met behulp van de TortoiseHg Workbench GUI. Voordat het bestand aan de werkdirectory wordt toegevoegd, ziet het venster er als volgt uit.

Afbeelding 5.3.5 Bestand toevoegen aan werkmap

Laten we het bestand naar de repository overbrengen en het venster bijwerken door op de knop aan de linkerkant van de werkbalk te klikken. Laten we het bestand toevoegen aan het versiebeheersysteem met behulp van de juiste contextmenuopdracht (vergelijkbaar met hg add).

Afbeelding 5.3.6 Opdracht contextmenu

Afbeelding 5.3.7 Bestand toevoegen

Nadat het bestand is toegevoegd, wordt de beschrijving van de revisie in het venster rechtsboven geschreven en wordt een nieuwe revisie gemaakt door op de knop "Repareren" te klikken. Een overzicht van de aangebrachte wijzigingen verschijnt in het venster rechtsonder. U kunt zien dat de wijzigingen worden weergegeven in de vorm van grafieken.

Afbeelding 5.3.8 Grafieken wijzigen

U kunt ook wijzigingen vastleggen met de opdracht Hg Commit in het contextmenu van een bestand dat in de repository is geplaatst zonder Workbench te starten.

Figuur 5.3.9 Wijzigingen doorvoeren

Het commando hg log of hg diff komt hier overeen met "Bestandsrevisies vergelijken" (klik met de rechtermuisknop op de bestandsnaam).

Figuur 5.3.10 Vergelijking bestandsrevisie

In hetzelfde venster kunt u terugkeren naar een van de vorige revisies met de opdracht "Terug naar revisie ..." of "Wijzigingen terugzetten ..." in het hoofdvenster. Laten we het demonstreren met een voorbeeld, waarbij we vooraf nog enkele wijzigingen in het voorbeeld.txt-bestand repareren. De rood gemarkeerde regel is een omgekeerde wijziging.

Afbeelding 5.3.11 Wijzigingen annuleren

5.3.5 Een kopie maken van de repository

Hoewel je de repository als een gewone map kunt kopiëren, is het beter om het ingebouwde Mercurial-commando te gebruiken. Het wordt hg-kloon genoemd omdat het een identieke kopie van een bestaande repository maakt. Een van de voordelen van het gebruik van hg clone is dat u hiermee repositories via het netwerk kunt klonen. Een andere is dat het onthoudt waar we het van hebben gekloond.

Elke Mercurial-repository is compleet, op zichzelf staand en onafhankelijk. Het bevat een eigen kopie van de projectbestanden en hun geschiedenis. Een gekloonde repository onthoudt waar het van gekloond is, maar praat niet met die repository, of een andere, tenzij je het zegt. Daarom bent u vrij om te experimenteren met uw repository. Dit is veilig omdat uw repository een "gesloten sandbox" is, waarvan wijzigingen alleen van invloed zijn op zichzelf.

Laten we een externe kopie van onze opslag maken (we zullen de Google Drive-map gebruiken, wat een cloudservice op zich is), waarvoor we de opdrachtreeks File\Clone Storage in TortoiseHg Workbench zullen uitvoeren. Het resultaat is weergegeven in de volgende afbeelding.

Afbeelding 5.3.12 Een externe opslagkopie maken

Mercurial stelt ons in staat om wijzigingen naar een andere repository te pushen vanuit de repository waarin we ons momenteel bevinden. Laten we een nieuwe revisie toevoegen (onder de lokale wijzigingsopmerking) aan de oorspronkelijke repository en het commando Repository\Sync\Push uitvoeren. Met de workbench-interface kunt u alleen die revisies selecteren die u moet "duwen". Houd er rekening mee dat er een nieuwe vertakking is gemaakt in de externe kluisrepository voor de opgehaalde revisie.

Vergelijkbare documenten

Kenmerken van het versiebeheersysteem - een programma dat is ontworpen om te werken met veranderende documenten. Zijn eigenschappen en gebruikspraktijken. Intern opslagapparaat. Werkkopie van documenten met versiebeheer. Gecentraliseerde en gedistribueerde VCS.

presentatie, toegevoegd 01/05/2014


Analyse van methoden en middelen om de toegang tot bestanden te controleren. Problemen met de beveiliging van het werken met bestanden, middelen om de toegang ertoe te controleren. Interface-bouwideologie, architectuurvereisten. Het werk van de klassen van het systeem. Schatting van de kosten van softwareproducten.

proefschrift, toegevoegd 21-12-2012


Architectuuranalyse van Windows 8. Vergelijking met eerdere versies (Moderne UI-interface, werken met accounts, beveiligingsmodel, taakbeheer, bestandsgeschiedenis, systeemherstel, opslagruimten). Functies van verschillende versies van Windows 8.

scriptie, toegevoegd 25-01-2016


Stadia van ontwikkeling van een geautomatiseerd systeem voor het ontvangen en boeken van tafelorders in etablissementen. Analyse van de ontwikkelomgeving van Android Development Tools. Algemene kenmerken van het diagram met componenten van de IOS-toepassing. Overweging van het serverversiebeheersysteem.

scriptie, toegevoegd 14-05-2014


Grafische interfaces en uitbreidingen voor DOS. De geschiedenis van de ontwikkeling van het Microsoft Windows-besturingssysteem. Innovaties van zijn moderne versies: gebruikersinterface, taalintegratie, beveiligingssystemen. Chronologie van ontwikkeling en architectuur van het GNU/Linux-systeem.

samenvatting, toegevoegd 25-10-2010


DirectX-ontwikkelingskit voor Microsoft Windows, kenmerken van sets COM-compatibele objecten in zijn samenstelling. Belangrijkste kenmerken van versies, shader-talen. Beschrijving van de belangrijkste gebruikte functies. De broncode van het programma, voorbeelden van zijn werk.

scriptie, toegevoegd 16-02-2015


Windows als tussenpersoon tussen de gebruiker en het besturingssysteem, waardoor het proces van communicatie tussen hen, de geschiedenis van de vorming en ontwikkeling van de eerste versies, wordt vergemakkelijkt. Functionele kenmerken en verschillen tussen Windows 95/98/ME en Windows NT/2000/XP/Vista/7, hun architecturale oplossingen.

presentatie, toegevoegd 23-10-2013


Het verminderen van de kosten van reparatiewerkzaamheden om defecten te elimineren, bereikt door een informatiesysteem te gebruiken om ze te beheersen. Analyse van het vakgebied en software. Bereken besparingen door de gebruikersproductiviteit te verhogen.

proefschrift, toegevoegd 19/01/2017


Concept, essentie, structuur en soorten besturingssystemen. Kenmerken van het Windows XP-besturingssysteem, vereisten voor de installatie, vergelijkende analyse van versies, configuratiefuncties, versie-updates, installatie van apparaatstuurprogramma's en het toevoegen van nieuwe.

samenvatting, toegevoegd 20-10-2009


Het uiterlijk van de eerste versies van Windows, hun grafische interfaces en extensies voor DOS. Windows 3.x- en Windows 9.x-families, hun kenmerken en belangrijkste functies. De evolutie van Plug and Play-technologie. De belangrijkste verbeteringen in moderne versies van Windows.

Omdat ons team van programmeurs meerdere projecten tegelijk ontwikkelt, ontstond al snel de behoefte aan een versiebeheersysteem.

De zoektocht begon natuurlijk met de studie van Habr - en leidde tot een onverwacht resultaat. Ondanks het feit dat versiebeheersystemen al sinds 1986 bestaan, zijn de meeste tutorials over het werken met modern versiebeheersystemen bleken onvolledig en sterk gebonden aan het werken met de opdrachtregel.

We hebben in het algemeen niets tegen de opdrachtregel, maar in ons kleine ontwikkelteam (4 personen) zijn er geen fans van het werken met de opdrachtregel :).

Waarom denken we dat werken met de opdrachtregel inefficiënt is?

1. Tijdverspilling met het invoeren van gegevens. Het typen van opdrachten duurt veel langer dan klikken met de muis.
2. Tijdverspilling om te leren. Het leren van een nieuwe syntaxis in een tijdperk van schone interfaces duurt zeker langer dan het leren van een GUI.
3. Foutkans. Het is gemakkelijker om een ​​fout te maken bij het invoeren van gegevens via de opdrachtregel (niemand heeft de menselijke factor geannuleerd).
4. overtreding principes van automatisering. Dit is misschien wel het belangrijkste punt. De computer is ontworpen om het werk te versnellen en een persoon te vervangen bij het uitvoeren van routinehandelingen. In het geval van de opdrachtregel werken we altijd handmatig moet eigenlijk elke keer schrijven hetzelfde programmacode (zij het primitief).

1. Er zullen stapsgewijze instructies zijn (onze programmeurs zullen eraan werken).
2. Het zal van begin tot eind werken (dat wil zeggen, hiermee krijgt u een klein maar compleet resultaat - een werkend gedistribueerd versiebeheersysteem).
3. Werkt alleen met GUI's (zie hierboven voor redenen).

Invoering

Als je geen fan bent van "For Dummies"-handleidingen, dan kun je dit artikel overslaan en je eigen weg gaan om het probleem van het verhogen van de VCS op te lossen.

Gebruikte programma's en diensten

• Mercurial is een platformonafhankelijk gedistribueerd versiebeheersysteem dat is ontworpen om efficiënt te werken met zeer grote coderepository's.
• TortoiseHg is een grafische frontend voor het versiebeheersysteem van Mercurial.
• Bitbucket is een webservice voor projecthosting en samenwerking op basis van versiebeheer van Mercurial en Git.

Een versiebeheersysteem implementeren - stapsgewijze instructies

Deze client zal geïnstalleerd moeten worden op alle computers van waaruit gezamenlijk projecten ontwikkeld zullen worden.

In deze handleiding worden alle stappen voor het instellen van en werken met het versiebeheersysteem uitgevoerd met: TortoiseHg-versie: 2.10.1 voor Windows 64-bit met Mercurial 2.8.1.

2. Registreer u bij de Bitbucket-webservice: https://bitbucket.org/
Het hele registratieproces komt neer op het invullen van contactgegevens (gebruikersnaam, e-mail, enz.) en het bevestigen van het e-mailadres dat tijdens de registratie is opgegeven door op de knop "Bevestig dit e-mailadres" te klikken in de brief die na registratie is ontvangen.

Alle leden van uw ontwikkelteam moeten zich ook registreren bij Bitbucket. Tot groot geluk van startups heeft deze service een gratis account waarmee je privérepositories kunt maken met 5 gebruikers. Het is ook mogelijk om het maximale aantal teamleden dat deelneemt aan de ontwikkeling gratis te verhogen tot 8 personen.

U kunt de volledige lijst met plannen bekijken door op de link te klikken: https://bitbucket.org/plans

3. Door in te loggen op uw account in de Bitbucket-service, kunt u de interfacetaal van uw account onmiddellijk wijzigen in Russisch.

Om dit te doen, selecteert u in de rechterbovenhoek van het hoofdmenu in de vervolgkeuzelijst het gedeelte "Account beheren" en selecteert u op de pagina die wordt geopend de interfacetaal die u nodig hebt in de vervolgkeuzelijst "Taal"

4. Om een ​​repository voor uw project aan te maken, moet u naar de hoofdpagina van uw account gaan (https://bitbucket.org/dashboard/overview) en op de knop "Create your first repository" klikken

5. Geef op de pagina voor het maken van een nieuwe repository de volgende instellingen op:

Naam - Geef een naam op voor uw nieuwe repository. Deze naam wordt gebruikt om een ​​toegangslink naar uw repository te bouwen.
Belangrijk! Het is beter om de naam in Latijnse letters te specificeren, anders eindigt de link naar de repository met koppeltekens en ziet er moeilijk te begrijpen uit: http://[email protected]/yourlogin/--------

Beschrijving - Geef een korte beschrijving van uw repository (veld is optioneel)
- Toegangsniveau - Vink het vakje aan als u wilt dat alleen leden van uw ontwikkelteam toegang hebben tot uw repository (private repository).
- Forks maken - Vink "Alleen privévorken toestaan" aan
- Type opslagplaats - Selecteer "Mercurial"
- Projectbeheer - Vink "Issue Tracker" en "Wiki" aan
- Taal - Selecteer de ontwikkeltaal waarin uw project is geschreven. In mijn geval is dat PHP.

Na voltooiing van het specificeren van alle instellingen, ziet de pagina er ongeveer zo uit:

Controleer nogmaals de ingevoerde gegevens en als alles correct is ingevoerd, klikt u op de knop "Repository maken".

6. Nadat je een nieuwe repository hebt gemaakt, ga je naar de pagina Aan de slag:

7. Maak een lege map op uw computer aan waarin uw projectbestanden die zijn verbonden met het Mercurial-versiebeheersysteem in de toekomst worden opgeslagen.

Belangrijk! De map moet leeg zijn. Om bijvoorbeeld een map te verbinden met een reeds bestaand project (een heleboel programmacode), moest ik tijdelijk alle bestanden naar een andere map overbrengen (maak een reservekopie). Later zullen we alle bestanden terugzetten naar hun plaats, maar voor nu moet je de verbindingsmap volledig wissen.

8. In het geopende venster moet u in het veld "Bron" een link opgeven om verbinding te maken met de repository die u vanaf stap 6 hebt gemaakt

En klik op de knop "Klonen".

9. Het systeem zal u vragen om een ​​wachtwoord van uw account in de Bitbucket-service, voer dit in.

10. Als alles is gedaan zonder van deze instructie af te wijken, dan verschijnt in de map een nieuwe “.hg”-directory met servicebestanden van de aangemaakte repository.

11. Nu kunt u de bestanden (programmacode) van uw project veilig terugsturen naar de map die bedoeld is voor het opslaan van projectbestanden die zijn aangesloten op het Mercurial-versiebeheersysteem

Belangrijk! Raak de servicedirectory ".hg" niet aan. Het is nodig om VCS te laten werken.

12. Klik nogmaals met de rechtermuisknop op onze projectmap en selecteer in het vervolgkeuzemenu het item "Hg Commit ..."

13. U ziet een dialoogvenster dat is ontworpen om alle wijzigingen aan uw project vast te leggen (in dit geval hebben we onze programmacodes toegevoegd aan de aanvankelijk lege projectmap).

U dient alle gewijzigde (toegevoegde) bestanden te selecteren, een opmerking (bijvoorbeeld versie 1.00) bij de wijziging op te geven en op de knop "Repareren" te klikken.

Het systeem zal u vragen om de toevoeging te bevestigen, klik op "Toevoegen".

14. Als alles correct is gedaan, zal het systeem de aangebrachte wijzigingen herstellen en ziet u zoiets als dit venster:

In de toekomst, wanneer u aan het ontwikkelen bent, voert u na het voltooien van een klein stukje code de actie uit paragraaf 12 uit (druk op "Hg Commit ...") om de wijziging in het versiebeheersysteem door te voeren. Dit geeft je de mogelijkheid om het systeem op elk moment terug te draaien naar een eerdere commit.

Gezien het bovenstaande zou je in de praktijk een meer gedetailleerde opmerking dan "Versie 1.00" moeten schrijven voor elk van de fixaties.

16. In het venster dat wordt geopend, kunt u de volledige geschiedenis van opgeslagen (toegewezen) wijzigingen in de code zien, u kunt teruggaan naar de gewenste vastlegging en ook de wijzigingen naar de eerder gemaakte repository sturen.

Selecteer hiervoor in het configuratiescherm de knop "Inkomende wijzigingen pushen naar".

Daarna krijgt u dialoogvensters te zien waarin u wordt gevraagd om de "push" te bevestigen en om een ​​wachtwoord voor uw Bitbucket-account op te geven. Ga akkoord en voer een wachtwoord in.

Het systeem begint met het kopiëren van de bestanden naar uw repository op de Bitbucket-server. Neem de tijd en wacht tot het proces is voltooid.

17. Nu wordt een kopie van uw projectbestanden opgeslagen in uw repository op Bitbucket-servers. In uw Bitbucket-account kunt u de volledige geschiedenis van uw project zien.

Tussenresultaten van het aansluiten van het versiebeheersysteem (VCS)

Het proces van het aansluiten van uw tweede computer is om de bestanden van de repository naar de tweede computer te kopiëren. Je moet stap 1 - TortoiseHg installeren en 7 - Repository-bestanden importeren, doorlopen om de bestanden naar je tweede, derde en volgende werkende computer te kopiëren.

Medewerkers koppelen aan uw repository.

Laten we daarom nu een andere programmeur aan ons project koppelen (we zullen een deelnemer uitnodigen) en een werkplek voor hem inrichten.

Een medewerker verbinden met onze repository

Hoe te registreren op de service en TortoiseHg te installeren, vertelde ik iets eerder in deze handleiding. Daarom zou dit proces voor u en uw collega's geen problemen mogen opleveren.

19. Log in op uw Bitbucket-account:

Klik op de knop "Uitnodiging verzenden" in het gedeelte "Een lid uitnodigen voor deze repository".

20. Het systeem toont een dialoogvenster waarin u wordt gevraagd het e-mailadres in te voeren van de gebruiker die u toegang wilt geven tot de repository. Daarnaast moet u toegangsrechten specificeren ("lezen" of "schrijven"). Omdat in deze handleiding laten we zien hoe u een andere ontwikkelaar kunt verbinden met de repository en vervolgens het "record" specificeert.

Na het invoeren van het e-mailadres van de medewerker en het opgeven van toegangsrechten, klikt u op de knop "Delen".

21. De uitgenodigde deelnemer ontvangt een e-mail met een link naar de uitnodiging. Hij moet deze link volgen en de uitnodiging accepteren om toegang te krijgen tot uw repository.

Nogmaals, alle leden van uw repository moeten geregistreerd zijn bij de Bitbucket-service.

22. Nadat de uitnodiging is geaccepteerd, ziet het nieuwe lid deze repository in zijn account en zijn link om toegang te krijgen met TortoiseHg.

Alle wijzigingen die door jou en je helpers zijn gemaakt, worden opgeslagen in je repository. U kunt op elk moment zien wat er is gewijzigd en desgewenst uw project terugdraaien naar de gewenste versie.

Ik denk dat dit inleidende artikel over het implementeren van versiebeheer zonder de opdrachtregel hier moet eindigen. Door de hierboven beschreven stappen te doorlopen, kunt u een volwaardige VCS op uw project implementeren, d.w.z. na het doorlopen van alle stappen, krijgt u, hoewel niet geweldig, maar een volledig resultaat.

We hebben deze aanpak gebruikt om het project te ontwikkelen.

Bij elke operatie die ik de prestaties heb gemeten, presteerde Mercurial beter dan Subversion. De snelheid is 2-6 keer meer als het gaat om: lokaal Subversion 1.4.3 repositories (snelste toegangsmethode). In een meer realistisch gebruik, een netwerkrepository, bevindt Subversion zich in een veel slechtere positie. Vanwege het feit dat Subversion-commando's met de server moeten communiceren en Subversion geen bruikbare replicatiefaciliteiten heeft, worden serverprestaties en netwerkbandbreedte zelfs voor kleine projecten knelpunten.

Daarnaast heeft Subversion extra schijfruimte nodig om netwerkverzoeken te vermijden bij het uitvoeren van bepaalde bewerkingen: zoeken naar gewijzigde bestanden (status) en het weergeven van wijzigingen (diff). Het resultaat is een Subversion-werkkopie die zo groot (of groter) is als de Mercurial-repository en de werkdirectory samen, ook al bevat de Mercurial-repository de volledige geschiedenis van het project.

Subversion heeft uitgebreide ondersteuning voor tooling van derden. In dit opzicht is Mercurial nu een aanzienlijke achterstand. Hoewel de kloof kleiner wordt, presteren sommige GUI-hulpprogramma's voor Mercurial beter dan hun Subversion-tegenhangers. Net als Mercurial heeft Subversion een uitstekende gebruikershandleiding.

Omdat Subversion geen geschiedenis van wijzigingen op de client bijhoudt, is het zeer geschikt voor het beheren van projecten die een groot aantal binaire bestanden bevatten. Als je 50 wijzigingen aanbrengt in een onsamendrukbaar bestand van tien megabyte, blijft de schijfruimte die door Subversion wordt gebruikt ongewijzigd. De ruimte die door een van de gedistribueerde versiebeheersystemen wordt gebruikt, zal snel toenemen in verhouding tot het aantal wijzigingen, omdat de verschillen tussen revisies groot zijn.

Bovendien is het meestal moeilijk, en vaak zelfs onmogelijk, om verschillende versies van een binair bestand samen te voegen. Met Subversion kan de gebruiker een bestand vergrendelen, wat de gebruiker tijdelijke exclusieve rechten geeft om er wijzigingen in aan te brengen. Dit kan een aanzienlijk voordeel zijn voor een project dat uitgebreid gebruik maakt van binaire bestanden.

Mercurial kan de changelog importeren uit de Subversion repository. Het omgekeerde proces is ook mogelijk. Dit maakt het mogelijk om de wateren te testen en tegelijkertijd Mercurial en Subversion te gebruiken voordat wordt besloten om te migreren of niet. Geschiedenisconversie is een stapsgewijs proces, dus u kunt een eerste conversie uitvoeren en vervolgens nieuwe wijzigingen aanbrengen.

1.6.2. git

Git is een gedistribueerd versiebeheersysteem dat is ontwikkeld om de broncode van de Linux-kernel te beheren. Net als bij Mercurial werd het oorspronkelijke ontwerp van het systeem beïnvloed door Monotone.

Git biedt een grote lijst met commando's, die in versie 1.5.0 139 unieke eenheden bereikt. Het heeft de reputatie een moeilijk leermiddel te zijn. In vergelijking met Git legt Mercurial de nadruk op eenvoud.

Qua prestaties is Git erg snel. In sommige gevallen is het sneller dan Mercurial (tenminste onder Linux), en in andere gevallen is Mercurial sneller. Onder Windows, zowel qua prestaties als algemene ondersteuning, is Git echter veel slechter dan Mercurial op het moment van schrijven.

Hoewel de Mercurial-repository geen onderhoudswerkzaamheden vereist, vereist de Git-repository regelmatig handmatige handelingen "opnieuw verpakken" eigen metagegevens. Als dit niet wordt gedaan, beginnen de prestaties te dalen, samen met een toename van de hoeveelheid ingenomen schijfruimte. De schijfarray van een server die meerdere Git-repository's bevat die geen strikte frequentie volgen "opnieuw verpakken", raakt vroeg of laat de capaciteit vol, waardoor het dagelijkse back-upproces al snel meer dan 24 uur kan duren. Alleen maar "Ingepakt" een Git-repository neemt iets minder ruimte in beslag dan een Mercurial-repository, maar een onverpakte repository zal enkele ordes van grootte groter zijn.

De kern van Git is geschreven in C. Veel Git-commando's zijn geïmplementeerd als Shell-scripts of Perl-scripts, en de kwaliteit van deze scripts varieert sterk. Ik heb verschillende installaties gezien waar scripts gewoon blijven uitvoeren ondanks fatale fouten.

Mercurial biedt de mogelijkheid om versiegeschiedenis uit een Git-repository te importeren.

1.6.3. CVS

CVS is waarschijnlijk het meest gebruikte versiebeheersysteem ter wereld. Door zijn eerbiedwaardige leeftijd, evenals de rommel die er binnen heerst, is het jarenlang zeer slecht onderhouden.

CVS is gebaseerd op een gecentraliseerde client-server-architectuur. Het groepeert geen bestandswijzigingen in atomic commits, waardoor mensen gemakkelijk kunnen "breek de bouw": Eén persoon kan met succes een deel van de wijzigingen in de repository vastleggen en vervolgens worden buitengesloten vanwege de noodzaak om een ​​samenvoeging uit te voeren. Dit zal leiden tot een situatie waarin de rest van de deelnemers slechts een deel van de veranderingen zal zien die ze hadden moeten zien. Deze functie is ook van invloed op hoe u met de geschiedenis van wijzigingen werkt. Als je alle wijzigingen wilt zien die een van de teamleden heeft aangebracht om een ​​bepaald probleem op te lossen, moet je handmatig de beschrijvingen en de datum van wijzigingen bekijken die voor elk getroffen bestand zijn aangebracht (als je al weet welke bestanden zijn getroffen).

CVS behandelt nogal verwarrende concepten van branches en tags, die ik niet eens zal proberen te beschrijven in dit boek. Het ondersteunt het hernoemen van zowel bestanden als mappen niet, dus de repository kan vrij gemakkelijk worden beschadigd. Omdat er vrijwel geen interne integriteitsmechanismen zijn, is het vaak onmogelijk om met zekerheid te zeggen of een repository beschadigd is, en zo ja, hoe. Daarom zou ik CVS niet aanbevelen voor gebruik in een bestaand of nieuw project.

Mercurial biedt de mogelijkheid om CVS-versiegeschiedenis te importeren. Er zijn echter een paar valkuilen die elke andere CVS-importtool ook tegenkomt. Het ontbreken van atomaire wijzigingen en versiebeheer van de hiërarchische bestandssysteemgegevens maakt het onmogelijk om de CVS-wijzigingsgeschiedenis volledig te reconstrueren, dus in sommige gevallen worden veronderstellingen gemaakt en worden hernamen meestal niet getoond. Omdat veel CVS-beheertaken handmatig moeten worden uitgevoerd, wat het risico op fouten vergroot, is het gebruikelijk dat de CVS-importtool veel repository-integriteitsfouten retourneert (absoluut onrealistische revisiedatums en bestanden die de laatste tien jaren zijn slechts een paar van de minst interessante problemen die ik uit eigen ervaring kan bedenken).

1.8. Een korte geschiedenis van versiebeheer

De bekendste van de oude hulpprogramma's voor versiebeheer is SCCS (Source Code Control System), dat begin jaren '70 werd geschreven door Marc Rochkind van Bell Labs. SCCS werkte met afzonderlijke bestanden en vereiste dat elke persoon die aan een project werkte, toegang had tot een gedeelde werkruimte die in één instantie bestond. Slechts één persoon kon een bestand tegelijk bewerken; bestandstoegangsconflicten werden opgelost met vergrendelingen. Een veel voorkomende situatie was het vergeten om het slot na het bewerken te ontgrendelen, waardoor andere mensen het bestand niet konden openen zonder de hulp van een beheerder.

Walter Tichy ontwikkelde begin jaren tachtig een gratis alternatief voor SCCS; hij noemde zijn programma RCS (Revision Control System, revisiecontrolesysteem). Net als SCCS, vereiste RCS dat ontwikkelaars zowel in een enkele, gedeelde werkruimte werkten als bestanden vergrendelen om te voorkomen dat meerdere mensen tegelijkertijd bestanden wijzigen.

Later, in de jaren tachtig, gebruikte Dick Grune RCS als basis voor een set shellscripts, oorspronkelijk cmt genoemd en later omgedoopt tot CVS (Concurrent Versions System). Een belangrijke innovatie van CVS was dat ontwikkelaars gelijktijdig en tot op zekere hoogte onafhankelijk in hun persoonlijke werkruimten konden werken. Het waren deze ruimtes die de constante aanval van ontwikkelaars op elkaars hielen verhinderden, wat gebruikelijk was in SCCS en RCS. Elke ontwikkelaar had een kopie van elk projectbestand, ontwikkelaars konden hun kopieën onafhankelijk wijzigen. Ze moesten hun eigen bewerkingen samenvoegen net voordat ze de wijzigingen doorvoeren naar de centrale repository.

Brian Berliner nam de originele scripts van Grün en herschreef ze in C, waarmee hij in 1989 code vrijgaf die later uitgroeide tot de moderne versie van CVS. CVS verwierf vervolgens de mogelijkheid om via het netwerk te werken en kreeg een client-server-architectuur. De architectuur van CVS is gecentraliseerd: alleen de server heeft een kopie van de projectgeschiedenis. De werkkopieën van de client bevatten alleen de nieuwste bestandsinstanties en weinig metagegevens om de server te lokaliseren. Het CVS-systeem heeft ongekend succes geboekt: het is waarschijnlijk het meest gebruikte versiebeheersysteem ter wereld.

Begin jaren negentig ontwikkelde Sun Microsystems een vroeg gedistribueerd versiebeheersysteem genaamd TeamWare. Elke werkkopie van TeamWare bevatte een volledige kopie van de wijzigingsgeschiedenis van het project. Het concept van een centrale repository ontbrak als zodanig in TeamWare. (Zoals CVS RCS gebruikte om geschiedenis op te slaan, gebruikte TeamWare SCCS.)

Naarmate de jaren negentig vorderden, groeide het bewustzijn van verschillende CVS-problemen. Het systeem schrijft gelijktijdige wijzigingen naar meerdere bestanden afzonderlijk in plaats van ze te groeperen in één logisch atomaire bewerking. De manier waarop de bestandshiërarchie wordt beheerd, is niet erg goed: het is gemakkelijk om de repository te verknoeien door bestanden en mappen te hernoemen. Bovendien zijn CVS-bronnen niet gemakkelijk te begrijpen en te onderhouden, waardoor het bijna onoverkomelijk is geworden "pijngrens" oplossingen voor deze architecturale problemen.

In 2001 begonnen Jim Blandy en Karl Fogel - twee ontwikkelaars die eerder aan CVS hadden gewerkt - een project om het te vervangen door een tool met een betere architectuur en schonere code. Het resultaat - Subversion - week niet af van het gecentraliseerde client-servermodel van CVS, maar voegde atomaire commits toe aan meerdere bestanden, beter naamruimtebeheer en andere functies die Subversion een beter hulpmiddel maakten dan CVS. Sinds de release van de eerste versie is Subversion snel populair geworden.

Min of meer gelijktijdig begon Graydon Hoare te werken aan een ambitieus versiebeheersysteem dat hij Monotone noemde. Dit systeem lost niet alleen veel interne CVS-problemen op en heeft een gedistribueerde architectuur, maar het gaat in sommige van zijn innovaties verder dan verschillende oudere (en latere) versiecontrolesystemen. Monotone gebruikt cryptografische hashes als identifiers en heeft een inherent begrip van " vertrouwen " code uit verschillende bronnen.

Het leven van Mercurial begon in 2005. Hoewel sommige aspecten van de architectuur werden beïnvloed door Monotone, is Mercurial gericht op gebruiksgemak, hoge prestaties en schaalbaarheid voor zeer grote projecten.

Heb je een geweldig nieuw bedrijfsidee voor softwareontwikkeling?Moet u een technologisch geavanceerde oplossing ontwikkelen? Of heb je een groot team van programmeurs die aan dezelfde taak werken? Onthoud dan deze drie woorden:versiebeheersysteem .

Versiebeheersysteem (cvs), 2017 - Vergelijk: Git, SVN, Mercurial

, of vcs- dit zorgt ervoor dat het project niet uit elkaar valt als er veel mensen aan werken. Programmeurs, managers, copywriters kunnen elk aan hun eigen stuk werken zonder elkaar te hinderen en zonder onherstelbare schade te veroorzaken.

Als u niet bekend bent met het concept:versiebeheersystemen, dan hier alles wordt heel duidelijk weergegeven.

Of bekijk de video van GitHub.

Dus welk versiebeheersysteem is geschikt voor uw project?

We hebben verschillende populaire oplossingen vergeleken om u te helpen bij het maken van uw keuze.

Dit is een zeer gespecialiseerd technisch onderwerp. We hebben geprobeerd onze review voor iedereen begrijpelijk te maken. Maar als u geen programmeerervaring heeft, neem dan contact op met uw ontwikkelingsafdeling voordat u een beslissing neemt.

Versiecontrolesystemen, inclusief de bekende SVN (Subversion) en Git, werden oorspronkelijk gemaakt zodat ontwikkelingsteams aan samenwerkingsprojecten konden werken zonder verwarring te veroorzaken. In het besturingssysteem hoeft u niet zelfstandig de codevertakkingen te volgen en de toelichting daarop te bestuderen. In plaats daarvan wordt een centrale repository gebruikt, waar alles wordt geordend, gestructureerd. Hier is het handig om bestanden bij te werken, opmerkingen toe te voegen en zelfs projecttakken samen te voegen.

Meningen over wat?versiebeheersysteemde beste, variëren sterk, en dit leidt tot verhitte discussies onder programmeurs. Selecteren en studerenversiebeheersystemenHoud er voor uw project rekening mee dat de voordelen van de ene of de andere oplossing vaak subjectief zijn. Bijvoorbeeld de persoonlijke voorkeuren van de programmeur, of bijvoorbeeld indicatoren zoals prestaties, IDE-plug-inmogelijkheden, enz.

Het belangrijkste verschil tussen versiebeheersystemen is of ze client-server of gedecentraliseerd (p2p) zijn. Hebben ze een centrale repository (server) waar de code vandaan komt en waar deze wordt geretourneerd met de aangebrachte wijzigingen. Of is het een kopie in lokale opslag, bijgewerkt via peers: een meer gedecentraliseerd netwerk dat wordt gebruikt voor synchronisatie, het delen van patches (sets van wijzigingen) en het onderhouden van de huidige code.

Het is ook de moeite waard om rekening te houden met de snelheid, functionaliteit en drempel voor het invoeren / beheersen van een bepaaldcontrolesystemen. Overweeg de meest voorkomendeversiebeheersystemenen de redenen waarom programmeurs bepaalde oplossingen verkiezen.

Simultaan versiesysteem (CVS)

CVS verscheen in de jaren tachtig en is nog steeds populair bij zowel commerciële productontwikkelaars als open-sourceontwikkelaars.

CVS is onderworpen aan de voorwaardenGNU General Public License en stelt u in staat om de gewenste versie van het project van de server te krijgen - "uitchecken" (uittreksel) , en dan terug naar de server, "inchecken" (retour),met de aangebrachte wijzigingen.

Oorspronkelijk CVS is gemaakt om versieconflicten te voorkomen. Alle deelnemers kregen alleen de meest recente versie van de code om mee te werken. Het was het eerste versiebeheersysteem. De gebruiker moest snel wijzigingen in de repository doorvoeren voordat anderen hem voor waren.

Nu CVS heeft ondersteuning voor het werken aan projecten met code branches. Het blijken verschillende varianten van het product met verschillende kenmerken, die later kunnen worden gecombineerd.

CVS-servers draaien meestal onder Unix, maar CVS -Clients zijn ook beschikbaar op andere populaire besturingssystemen. CVS - "volwassen", beproefdversiebeheersysteem. Het is nog steeds een open source systeem, maar nieuwe functies worden tegenwoordig zelden toegevoegd.

Tegelijkertijd is CVSNT een versie die is opgedeeld in een apart project CVS voor Windows-servers - nu breidt het zijn functionaliteit actief uit.

Voordelen:

• Beproefde technologie die al tientallen jaren op de markt is.

Gebreken:

• Het hernoemen of verplaatsen van bestanden wordt niet weergegeven in de geschiedenis
• Beveiligingsrisico's in verband met symbolische koppelingen naar bestanden
• Geen ondersteuning voor atomaire operaties, wat kan leiden tot codecorruptie
• Bewerkingen met programmacode-vertakkingen zijn duur, aangezien ditcontrole systeemniet bedoeld voor langetermijnprojecten met codetakken

Apache-ondermijning (SVN)

SVN gemaakt als alternatief CVS om tekortkomingen te corrigeren CVS en tegelijkertijd zorgen voor een hoge compatibiliteit ermee.

Vind CVS leuk , SVN is een gratis systeem versiebeheer open source. Met het enige verschil dat het wordt gedistribueerd onder de Apache-licentie, en niet onderGNU General Public License.

SVN gebruikt zogenaamde atomaire operaties om de integriteit van de database te behouden. Wanneer een nieuwe versie wordt uitgebracht, worden ofwel alle fixes of geen ervan toegepast op het uiteindelijke product. Zo wordt de code beschermd tegen chaotische deelwijzigingen die niet met elkaar in overeenstemming zijn en fouten veroorzaken.

Veel ontwikkelaars zijn overgestapt opSVN als de nieuwe technologie heeft de beste eigenschappen geërfd CVS en breidde ze tegelijkertijd uit.

Terwijl in CVS bewerkingen met code-vertakkingen zijn duur en worden niet geleverd door de systeemarchitectuur, SVN is speciaal hiervoor gemaakt. Dat wil zeggen, voor grotere projecten met vertakkingscode en veel ontwikkelingsgebieden.

De nadelen van SVN zijn de relatief lage snelheid en het ontbreken van gedistribueerd versiebeheer. Gedistribueerd versiebeheer gebruikt een peer-to-peer-model in plaats van een gecentraliseerde server om code-updates op te slaan. Hoewel het peer-to-peer-model het beste werkt in open source-projecten, is het in andere gevallen niet ideaal. Het nadeel van de server-side benadering is dat wanneer de server crasht, de clients geen toegang hebben tot de code.

Voordelen:

• systeem gebaseerd CVS
• Staat atomaire operaties toe
• Code-vertakkingsbewerkingen zijn goedkoper
• Breed scala aan IDE-plug-ins
• Maakt geen gebruik van een peer-to-peer-model

Gebreken:

• Fouten blijven bestaan gerelateerd aan het hernoemen van bestanden en mappen
• Onbevredigende reeks opdrachten voor het werken met de repository
• Relatief lage snelheid

git

Dit systeem is gemaakt om de ontwikkeling van de Linux-kernel te beheren en gebruikt een benadering die fundamenteel verschilt van CVS en SVN.

De basis git concepten werden vastgelegd om een ​​snellere gedistribueerdeversiebeheersysteem, in tegenstelling tot de regels en oplossingen die worden gebruikt in CVS . Omdat Git voornamelijk voor Linux is ontwikkeld, werkt het op dit besturingssysteem het snelst.

Git werkt ook op Unix-achtige systemen (zoals MacOS), en voor Windows-platforms wordt het mSysGit-pakket gebruikt.

De programmacode is mogelijk niet beschikbaar bij gebruik van een computer zonder repository. Er zijn oplossingen voor dit probleem, en sommige ontwikkelaars zijn van mening dat de snelheid van Git een redelijke prijs is voor het ongemak.

Daarnaast heeft Git veel tools om door de wijzigingsgeschiedenis te navigeren. Elke werkkopie van de broncode bevat de volledige ontwikkelingsgeschiedenis, wat erg handig is bij het programmeren zonder internetverbinding.

Voordelen:

• Perfect voor degenen die haten CVS/SVN
• Aanzienlijke prestatieverbetering
• Goedkope operaties met code branches
• Volledige ontwikkelingsgeschiedenis offline beschikbaar
• Gedistribueerd, peer-to-peer-model

Gebreken:

• Hoge instapdrempel (leer) voor degenen die eerder SVN . hebben gebruikt
• Beperkte ondersteuning voor Windows (vergeleken met Linux)

Mercurial

Mercurial werd uitgebracht op hetzelfde moment als Git. het is hetzelfde gedistribueerd versiebeheersysteem.

Mercurial is gemaakt als alternatief voor Git voor het ontwikkelen van Linux-kernelmodules. Maar sinds Git werd gekozen, wordt Mercurial minder gebruikt. Veel toonaangevende ontwikkelaars werken bijvoorbeeld met dit systeemopenoffice.org .

Het versiebeheersysteem van Mercurial is andersversiebeheersystemenomdat het meestal in Python is geschreven (niet in C). Sommige onderdelen zijn echter geïmplementeerd als uitbreidingsmodules in C.

Omdat het systeem gedecentraliseerd is en in Python is geschreven, neigen veel Python-programmeurs naar Mercurial.

Gebruikers merken op dat Mercurial enkele kenmerken van SVN behoudt terwijl het een gedistribueerd systeem is, en vanwege deze gelijkenis heeft het een lagere toetredingsdrempel voor degenen die al bekend zijn met SVN. Ook is de documentatie voor Mercurial completer, waardoor je sneller aan de verschillen kunt wennen.

Een van de grootste nadelen van Mercurial is dat het, in tegenstelling tot Git, geen twee bovenliggende branches kan samenvoegen, aangezien Mercurial een plug-insysteem gebruikt in plaats van scriptondersteuning. Dit is geweldig voor sommige programmeurs, maar velen willen de kracht van Git niet opgeven.

Voordelen:

• In vergelijking met Git is het gemakkelijker te leren
• Gedetailleerde documentatie
• gedistribueerd modelversiebeheersystemen

Gebreken:

• Geen optie om twee bovenliggende takken samen te voegen
• Plugins gebruiken, geen scripts
• Minder mogelijkheden voor niet-standaard oplossingen

Dieversiebeheersysteem past bij mij?

In de meeste gevallen gebruiken ontwikkelaars CVS omdat ze eraan gewend zijn. Als het team al aan een project werkt, dan is het vooruitzicht om alle ontwikkelingen over te dragen aan een andercontrole systeemergens niet inspirerend. Als ze het systeem toch moesten veranderen, dan zouden ze hoogstwaarschijnlijk overstappen op SVN.

CVS heeft de status van "volwassen technologie" al bereikt, wat betekent dat het niet langer radicaal nieuwe functies en oplossingen zal introduceren. Het momentum van gewoonte gaat verloren als mensen naar SVN verhuizen. Zo wordt CVS stilaan verleden tijd.

Vandaag heeft SVN de palm onder de serverversiebeheersystemen. Het omvat de voordelen CVS en overtreft ze. Als we het hebben over prevalentie, dan kom je ze waarschijnlijk vaker tegen CVS of SVN dan met Git of Mercurial. Dus het kennen van één servertechnologie, hoewel niet essentieel, zal de overgang voor u gemakkelijker maken.

Vanwege het brede gebruik en de volwassenheid van de technologie heeft SVN een grote kennisbank, waardoor het voor gebruikers gemakkelijk is om hulp te krijgen.

Git is duidelijk sneller dan zijn concurrenten. Voor projecten die zijn gemaakt onder gedistribueerdversiebeheersystemen, is dit een duidelijke verbetering.

Een belangrijk nadeel van Git is dat het soms moeilijk is om de nuances hiervan uit te leggencontrolesystemen, en dit vertraagt ​​de workflow terwijl programmeurs eraan wennen. Zodra de "toegangsdrempel" echter is overwonnen, neemt de productiviteit toe en zal het gemak van het beheren van codevertakkingen de bestede tijd volledig betalen.

Voor degenen die Git haten (en het heeft zijn tegenstanders in de ontwikkelaarsgemeenschap), Mercurial is een compromis tussen SVN en Git. Dit systeem wordt gebruikt in veel bekende projecten en heeft ook goede documentatie.

De Windows-compatibele versie van Git vordert ook in de richting van de snelheid van de Linux-versie, dus je kunt dit systeem nog steeds gebruiken, zelfs als je niet op Linux ontwikkelt.

Om te begrijpen welke het beste voor u is, moet u rekening houden met de specifieke kenmerken van het project en uw team. Praat met ontwikkelaars!

Als uw project een enkele bronstructuur vereist waar een kleine groep programmeurs aan zal werken, dan is SVN uw optie. Het is betrouwbaar en speciaal ontworpen voor dergelijke gevallen.

Als je een open-source project uitvoert waaraan door verschillende programmeurs op verschillende tijdstippen wordt gewerkt, of als je een constante update van de code verwacht, kies dan voor Git. Het snelheids- en bronboombeheer is hier veel beter dan in SVN.

Als je op een kruispunt staat of gewoon niet houdt van de manier waarop SVN of Git werkt, dan is Mercurial iets voor jou.

Al deze systemen zijn volledig functioneel. En ook gratis. Ze worden gebruikt om software, websites en zelfs besturingssystemen te maken die u gebruikt en kent.

Bepaal eerst of de een of de ander geschikt iscontrole systeemversies voor uw bedrijf, en zorg er dan - net zo belangrijk - voor dat deze keuze programmeurs niet irriteert.

Aan de slag met SVN

Als je nog nooit met SVN of Git hebt gewerkt en geen idee hebt hoe je moet beginnen, danhostingoplossing gecombineerd met GUIhelpen u snel aan de slag.

Zoals in de meeste gevallen, is het belangrijkste om te beginnen met werken, en dan zal het begrip komen. Het bedienen van een versiebeheersysteem lijkt sterk op het werken met bestanden op een server met behulp van een FTP-client.

NOTITIE:Er zijn veel hostingoplossingen voor:versiebeheersystemen, inclusief een gratis proefperiode. U kunt op basis hiervan gratis uw eerste repository (een plek om samen te werken aan codebestanden) maken. Hier zijn enkele van deze diensten:

SVN & GIT-hosting

De eerste repository maken

Nadat je een account hebt aangemaakt, moet je een repository aanmaken - voor elk platform afzonderlijk. Het ziet er meestal zo uit:

• Log in op uw account, klik op uw projecten.
• Projectcreatie:

• Voer in de regel "Een nieuw project maken" de naam van uw project in
• Klik op de knop "Project maken"

• SVN-verbinding:

• Selecteer na het aanmaken van het project het tabblad "Bronbeheer" (broncodeversies)
• Klik op de link "Bronbeheer inschakelen"
• Geef de repository een naam
• Klik op "Opslaan"

Grafische clients van SVN en GIT

Dus de repository is gemaakt. Nu is het nodig dat alles er eenvoudig en duidelijk in wordt weergegeven. Hiervoor heeft u een grafische interface nodig.

—handige software om mee te werkenversiebeheersystemenop Microsoft Windows en misschien wel de beste Apache Subversion-client die er is. TortoiseSVN is geïmplementeerd als een Windows shell-extensie, waardoor het gemakkelijk te integreren is in browser. Daarnaast is het een open source programma waarvoor 34 taalpakketten beschikbaar zijn.

SmartGit

- Git grafische client (Open Source gedistribueerd)versiebeheersysteem). Werkt op Windows, Mac OS X en Linux.Licentiekosten - $ 39

Repository "Afrekenen" ("Uitchecken")

Dus de klant is geselecteerd. Nu moet u een opslagplaats voor het besturingssysteem maken. Moet binnenkomenUw repository-URL, gebruikersnaam en wachtwoord.

De URL ziet er meestal als volgt uit:https://svn .hostnaam.com/svn/ > (je kunt https:// (SSL) gebruiken als je een betaald account hebt)

1. Navigeer naar de hoofdmap, klik op de knop "Uitchecken" en maak een werkmap voor de client. Nu kunt u er bestanden aan toevoegen.
2. Nadat u de projectbestanden hebt uitgepakt, kunt u ze in een lokale map op uw computer bewerken.

Nadat u wijzigingen in de bestanden heeft aangebracht, klikt u op de knop "Inchecken" op de werkbalk om ze op te slaan. U kunt wijzigingen bekijken en er opmerkingen aan toevoegen - dit is een redelijk goed idee, omdat u in de toekomst precies weet waar u aan hebt gewerkt, welke wijzigingen zijn aangebracht en andere projectdeelnemers op de hoogte houdt.

Uw klant moet ook op elk moment met revisies kunnen beginnen door het revisielogboek of de wijzigingsgeschiedenis te openen - daarna kunt u, indien nodig, voor elk bestand afzonderlijk "terugdraaien" naar de vorige versie. Nu u bekend bent met de basisconcepten, is de documentatie

Gedistribueerd versiebeheersysteem Git. Deel 1

Invoering

Inhoud serie:

1. Inleiding

Tijdens het werken aan een project hebben de deelnemers vaak te maken met synchronisatie- en bestandsgeschiedenisproblemen, die met versiebeheersystemen (VCS) kunnen worden opgelost. Het doel van deze serie artikelen is om de lezer kennis te laten maken met de principes van het werk van de VCS en om een ​​ervan in detail te beschouwen, namelijk Git. Waarom Git? Dit systeem wint de laatste tijd aan populariteit en het belang ervan voor vrije software (en in het bijzonder voor het GNU/Linux-project) kan niet worden overschat.

We zullen achtereenvolgens, in algemene termen, de kenmerken van besturingssystemen analyseren, praten over hun architectuur en de belangrijkste kenmerken van de toepassing in kwestie. Daarnaast zullen we de momenteel bestaande interfaces voor het werken met Git bekijken.

De auteur laat bewust de terminologie van functies, toetsen en andere subtiliteiten weg om het beeld duidelijk, duidelijk en algemeen voor u te presenteren. Dit artikel gaat ervan uit dat de lezer bekend is met Unix-achtige besturingssystemen (OS) en een basiskennis heeft van algoritmiek en informatica in het algemeen.

In de volgende materialen zullen we ingaan op de structuur en filosofie van Git, de bijzonderheden van dit systeem en de subtiliteiten van het praktisch werken ermee. De cyclus wordt afgesloten met een artikel over de interactie van Git met andere VCS (zoals Subversion, CVS, Mercurial, etc.).

2. Git is...

Git is een versiebeheersysteem voor gedistribueerde bestanden. De programmacode is voornamelijk in C geschreven. Het project is in 2005 gemaakt door Linus Torvalds om de ontwikkeling van de Linux-kernel te beheren en is, net als GNU/Linux, vrije software, waarbij gebruik door derden onderhevig is aan de GNU GPL versie 2-licentie deze overeenkomst kan worden gekarakteriseerd als gratis codesoftware, die openlijk moet worden ontwikkeld, d.w.z. elke programmeur heeft het recht om het project in elk stadium te blijven verbeteren. Tijdens zijn korte bestaan ​​is dit systeem door veel vooraanstaande ontwikkelaars geïntroduceerd. Git wordt gebruikt in projecten die bekend zijn bij de Linux-gemeenschap, zoals Gnome, GNU Core Utilities, VLC, Cairo, Perl, Chromium, Wine.

3. Versiecontrolesystemen

Versiecontrolesystemen (Versiecontrolesystemen) zijn software die is ontworpen om het werk met de geschiedenis van een bestand (of een groep bestanden) te automatiseren, wijzigingen te bewaken, gegevens te synchroniseren en een veilige projectrepository te organiseren. Kortom, het belangrijkste doel van versiebeheersystemen is het gemakkelijker maken om met veranderende informatie te werken. Laten we de algemene kijk op ontwikkeling analyseren met een voorbeeld.

Stel er is een bepaald project dat je aan het ontwikkelen bent, meerdere afdelingen van programmeurs en je bent de coördinator (of leider). Met betrekking tot het besturingssysteem, of het nu een server is (als we het hebben over een gecentraliseerd systeem) of een lokale machine, elke projectontwikkelaar wordt alleen beperkt door toegangsrechten om versies van bestanden in deze repository te wijzigen en/of te lezen. U kunt de gegevens op elk moment terugdraaien naar de versie die u nodig hebt. U, als coördinator, kunt de toegang tot bepaalde gebruikers beperken om de bestandsversie bij te werken. Het biedt ook een interface voor het bewaken en zoeken naar bestandsversies. U kunt bijvoorbeeld een query maken: "Waar en wanneer is dit stukje code gewijzigd?".

Het systeem gaat uit van veilige gegevensopslag, d.w.z. elk blok dat erin is opgeslagen, heeft veel klonen. Dus als bijvoorbeeld een bestand beschadigd is, kunt u dit tijdig vervangen door een kopie. Om de hoeveelheid projectgegevens te verminderen, wordt vaak deltacompressie gebruikt - een type opslag waarin niet de versies van het bestand zelf worden opgeslagen, maar alleen verandert tussen opeenvolgende revisies.

4. Verschillen in gedistribueerde versiebeheersystemen

Gedistribueerde versiebeheersystemen zijn VCS, waarvan het belangrijkste paradigma de lokalisatie van de gegevens van elke projectontwikkelaar is. Met andere woorden, als in gecentraliseerde VMS alle acties op de een of andere manier afhankelijk zijn van het centrale object (server), dan behoudt in gedistribueerde VMS elke ontwikkelaar zijn eigen versietak van het hele project. Het gemak van zo'n systeem is dat elke ontwikkelaar de mogelijkheid heeft om zelfstandig te werken en van tijd tot tijd tussenversies van bestanden uit te wisselen met andere projectdeelnemers. Laten we deze functie eens bekijken en doorgaan met het vorige voorbeeld.

Elke ontwikkelaar op de machine heeft zijn eigen lokale repository - een plaats waar bestandsversies worden opgeslagen. Het werken met projectgegevens wordt geïmplementeerd op uw lokale repository, en hiervoor is het niet nodig om contact te houden met de rest (zelfs als de belangrijkste) van de ontwikkelingsafdelingen. Communicatie met andere repositories is alleen nodig bij het wijzigen/lezen van versies van bestanden uit andere branches. Tegelijkertijd bepaalt elke projectdeelnemer de rechten van zijn eigen opslag voor lezen en schrijven. Alle takken in de gedistribueerde VCS zijn dus gelijk aan elkaar en de belangrijkste wordt geselecteerd door de coördinator. Het enige verschil tussen de hoofdtak is dat ontwikkelaars er mentaal naar opkijken.

5. Belangrijkste kenmerken en kenmerken van Git

Het is de moeite waard om te zeggen dat het systeem, als het geen plons maakte, de SUV-gemeenschap een beetje opschudde met zijn nieuwigheid en een nieuw ontwikkelingspad bood. Git biedt flexibele en gebruiksvriendelijke tools voor het bijhouden van de projectgeschiedenis.

Een kenmerk van Git is dat het werken aan projectversies niet in chronologische volgorde mag plaatsvinden. Ontwikkeling kan worden uitgevoerd in verschillende parallelle takken, die op elk moment tijdens de ontwikkeling kunnen worden samengevoegd en gesplitst.

Git is een redelijk flexibel systeem en de reikwijdte ervan is niet beperkt tot alleen ontwikkeling. Journalisten, auteurs van technische literatuur, bestuurders, universiteitsprofessoren kunnen het bijvoorbeeld heel goed gebruiken in hun soort activiteiten. Deze taken omvatten versiebeheer van alle documentatie, rapporten, huiswerk.

Laten we de belangrijkste verschillen tussen Git en andere gedistribueerde en gecentraliseerde VMS benadrukken.

Git-architectuur

SHA1 (Secure Hash Algorithm 1) is een cryptografisch hash-algoritme. Elk bestand in je Git-project bestaat uit een naam en een inhoud. De naam is de eerste 20 bytes aan gegevens, het is duidelijk geschreven in veertig tekens in hexadecimaal. Deze sleutel wordt verkregen door de inhoud van het bestand te hashen. Dus door bijvoorbeeld twee namen te vergelijken, kunnen we met bijna 100% zekerheid zeggen dat ze dezelfde inhoud hebben. Ook zijn de namen van identieke objecten in verschillende branches (repositories) hetzelfde, waardoor u direct met gegevens kunt werken. Een goede aanvulling op het bovenstaande is dat je met de hash nauwkeurig de schade aan bestanden kunt bepalen. Door bijvoorbeeld de hash van de inhoud te vergelijken met de naam, kunnen we vrij nauwkeurig zeggen of de gegevens beschadigd zijn of niet. Verder zullen we bij naam de naam van het bestand begrijpen, en de tekenreeks zal de SHA1-hash worden genoemd.

Vermeldenswaard zijn de zogenaamde botsingen. "Het is vrij nauwkeurig om de schade te bepalen" betekent dat er dergelijke bestanden zijn, verschillend van inhoud, waarvan de SHA1-hash hetzelfde is. De kans op dergelijke botsingen is erg klein en volgens een voorlopige schatting is deze gelijk aan 2 tot de -80e macht (~ 10 tot de -25e macht). Er is geen exacte schatting, omdat de wereldgemeenschap op dit moment niet in staat is geweest om dit cryptografische schema effectief te decoderen.

Git-objecten

Het werken met bestandsversies in Git kan worden vergeleken met normale bestandssysteembewerkingen. De structuur bestaat uit vier typen objecten: Blob, Tree, Commit en References; sommige zijn op hun beurt onderverdeeld in subobjecten.

Blob (Binary Large Object) is een gegevenstype dat alleen de inhoud van een bestand en zijn eigen SHA1-hash bevat. Blob is het belangrijkste en enige opslagmedium in de Git-structuur. Het is mogelijk om een ​​parallel te trekken tussen dit object en inodes in bestandssystemen, aangezien hun structuur en doel erg op elkaar lijken.

Boom

• eigen SHA1-hash;
• SHA1 hash van blobs en/of bomen;
• toegangsrechten van Unix-systemen;
• symbolische naam van het object (naam voor intern gebruik in het systeem).

In de kern is een object analoog aan een directory. Het definieert de hiërarchie van projectbestanden.

Verbinden- een gegevenstype dat het volgende bevat:

• eigen SHA1-hash;
• link naar precies één boom;
• een link naar de vorige commit (er kunnen er meerdere zijn);
• de naam van de auteur en het tijdstip waarop de commit is gemaakt;
• de naam van de committer (commiter is de persoon die de commit op de repository heeft toegepast, deze kan verschillen van de auteur) en het tijdstip waarop de commit is toegepast;
• een willekeurig gegeven (een blok kan worden gebruikt voor een elektronische handtekening of bijvoorbeeld om wijzigingen in een commit uit te leggen).

Dit object is ontworpen om op een bepaald moment een snapshot (versie) van een groep bestanden op te slaan, je kunt het vergelijken met een checkpoint. Commits kunnen worden gecombineerd (samenvoegen), vertakt (branch) of bijvoorbeeld een lineaire structuur instellen, waardoor de hiërarchie van projectversies wordt weergegeven.

Referentie is een gegevenstype dat een verwijzing bevat naar een van de vier objecten (Blob, Tree, Commit en References). Het belangrijkste doel is om direct of indirect naar een object te verwijzen en een synoniem te zijn voor het bestand waarnaar het verwijst. Dit vergroot het inzicht in de projectstructuur. Het is erg onhandig om te werken met een betekenisloze set tekens in de naam, terwijl de link, in tegenstelling tot de SHA1-hash, een naam kan krijgen omdat dit handiger is voor de ontwikkelaar.

Links kunnen op hun beurt worden onderverdeeld in een aantal subobjecten die enkele verschillen hebben: Branch, Tag. Laten we ze eens bekijken.

Tak (Hoofd, Tak)– een symbolische link, die verwijst naar de laatste commit in de commit-geschiedenis van een bepaalde branch en de SHA1-hash van het object opslaat. Is het gegevenstype van gejournaliseerde bestandssystemen. Dit type object is niet gedefinieerd in Git zelf, maar wordt overgenomen van het besturingssysteem en het bestandssysteem. Een branch wordt gebruikt als synoniem voor het bestand waarnaar het verwijst, d.w.z. Met Git kun je er direct mee werken. U kunt het zich veroorloven niet na te denken of u met de nieuwste versie werkt of niet.

Label is een gegevenstype dat, in tegenstelling tot branches, altijd verwijst naar hetzelfde object van het type blob, tree, commit of tag. Het kan op zijn beurt worden onderverdeeld in lichtgewicht (licht label) en zwaar of geannoteerd (geannoteerd label). Het lichtlabel, behalve de onveranderlijkheid van de link, verschilt niet van gewone takken, d.w.z. bevat alleen de SHA1-hash van het object waarnaar het verwijst in zichzelf. Een geannoteerde tag bestaat uit twee delen:

• het eerste deel bevat zijn eigen SHA1-hash;
• het tweede deel bestaat uit:
  • SHA1 van het object waarnaar wordt verwezen door de geannoteerde tag;
  • het type van het opgegeven object (blob, tree, commit of tag);
  • de symbolische naam van de tag;
  • datum en tijd waarop de tag is gemaakt;
  • naam en e-mailadres van de maker van de tag;
  • een willekeurig gegeven (dit blok kan worden gebruikt voor een elektronische handtekening of voor het uitleggen van een tag).

Met andere woorden, een project in Git is een verzameling blobs die verbonden zijn door een netwerk van bomen. De resulterende hiërarchische structuur kan, afhankelijk van de tijd, worden weerspiegeld in de vorm van commits - versies, en om hun structuur te begrijpen, bevat Git objecten zoals links. Met uitzondering van acties met koppelingen wordt vrijwel al het werk met systeemobjecten zoveel mogelijk van binnenuit geautomatiseerd. Uitgaande van het mechanisme van koppelingen, komen we tot het volgende idee - werken aan groepen bestanden. Volgens de auteur is het idee de sleutel tot de filosofie van Git. Na bijvoorbeeld een operatie voor een bepaalde commit te hebben ingesteld, zal het recursief zijn deel uitwerken langs de boom waarnaar het verwijst. Als uitbreiding van de algemene "actie op elk bestand"-weergave, vereenvoudigt de innovatie de implementatie en aanpak door de programmeur van dagelijkse VCS-taken zoals het samenvoegen/splitsen van takken, waarbij het proces opnieuw recursief wordt geautomatiseerd. Deze aanpak is makkelijk te begrijpen, werkt snel en is flexibel in het behalen van haar doelen. Veel van deze functies worden bereikt door de Unix-georiënteerde aard van het systeem; in termen van standaard apparaten vertrouwt Git op de oplossingen die al beschikbaar zijn in het besturingssysteem.

Laten we het moment van gegevensopslag verduidelijken. Het bewaren van bestanden van verschillende versies in de geschiedenis neemt behoorlijk wat geheugen in beslag. Dus in een project van twintig bestanden van twintig versies zal het archief bijvoorbeeld 20 keer meer wegen (misschien in de orde van honderd megabytes), maar wat gebeurt er als het aantal van beide 10 keer meer is (schijnbaar niet veel )? De grootte van de bezette ruimte wordt 100 keer groter (d.w.z. ongeveer 1 GB). Bij echte problemen is de groeisnelheid van het bezette geheugen verre van lineair afhankelijk van de tijd. Er zijn verschillende optimalisaties om dit probleem op te lossen:

• elk Git-object wordt opgeslagen als een gewoon archief (tar.gz);
• sequentiële deltacompressie wordt toegepast op de volledige bestandshiërarchie.

Laten we een voorbeeld nemen.

Je hebt een driejarige geschiedenis van je project, het heeft ongeveer duizend bestanden en honderd versies. Als je op een gegeven moment terug moet naar de vroegste versie, zal Git de hele geschiedenis van het bestand moeten delta-comprimeren. Helaas kan dit proces tot 12.00 uur duren. Git stelt voor om zogenaamde breekpunten te doen, d.w.z. sla een wekelijks gearchiveerd bestand op na een bepaald aantal versies, wat we de compressiediepte zullen noemen. Dan, in ons voorbeeld, wordt de hele geschiedenis beperkt tot een vooraf bepaald aantal delta-compressies, uitpakken die je kunt bekijken in elke versie in de chronologie. Merk op dat deltacompressie het meest geschikt is om te gebruiken op sommige typen objecten die zich het dichtst in de hiërarchie bevinden, hiervoor moet de repository dienovereenkomstig worden gesorteerd op type en grootte. Deze reeks bewerkingen die in deze paragraaf worden beschreven, wordt uitgevoerd door de git-repack-functie (en git-gc, die deze bevat).

Vertakkingen samenvoegen en splitsen

Deze vraag is erg tijdrovend en verzadigd, en daarom zullen we de concepten van samenvoegen en scheiden alleen in algemene termen introduceren. Laten we het voorbeeld nog eens bekijken.

Stelt u zich het moment van projectontwikkeling voor, wanneer het belangrijkste doel de snelheid van het programma is. Een van de mogelijke tactische oplossingen is om de ontwikkelaars in twee groepen te splitsen, die elk hetzelfde probleem zullen oplossen. In dit geval moet de tak van de projectgeschiedenis worden gesplitst. Deze procedure wordt vertakking genoemd. De actie van het vertakken van een vertakking is gewoon om er een kopie van te maken, die later zijn eigen geschiedenis zal hebben.

Stel dat we twee reeds voltooide resultaten hebben ontvangen van dezelfde taak, waaraan is gewerkt door twee groepen programmeurs. Hoe kunnen we zijn? Kijk wiens code sneller en betrouwbaarder is? Het is te gemakkelijk, maar niet altijd de beste oplossing. Een goede oplossing is om de code en bestanden een beetje te begrijpen en ze op te splitsen in subtaken of codeblokken. En alleen dan om de sterke en zwakke punten van deze stukken te onthullen. Deze optie is natuurlijk alleen geschikt als je van tevoren hebt voorzien dat je later al deze deeltjes bij elkaar kunt verzamelen. Het geval dat u zelf de code ontwikkelt en enkele bugs verbetert en repareert, is gelijk aan het bovenstaande voorbeeld. Dit proces van het combineren van twee gehele getallen tot één wordt samenvoegen genoemd. Het proces van het samenvoegen van twee versies is het belangrijkste moment van projectmanagement. Hoe het ook zij, u moet de geautomatiseerde uitvoering van deze bewerking vermijden. Een onderscheidend kenmerk van Git is de meest betrouwbare en redelijk snelle manier om het probleem van vertakking op te lossen.

De voordelen van het systeem zijn onder meer:

1. Unix-georiënteerd.
2. Ideologische consistentie (volgens de regels voor het gebruik van het systeem is het erg moeilijk om in een hopeloze situatie te komen of iets te krijgen dat je niet had verwacht).
3. Hoge prestaties (dit is een van de meest voor de hand liggende voordelen van het systeem, waarvan de prijs "Ideologische consistentie" en "Unix-oriëntatie" is).
4. Git integratie met 3rd party VMS zoals Subversion, Mercurial, ...
5. Een groep bestanden beheren (het systeem hoeft wijzigingen in elk bestand niet afzonderlijk te beschouwen, het onthoudt alle wijzigingen in het hele project en als u plotseling enkele wijzigingen moet bijhouden, wordt precies het deel weergegeven dat aan dit bestand is gekoppeld ).
6. Samenvoegbewerking (de meest geautomatiseerde implementatie van een complexe taak).

De nadelen zijn onder meer:

1. Unix-centrisch (let op het ontbreken van een volwassen Git-implementatie op niet-Unix-systemen).
2. De noodzaak om periodiek het git-gc commando uit te voeren (pakt groepen bestanden in en verwijdert de niet-gekoppelde bestanden).
3. Hashing-botsingen (samenval van SHA1-hashes van verschillende bestanden).

6. Git-interfaces

"Hoeveel mensen, zoveel meningen." Laten we proberen een aantal interfacetypes te identificeren om met het systeem te werken. Voor bepaalde doeleinden is elk van de volgende soorten toepassingen op zijn eigen manier beter.

Voor mensen die niet veel aan ontwikkeling doen, voor "conservatieven" - degenen die van "knoppen en selectievakjes" houden en zichzelf bewust willen beschermen tegen de exorbitante inspanning van het onthouden van functies, toetsen en vele subtiliteiten, is de stijloptie TortoiseGit of Git Extensions meer geschikt - eenvoudige interfaces. Hiermee kunt u voornamelijk met de muis werken en werken in het vertrouwde Windows-besturingssysteem.

Precies het tegenovergestelde type interface. Voor programmeurs die voortdurend met werknemers moeten communiceren, om typische problemen van codecontrole op te lossen, voor mensen die gewend zijn om in Unix-achtige systemen te werken met behulp van een terminal, is het console-type applicaties het meest geschikt. Ze zijn net zo gemakkelijk te gebruiken, een beetje sneller en functioneler, maar ze zullen de tijd moeten nemen om erachter te komen hoe ze te gebruiken.

Er kan ook een derde type interfaces worden onderscheiden - een mengsel van de eerste twee. Die. je hebt een consoletoepassing, zoals een native git-shell. U kunt een aantal extra hulpprogramma's gebruiken, zoals Gitk of QGit, om bomen weer te geven, het gemakkelijker maken om de versiehiërarchie en verschillen tussen versies te zien en om de objecten te vinden die u nodig hebt.