Hej, Habr. Jag bestämde mig för att ta upp ett ämne som var slitet i många artiklar, mer specifikt - för att beskriva den i stort sett icke-standardiserade (jag skulle säga, osorterade) användningen av versionskontrollsystem (nedan - VCS). Kamrater programmerare, låt oss gömma de ruttna tomaterna och gå förbi, för den här artikeln är inte för dig. Ja, alla ni har redan lärt er alla krångligheterna med att arbeta med Git, SVN, CVS, och ni känner till många andra modeord. Låt oss, bara dödliga, bekanta dig med alla fördelarna med att använda SLE.
Jag bjuder in under snittet alla som vill bekanta sig med SLE, samt alla de som på ett eller annat sätt hanterar snabbt föränderliga data.

Varför behövs det

Jag är själv student vid ett tekniskt universitet och arbetar nästan ständigt med dokument (texter, bilder, ritningar) och ändrar dem tre (tio, hundra) gånger om dagen. Ibland visar det sig att de ändringar som gjorts under den senaste veckan måste avbrytas och återföras till dokumenten i tillståndet för en vecka sedan. Tja, om det inte fanns många redigeringar, i det här fallet kan femtio slag på Ctrl + Z hjälpa. Men om det under denna vecka pågick mer eller mindre aktivt arbete med dokumentet kommer det helt enkelt inte att vara möjligt att återställa statusen "innan en viktig ändring gjordes för en vecka sedan". Detta kräver en kopia av dokumentet vid tidpunkten "före en viktig revidering", samt ytterligare ett dussin kopior "före en annan viktig revidering", "före en tvivelaktig revidering" och "före en redigering som med största sannolikhet kommer att behöva avbrytas ”. I princip är detta tillvägagångssätt möjligt och praktiserat av många. Tills nyligen behöll jag själv viktiga versioner av filer och sparade dem med prefixet "date_time", och det verkade vara nöjd. Fördelen med denna metod är enkelheten, nackdelen är "svällningen" av arbetsmappar och besväret med användningen. Och om den första av dem kan hanteras på något sätt (stora hårddiskar och 7zip), måste något göras med besvär.

Vad kan man göra åt det, eller vad är SLE

Vi tar fram ett stycke från Wikipedia: "Versionskontrollsystem (från engelska Version Control System, VCS eller Revision Control System) - programvara för att underlätta arbetet med att ändra information. Versionskontrollsystemet låter dig lagra flera versioner av samma dokument, om nödvändigt, återgå till tidigare versioner, bestämma vem och när som gjorde den eller den ändringen och mycket mer." Det liknar själva Wikipedias funktionsprincip - alla versioner av artiklar med alla redigeringar är tillgängliga för studier.
Att använda VCS i en situation där du behöver lagra många versioner av filer är alltså vad du behöver. Fördelarna med detta tillvägagångssätt inkluderar enkel användning och besparingar gratis disk utrymme tack vare den så kallade deltakomprimeringen (när inte själva filerna sparas i olika versioner, utan ändras från version till version, vilket minskar mängden lagrad data). Låt oss försöka.

Vad är SLE

Samma Wikipedia föreslår att SLE är centraliserade och distribuerade, stora som små, med eller utan ringklockor och visselpipor. Vi är inte särskilt intresserade av detta, eftersom vi (åtminstone till en början) endast kommer att använda en del av SLE-funktionaliteten. Vi kommer att överväga just denna funktionalitet.
Nästan alla VCS är en sorts lagring som lagrar alla versioner av filerna vi arbetar med. Här är det nödvändigt att klargöra att versionen av de lagrade filerna oftast bestäms av användaren. Vi gjorde, säg, ett dussin mindre redigeringar och beslutade att det var dags att spara resultaten av våra aktiviteter i förvaret. En analogi kommer att tänka på med att regelbundet trycka på Ctrl + S, med den enda skillnaden att den här versionen av filen kan nås i framtiden. Naturligtvis, i ett slag på detta sätt, kan du lägga till versioner av ett godtyckligt stort antal filer till förvaret. Denna åtgärd kallas "commit", eller "commiting changes" på ett enkelt sätt.
När som helst kan du lägga till en ny eller ta bort en befintlig fil till förvaret (så här heter förvaret skickligt), och VCS kommer att "komma ihåg" när och vad vi lade till / tog bort. Och tack vare kommentarerna i commit's, kan du också beskriva varför denna commit faktiskt utförs ("lägg till en kula där" / "tog bort den eventuellt nödvändiga biten därifrån").
När vi äntligen förstår att det är dags för oss att återgå till versionen för en vecka sedan, har vi hela historien av förändringar. Och här kan vi välja vad vi ska göra. Om du behöver kopiera den önskade biten från den gamla filen och klistra in den i den aktuella versionen, extraherar vi helt enkelt den gamla filen från lagringen och kopierar den nödvändiga från den. Om du behöver rulla tillbaka helt och fortsätta arbeta med den gamla versionen kommer SLE till vår hjälp igen - du kan återgå till den tidigare versionen och skapa en så kallad ny gren ("branch"), samtidigt som du behåller allt som vi "övergav" genom att återgå till versioner för en vecka sedan. Således kan versionshistoriken för ett projekt representeras grafiskt som ett träd - från "rötter" (projektets början) till "grenar" (lyckade och misslyckade redigeringar). Dessutom kan en "gren" skapas på konstgjord väg, till exempel i det fall vi bestämmer oss för att utveckla två olika versioner från samma källfiler - i den första arbetar vi med några grannlåtar, i den andra - på andra. Dessutom, om arbetsfilerna är textdokument(och i vissa andra) är det möjligt att slå samman olika grenar till en - den så kallade sammanfogningen ("merge"). Låt oss nu föreställa oss att flera personer arbetar med ett projekt, och var och en är engagerad i sin egen "bauble". Att ha ett gemensamt arkiv i det här fallet förenklar utvecklingen avsevärt.

Från teori till praktik, eller börja använda SLE

Så jag hoppas att jag har övertygat dig om att det är bra att använda SLE. Det återstår bara att lära sig hur man använder SLE. Detta är vad vi kommer att göra.
Det finns olika versionskontrollsystem, som skiljer sig från varandra i olika aspekter av deras användning. Eftersom vi inte är intresserade (åtminstone till en början) av arbetets finesser olika system, kommer vi att fokusera på de enklaste och vänligaste av dem. Enligt min ödmjuka åsikt är ett sådant system, konstigt nog, Mercurial - "ett plattformsoberoende distribuerat versionskontrollsystem designat för att fungera effektivt med mycket stora kodlager" med det grafiska skalet TortoiseHg. Systemet kan användas under Windows, Linux och Mac OS X.
Jag kommer genast att göra en reservation för att jag ska beskriva hur man arbetar med systemet i Windows. För dem som behärskar Linux kommer det inte att vara svårt att studera allt analogt.
Dessutom ska vi parallellt lära oss att arbeta med gratis hosting Mercurial repositories - bitbucket.org, nödvändigt om du inte arbetar med ett projekt ensam eller, vilket är mycket bekvämt, du vill ha tillgång till alla versioner av projektet över Internet. I grund och botten är det en praktisk Dropbox-ersättning om du har använt den tidigare.
Installera först Mercurial + TortoiseHg från tortoisehg.bitbucket.org.
Detta system fungerar i konsolen, så för enkelhetens skull kommer vi senare att skriva flera *.bat-filer för typiska operationer.
Alla operationer utförs av kommandot hg. Kallas utan parametrar och listar huvudkommandona.
Alla kataloger vi väljer (jag kommer att använda mappen "C: \ project \") fungerar som ett arkiv, där alla filer i vårt framtida projekt ska lagras. Naturligtvis är det ingen som förbjuder att ha flera förråd på en dator.
För att få systemet att "förstå" att vi vill skapa ett arkiv kör vi kommandot:
hg init c: \ projekt
varefter mappen "c: \ project \" skapas, om den inte skapades tidigare, och mappen "c: \ project \ .hg \", där Mercurial kommer att lagra all tjänstinformation.
Omedelbart kommer vi ihåg att vi inte bara vill ha ett lokalt arkiv på vår dator, utan också ett fjärrarkiv till vilket vi kommer att skicka alla våra ändringar (eller, som de smarta människorna säger, "push" ändringar till ett fjärrarkiv, från engelska "push"). För att göra detta, gå till bitbucket.org, registrera dig och skapa vårt första arkiv (Repositories - Skapa nytt arkiv). Ge arkivet ett namn (jag kallar det remote_project för tydlighetens skull) och klicka på Skapa arkiv.
Nu har vi två arkiv - ett lokalt som finns i mappen "c: \ project \" och ett fjärrbeläget på "bitbucket.org/ditt_kontonamn/remote_project/", där ditt_kontonamn anges vid registrering på bitbucket, remote_project är arkivet namn som valdes när det skapades.
För att kunna fortsätta utforska behöver vi lägga något i vårt lokala förvar. Skapa bara i den (i mitt fall - i mappen "c: \ project \") vilken fil som helst av ditt framtida projekt, eller kopiera ditt nuvarande projekt dit.
Nu, strängt taget, måste vi berätta för Mercurial: "vi lade till sådana och sådana filer och ett par nya mappar till projektmappen", för detta tillhandahålls kommandot "hg add". Ett annat tillvägagångssätt är dock bekvämare - vid nästa commit kommer vi att säga till Mercurial att plocka upp alla nyskapade filer från projektmappen och glömma bort de borttagna, detta är mycket enklare än att köra "hg add c: \ project \ new_document .doc” varje gång du skapar ett nytt dokument”.
Så låt oss gå ner till vårt första åtagande. Det exekveras av följande kommando:
hg commit –A –m “commit to commit”
Låt oss ta en titt på allt i ordning. Kommandot ska anges när vi är i förvaret (det vill säga vi måste först köra "cd c: \ project"). Alternativet -A krävs för att Mercurial ska kunna plocka upp nyskapade filer (se ovan), alternativet -m lägger till en kommentar till commit. Dessa kommentarer kommer att visas när du visar versioner (eller ändringar) i TortoiseHg och på projektsidan på bitbucket.org. Det är mycket viktigt att ge meningsfulla kommentarer så att du inte lider senare, komma ihåg när den eller den redigeringen gjordes.
Nu innehåller vårt arkiv den första versionen av vårt projekt. Alla ytterligare commits utförs på samma sätt efter att vi beslutat att det är dags att spara den aktuella versionen.
Den committerade commit kan skjutas in i fjärrförvaret med kommandot:
hg push https://bitbucket.org/ditt_kontonamn/remote_project
I det här fallet måste du också vara i mappen som motsvarar förvaret. Efter att ha angett kommandot kommer du att bli tillfrågad om namnet och lösenordet för vårt konto på bitbucket.org, för att inte ange dem med varje tryck, kan kommandot ersättas med följande:
hg push hg push https: // ditt_kontonamn: ditt_konto_lö[email protected]/ditt_kontonamn/fjärrprojekt
Eftersom vi kommer att hamra alla kommandon i en *.bat-fil, kommer lösenordet i det här fallet att lagras i klartext, vilket innebär en viss säkerhetsrisk, men för mig är det acceptabelt.
Så för enkelhetens skull skapar vi commit.bat, push.bat och commit & push.bat-filer i zonen för direkt räckvidd med följande innehåll:
[innehållet i filen commit.bat]
OM!% 1 ==! gå ut 1
cd C: \ projekt
hg commit -A -m "% *"
gå ut 0
: utgång1
echo "INGEN KOMMANDO-LINE ARG!"
: exit0
Denna fil, anropad med argument, kommer att commit projektet och lägga till argumenten till commit kommentaren. Exempel: vi kör "commit.bat my first commit" och får en commit med kommentaren "my first commit". I FAR är det bekvämt att använda kombinationen Ctrl + Enter för detta.
[innehållet i filen push.bat]
cd C: \ projekt
hg push https: // ditt_kontonamn: ditt_konto_lö[email protected]/ditt_kontonamn/remote_project
Den här filen skickas till fjärrarkivet.
[innehåll i commit & push.bat-fil]
OM!% 1 ==! gå ut 1
cd C: \ projekt
hg commit -A -m "% *"
gå ut 0
: utgång1
echo "INGEN KOMMANDO-LINE ARG!"
: exit0
ring ./push.bat
Den här filen, anropad med argument, kommer att utföra en sekventiell commit och push av projektet, inklusive argumenten i commit-kommentaren.
Dessutom, för små mellanliggande commits, rekommenderar jag att du skapar en commit_date_time.bat-fil:
[innehållet i filen commit_date_time.bat]
cd C: \ projekt
hg commit -A -m "% DATUM%% TID%"
Den här filen commit med aktuellt datum och tid som en kommentar, vilket ofta är bekvämt.
Alla bestämmer frekvensen av commits och pushar på individuell basis, beroende på intensiteten och komplexiteten i de redigeringar som görs. Även om det rekommenderas att vägledas av regeln "oftare är bättre".
Genom att högerklicka på filen/mappen i förvaret kan du starta Repository Explorer (TortoiseHg - Repository Explorer), som innehåller alla våra commits med kommentarer till dem. Det här fönstret visar trädstrukturen för vårt arkiv, härifrån kan du också göra commits, pushar, rollbacks till tidigare versioner (backouts) och andra operationer.
På bitbucket.org/your_account_name/remote_project finns en liknande uppsättning ändringsuppsättningar, och du kan ladda ner vilken version av projektet som helst i ett arkiv, vilket ibland är väldigt bekvämt.
Generellt sett anser jag att min första bekantskap med Mercurial är över. För mer information, vänligen kontakta: translated.by/you/mercurial-the-definitive-guide/into-ru/trans/

Vem är den här artikeln till för

Jag avslutar kanske med var jag ska börja - för vem är den här artikeln? Svaret är enkelt – för den som vill lära sig använda SLE. Jag lyckades "haka" flera designers, ingenjörer och till och med en skribent på SLE. Prova själv - genom att göra detta kan du avsevärt underlätta ditt arbete.

P. S. Flyttad till bloggen "Versionskontrollsystem".

Taggar:

• versionskontrollsystem
• kvicksilver
• bit hink

Lägg till taggar

Översikt över versionskontrollsystem

Versionskontrollsystem har blivit en integrerad del av livet för inte bara mjukvaruutvecklare, utan också alla människor som står inför problemet med att hantera intensivt föränderlig information och som vill göra livet enklare. Som en konsekvens har ett stort antal olika produkter dykt upp som erbjuder kraftfulla möjligheter och tillhandahåller omfattande versionskontrollverktyg. Den här artikeln kommer kortfattat att gå igenom de mest populära, deras fördelar och nackdelar.

Som jämförelse valdes de vanligaste versionskontrollsystemen: RCS, CVS, Subversion, Aegis, Monoton, Git, Bazaar, Arch, Perforce, Mercurial, TFS.

RCS är ett revisionskontrollsystem.
(www.gnu.org/software/rcs/rcs.html)

Låt oss börja vår recension med ett av de första versionskontrollsystemen - RCS (Revision Control System), utvecklat 1985. Det ersatte det då populära versionskontrollsystemet SCCS (Source Code Control System).

För tillfället ersätts RCS aktivt av det mer kraftfulla versionskontrollsystemet CVS, men det är fortfarande ganska populärt och är en del av GNU-projektet.

RCS låter dig arbeta endast med enskilda filer och skapar en historik över ändringar för varje. För textfiler sparas inte alla versioner av filen, utan endast den senaste versionen och eventuella ändringar som gjorts i den. RCS kan också spåra ändringar i binärer, men varje ändring lagras som en separat version av filen.

När en användare gör ändringar i en fil förblir filen låst för alla andra. De kan inte begära det från förvaret för redigering förrän den första användaren är klar och genomför ändringarna.

Låt oss överväga de viktigaste fördelarna och nackdelarna med RCS-versionskontrollsystemet.

Fördelar:

1. RCS är lätt att använda och väl lämpat för att bekanta sig med principerna för versionskontrollsystem.

2. Bra för att säkerhetskopiera enskilda filer som inte kräver frekventa ändringar av en grupp användare.

3. Bred distribuerad och förinstallerad i de flesta gratis operativsystem.

Brister:

1. Spårar endast ändringar av enskilda filer, vilket inte tillåter användning av den för versionskontroll stora projekt.

2. Tillåter inte att flera användare gör ändringar i samma fil samtidigt.

3. Dålig funktionalitet jämfört med moderna versionskontrollsystem.

Slutsatser:

RCS-versionskontrollsystemet tillhandahåller en för svag uppsättning verktyg för att hantera projekt under utveckling och är endast lämpligt för att bekanta sig med versionskontrollteknik eller för att hålla en liten historik över återställningar av enskilda filer.

CVS är ett system för samtidig versionskontroll.
(www.nongnu.org/cvs)

Concurrent Versions System är en logisk utveckling av revisionskontrollsystemet (RCS), som använder dess standarder och algoritmer för versionskontroll, men mycket mer funktionellt, och låter dig arbeta inte bara med enskilda filer utan också med hela projekt.

CVS är baserat på klient-server-teknik som kommunicerar över ett nätverk. Klienten och servern kan också placeras på samma maskin om det bara är en person som arbetar med projektet, eller om du vill behålla lokal versionskontroll.

CVS är organiserat enligt följande. Den senaste versionen och alla ändringar som görs lagras i serverförrådet. Klienter som ansluter till servern kontrollerar skillnaderna mellan den lokala versionen och den senaste versionen som är lagrad i förvaret, och, om det finns skillnader, ladda upp dem till deras lokala projekt. Vid behov löser de konflikter och gör nödvändiga ändringar i produkten som utvecklas. Efter det laddas alla ändringar upp till serverförrådet. CVS, om nödvändigt, låter dig återgå till önskad version av projektet som utvecklas och hantera flera projekt samtidigt.

Här är de viktigaste fördelarna och nackdelarna med det parallella versionskontrollsystemet.

Fördelar:

1. Flera kunder kan arbeta med samma projekt samtidigt.

2. Låter dig hantera inte en enda fil, utan hela projekt.

3. Har ett stort antal användarvänliga grafiska gränssnitt som kan tillfredsställa nästan alla, även den mest krävande smak.

4. Utbredd och levereras som standard med de flesta Linux-operativsystem.

5. När testfiler laddas från förvaret överförs endast ändringar, inte hela filen.

Brister:

1. När du flyttar eller byter namn på en fil eller katalog går alla ändringar som är associerade med denna fil eller katalog förlorade.

2. Svårigheter att upprätthålla flera parallella grenar av samma projekt.

3. Begränsat stöd för typsnitt.

4. För varje ändring av den binära filen sparas hela versionen av filen, inte bara ändringen.

5. Den modifierade filen överförs alltid helt från klienten till servern.

6. Resurskrävande operationer, eftersom de kräver frekventa anrop till förvaret, och de säkerhetskopierade kopiorna har viss redundans.

Slutsatser:

Trots att CVS är föråldrat och har allvarliga brister är det fortfarande ett av de mest populära versionskontrollsystemen och är utmärkt för att hantera små projekt som inte kräver att man skapar flera parallella versioner som behöver slås samman med jämna mellanrum. CVS kan rekommenderas som ett mellansteg för att bemästra arbetet med versionskontrollsystem, vilket leder till mer kraftfulla och moderna typer av sådana program.

Subversion versionskontrollsystem.
(www.subversion.tigris.org)

Subversion är ett centraliserat versionskontrollsystem skapat 2000 och baserat på klient-server-teknologi. Det har alla fördelar med CVS och löser dess huvudproblem (döpa om och flytta filer och kataloger, arbeta med binärer, etc.). Det hänvisas ofta till med namnet på klientsidan - SVN.

Att arbeta med Subversion är mycket likt att arbeta med CVS. Klienter kopierar ändringar från arkivet och slår samman dem i användarens lokala projekt. Om det uppstår konflikter lokala förändringar och ändringar sparas i förvaret, då löses sådana situationer manuellt. Sedan görs ändringar i det lokala projektet och resultatet sparas i arkivet.

När du arbetar med filer som inte tillåter sammanslagning av ändringar kan följande princip användas:

1. Filen laddas ner från förvaret och blockeras (det är förbjudet att ladda ner den från förvaret).

2. De nödvändiga ändringarna görs.

3. Filen laddas in i förvaret och avblockeras (andra klienter får ladda ner den från förvaret).

Till stor del på grund av prostata och likheter i hanteringen med CVS, men främst på grund av dess breda funktionalitet, konkurrerar Subversion framgångsrikt med CVS och ersätter det till och med framgångsrikt.

Men Subversion har också nackdelar. Låt oss ta en titt på dess styrkor och svagheter för jämförelse med andra versionskontrollsystem.

Fördelar:

1. Kommandosystem liknande CVS.

2. De flesta CVS-funktioner stöds.

3. Diverse grafiska gränssnitt och bekvämt arbete från konsolen.

4. Historiken för ändringar av filer och kataloger övervakas även efter att de har bytt namn och flyttat dem.

5. Hög effektivitet i arbetet med både text och binära filer.

6. Inbyggt stöd i många integrerade utvecklingsverktyg som KDevelop, Zend Studio och många andra.

7. Möjlighet att skapa spegelkopior av förvaret.

8. Två typer av arkiv - en databas eller en uppsättning vanliga filer.

9. Möjlighet att komma åt förvaret via Apache med hjälp av WebDAV-protokollet.

10. Tillgång till en bekväm mekanism för att skapa taggar och projektgrenar.

11. Det är möjligt att associera en specifik uppsättning egenskaper till varje fil och katalog för att underlätta interaktion med versionskontrollsystemet.

12. Utbredd spridning gör det möjligt att snabbt lösa de flesta av de problem som uppstår genom att hänvisa till data som samlats på Internet.

Brister:

1. En fullständig kopia av förvaret lagras på den lokala datorn i dolda filer, vilket kräver en stor mängd minne.

2. Det finns problem med att byta namn på filer om en lokalt omdöpt fil av en klient samtidigt ändrades av en annan klient och laddades upp till arkivet.

3. Driften av sammanslagna projektgrenar får dåligt stöd.

4. Svårigheter med att fullständigt ta bort information om filer som har kommit in i arkivet, eftersom det alltid innehåller information om tidigare ändringar av filen, och ingen personalresurser för att helt ta bort data om en fil från förvaret.

Slutsatser:

Subversion är ett modernt versionskontrollsystem med ett brett utbud av verktyg för att tillgodose alla behov av versionskontroll av ett projekt med hjälp av ett centraliserat kontrollsystem. Det finns många resurser på Internet som ägnas åt Subversions egenheter, vilket gör att du snabbt och effektivt kan lösa alla problem som uppstår under arbetets gång.

Enkel installation, installation och stora möjligheter gör subversion till en av de ledande positionerna i den konkurrensutsatta kapplöpningen av versionskontrollsystem.

Versionskontrollsystem Aegis.

Aegis, skapad av Peter Miller 1991, är det första alternativet till centraliserade versionskontrollsystem. Alla operationer i den utförs genom Unix-filsystemet. Tyvärr har Aegis inte inbyggt stöd för nätverk, men interaktioner kan utföras med protokoll som NFS, HTTP, FTP.

Huvudfunktionen hos Aegis är sättet att kontrollera ändringarna som görs i förvaret.

Först, innan de gör några ändringar, måste de klara en serie tester. Och om innovationer i programmets källkod inte klarar testerna, måste antingen nya test läggas till eller korrigeras möjliga misstag i källkoden.

För det andra, innan ändringar görs i huvudgrenen av ett utvecklingsprojekt måste de godkännas av webbläsaren.

För det tredje tillhandahålls en hierarki för åtkomst till förvaret, baserad på systemet med åtkomsträttigheter för Unix-liknande operativsystem till filer.

Allt detta gör användningen av Aegis versionskontrollsystem tillförlitlig, men extremt svår, och även den välutvecklade dokumentationen gör det inte mycket lättare.

Låt oss lyfta fram de viktigaste fördelarna och nackdelarna med Aegis versionskontrollsystem.

Fördelar:

1. Pålitlig kontroll av korrektheten av de laddade ändringarna.

2. Möjligheten att ge olika nivåer av åtkomst till filerna i förvaret, vilket ger en anständig säkerhetsnivå.

3. Högkvalitativ dokumentation.

4. Möjlighet att byta namn på filer som sparats i arkivet utan att förlora historiken över ändringar.

5. Förmåga att arbeta med ett lokalt förvar, om det saknas nätverkstillgång till huvudförvaret.

Brister:

1. Brist på inbyggt stöd för nätverk.

2. Komplexiteten i att installera och arbeta med förvaret.

3. Svaga grafiska gränssnitt.

Slutsatser:

Aegis komplexitet kan avskräcka användare från att använda versionskontrollsystem, så det kan inte rekommenderas för granskning eller små programvaruprojekt. Det har dock ett antal fördelar som kan vara användbara i vissa specifika situationer, särskilt när det krävs noggrann kontroll över kvaliteten på programvaran som utvecklas.

Versionskontrollsystem Monotone.
(monotone.ca)

Monotone är ett annat decentraliserat versionskontrollsystem utvecklat av Graydon Hoem. I den är varje kund själv ansvarig för att synkronisera versionerna av den utvecklade produkten med andra kunder.

Att arbeta med detta versionskontrollsystem är ganska enkelt, och många av kommandona liknar de som används i Subversion och CVS. Skillnaderna ligger främst i organisationen av att slå samman projektgrenar av olika utvecklare.

Att arbeta med Monotone är strukturerat enligt följande. Först skapas en SQLite-projektdatabas och nycklar genereras med hjälp av Secure Hash Algorithm 1 (SHA1) hashalgoritm.

Sedan, när användaren korrigerar projektet, sparas alla ändringar i denna databas, på samma sätt som att spara ändringar i arkivet för andra versionskontrollsystem.

För att synkronisera ett projekt med andra användare måste du:

Exportera nyckeln (hash - kod för den senaste versionen av projektet) och få liknande nycklar från andra klienter.

Nu kan alla registrerade på detta sätt synkronisera utvecklingen med sina kollegor med hjälp av en enkel uppsättning kommandon.

Låt oss sammanfatta fördelarna och nackdelarna med Monotone versionskontrollsystem.

Fördelar:

1. En enkel och okomplicerad uppsättning kommandon, liknande kommandona Subversion och CVS.

2. Stöder byta namn och flytta filer och kataloger.

3. Högkvalitativ dokumentation som i hög grad underlättar användningen av versionskontrollsystemet.

Brister:

1. Låg arbetshastighet.

2. Brist på kraftfulla grafiska skal.

3. Möjliga (men extremt låga) hash-kodmatchningar av olika versioner.

Slutsatser:

Monotone är ett kraftfullt och lättanvänt versionskontrollverktyg för ditt projekt. Uppsättningen av kommandon är genomtänkt och intuitiv, särskilt den kommer att vara bekväm för användare som är vana vid att arbeta med Subversion och CVS. Perfekt designad och komplett dokumentation gör att du snabbt kan lära dig och använda alla funktioner i Subversion till fullo.

Den relativt låga arbetshastigheten och avsaknaden av kraftfulla grafiska skal kan dock göra det svårt att arbeta med stora projekt. Därför, om du behöver ett versionskontrollsystem för att stödja komplexa och voluminösa produkter, bör du överväga att använda Git eller Mercurial.

Versionskontrollsystem Git.
(www.git-scm.com)

Sedan februari 2002 för utveckling Linux-kärnor Och majoriteten av programmerare började använda BitKeeper versionskontrollsystem. Under ganska lång tid var det inga problem med henne, men 2005 återkallade Larry McVoy (utvecklaren av BitKeeper) gratis version program.

Att utveckla ett projekt i Linux-skala utan ett kraftfullt och pålitligt versionskontrollsystem är omöjligt. En av kandidaterna och det mest lämpliga projektet var versionskontrollsystemet Monotine, men Torvalds Linus var inte nöjd med dess snabbhet. Eftersom Monatone-organisationens egenheter inte tillät att avsevärt öka hastigheten på databehandlingen, började Linus den 3 april 2005 utveckla sitt eget versionskontrollsystem - Git.

Nästan samtidigt med Linus (tre dagar senare), till utveckling nytt system Versionskontroll startades också av Matt Makal. Matt kallade sitt projekt Mercurial, men mer om det senare, men låt oss nu återgå till Gits distribuerade versionskontrollsystem.

Git är ett flexibelt, distribuerat (utan en enda server) versionskontrollsystem som ger många möjligheter, inte bara för mjukvaruutvecklare, utan också för skribenter att ändra, komplettera och spåra ändringar i "manuskript" och storylines, och lärare att justera och utveckla en kurs med föreläsningar och administratörer för underhåll av dokumentation och för många andra områden som kräver hantering av förändringshistorik.

Varje utvecklare som använder Git har sitt eget lokala arkiv, vilket möjliggör lokal versionshantering. Sedan kan data som sparats i det lokala arkivet utbytas med andra användare.

När de arbetar med Git skapar de ofta ett centralt arkiv som andra utvecklare synkroniserar med. Ett exempel på att organisera ett system med ett centralt arkiv är Linux-kärnutvecklingsprojektet (http://www.kernel.org).

I det här fallet genomför alla projektdeltagare sin lokala utveckling och laddar fritt ned uppdateringar från det centrala arkivet. När det nödvändiga arbetet är slutfört och felsökt av enskilda projektdeltagare, laddar de, efter att ha bekräftat riktigheten och relevansen av det arbete som utförts av ägaren av det centrala förvaret, sina ändringar till det centrala förvaret.

Att ha ett lokalt arkiv förbättrar också avsevärt tillförlitligheten för datalagring, eftersom om ett av arkiven misslyckas kan data enkelt återställas från andra arkiv.

Arbete med versioner av ett projekt i Git kan utföras i flera grenar, som sedan enkelt kan slås samman, helt eller delvis, förstöras, rullas tillbaka och utökas till fler och fler grenar av projektet.

Vi kan diskutera Gits möjligheter länge, men för korthetens skull och enklare uppfattning är här de viktigaste fördelarna och nackdelarna med detta versionskontrollsystem.

Fördelar:

1. Pålitlig revisionsjämförelse och datavalidering baserad på SHA1 (Secure Hash Algorithm 1) hashalgoritm.

2. Flexibelt system för att förgrena projekt och slå samman filialer sinsemellan.

3. Närvaron av ett lokalt arkiv som innehåller fullständig information om alla ändringar tillåter fullständig lokal versionskontroll och uppladdning av endast fullständigt verifierade ändringar till huvudförvaret.

4. Hög produktivitet och arbetshastighet.

5. Bekväm och intuitiv kommandouppsättning.

6. Massor av grafiska skal som gör att du snabbt och effektivt kan arbeta med Git.

7. Möjlighet att göra checkpoints, där data sparas utan deltakomprimering, men helt. Detta gör att du kan minska hastigheten för dataåterställning, eftersom den närmaste kontrollpunkten tas som grund och återställningen fortsätter från den. Om kontrollpunkter saknades kan det ta timmar att återställa stora projekt.

8. Utbredd tillgänglighet, enkel tillgänglighet och kvalitetsdokumentation.

9. Systemets flexibilitet tillåter dig att bekvämt konfigurera det och till och med skapa specialiserade systemkontroller eller användargränssnitt baserat på git.

10. Universell nätverksåtkomst med hjälp av protokollen http, ftp, rsync, ssh, etc.

Brister:

1. Unix - orientering. Det finns för närvarande ingen mogen Git-implementation som är kompatibel med andra operativsystem.

2. Möjliga (men extremt låga) hash-kodmatchningar av olika versioner.

3. Ändringar i enskilda filer spåras inte, utan endast för hela projektet, vilket kan vara obekvämt när man arbetar med stora projekt som innehåller många frånkopplade filer.

4. Vid den första (första) skapandet av förvaret och synkronisering av det med andra utvecklare, kommer det att ta lång tid att ladda ner data, särskilt om projektet är stort, eftersom du behöver kopiera hela förvaret till den lokala datorn.

Slutsatser:

Git är ett flexibelt, bekvämt och kraftfullt versionskontrollsystem som kan tillfredsställa de allra flesta användare. De befintliga bristerna avlägsnas gradvis och medför inga allvarliga problem för användarna. Om du driver ett stort projekt som är geografiskt avlägset, och ännu mer om du ofta måste utveckla mjukvara utan att ha tillgång till andra utvecklare (du vill till exempel inte slösa tid när du flyger från land till land eller när du reser till arbete), kan du göra alla ändringar och spara dem i det lokala arkivet, återställa, växla mellan grenar, etc.). Git är en av de ledande inom versionskontrollsystem.

Versionskontrollsystem Mercurial.
(mercurial.selenic.com)

Det distribuerade versionskontrollsystemet Mercurial utvecklades av Matt Macal parallellt med Git versionskontrollsystemet skapat av Torvalds Linus.

Inledningsvis skapades den för effektiv hantering av stora projekt under Linux, och var därför fokuserad på snabbt och pålitligt arbete med stora arkiv. För tillfället är mercurial anpassat för att fungera under Windows, Mac OS X och de flesta Unix-system.

Det mesta av versionskontrollsystemet är inskrivet Python språk, och endast vissa delar av programmet som kräver bäst prestanda skrivs i C.

Revisioner identifieras baserat på SHA1 (Secure Hash Algorithm 1) hashalgoritm, men det är också möjligt att tilldela individuella revisionsnummer.

Precis som i git stöder den möjligheten att skapa projektgrenar och sedan slå samman dem.

För kommunikation mellan klienter används protokollen HTTP, HTTPS eller SSH.

Kommandouppsättningen är enkel och intuitiv, ungefär som subversion-kommandona. Det finns också ett antal grafiska skal och tillgång till förvaret via webbgränssnittet. Viktigt är också tillgången på verktyg som låter dig importera arkiv för många andra versionskontrollsystem.

Låt oss titta på de viktigaste fördelarna och nackdelarna med Mercurial.

Fördelar:

1. Snabb databehandling.

2. Stöd över plattformar.

3. Förmåga att arbeta med flera grenar av projektet.

4. Lätt att använda.

5. Möjlighet att konvertera arkiv för andra versionssystem som CVS, Subversion, Git, Darcs, GNU Arch, Bazaar, etc.

Brister:

1. Möjliga (men extremt låga) hash-kodmatchningar av olika versioner.

2. Konsolorienterad.

Slutsatser:

Ett enkelt och polerat gränssnitt, en uppsättning kommandon, möjligheten att importera arkiv från andra versionskontrollsystem - kommer att göra övergången till Mercurial och lära sig de grundläggande funktionerna smärtfri och snabb. Det är osannolikt att det tar mer än några dagar.

Tillförlitlighet och arbetshastighet gör det möjligt att använda den för versionskontroll av stora projekt. Allt detta gör Mercurial till en värdig konkurrent till git.

Versionskontrollsystem Bazaar.
(bazaar.canonical.com)

Bazaar är ett distribuerat, gratis versionskontrollsystem utvecklat med stöd av Canonical Ltd. Den är skriven i Python och körs på Linux, Mac OS X och Windows operativsystem.

Till skillnad från Git och Mercurial, som är byggda för att styra operativsystemets kärnversioner Linux-system, och därför fokuserade på maximal prestanda när man arbetade med ett stort antal filer, fokuserade Bazaar på ett bekvämt och vänligt användargränssnitt. Optimering av arbetshastigheten utfördes redan i det andra steget, när de första versionerna av programmet redan hade dykt upp.

Liksom många andra versionskontrollsystem är Bazaars kommandosystem väldigt likt CVS- eller Subversion-kommandon, vilket dock inte är förvånande, eftersom det ger ett bekvämt, enkelt och intuitivt gränssnitt för att interagera med programmet.

Det är trevligt att stor uppmärksamhet ägnas åt att arbeta med projektgrenar (skapa, slå samman grenar, etc.), vilket är mycket viktigt när man utvecklar seriösa projekt och låter dig utföra förbättringar och experiment utan hot om att förlora huvudversionen av programvaran .

Ett stort plus med detta versionskontrollsystem är förmågan att arbeta med arkiv för andra versionskontrollsystem, som Subversion eller Git.

Låt oss sammanfatta de viktigaste fördelarna och nackdelarna med detta versionskontrollsystem.

Fördelar:

1. Stöd över plattformar.

2. Bekvämt och intuitivt gränssnitt.

3. Enkelt arbete med grenar av projektet.

4. Förmåga att arbeta med repositories av andra versionskontrollsystem.

5. Bra dokumentation.

6. Bekvämt grafiskt gränssnitt.

7. Extrem flexibilitet för att anpassa sig till en viss användares behov.

Brister:

1. Långsammare prestanda jämfört med git och mercurial, men denna situation korrigeras gradvis.

2. För fullfjädrad funktion är det nödvändigt att installera ett tillräckligt stort antal plug-ins för att helt avslöja alla funktioner i versionskontrollsystemet.

Slutsatser:

Bazaar är ett användarvänligt versionskontrollsystem med ett snyggt gränssnitt. Bra för användare som är avskräckta vid möjligheten att använda kommandoraden. Många ytterligare alternativ och tillägg gör att du kan anpassa programmet så att det passar dina behov. Likheten mellan kommandosystemet och Git och Subversion, och förmågan att arbeta direkt med deras arkiv, kommer att göra övergången till Bazaar snabb och smärtfri. Framgången för basaren bevisas också av det faktum att Ubuntu Linux-utvecklare använder den.

Versionskontrollsystem Arch.

Arch är ett distribuerat versionskontrollsystem skapat av Tom Lord. Det skapades ursprungligen för att lösa CVS-problem, vilket de gjorde ganska bra.

Arch utför atomoperationer för att spara ändringar i förvaret, d.v.s. eliminerar situationen med nedladdning av arkivet, när några av ändringarna har laddats ner och några ännu inte har hunnit ladda ner.

Stöder möjligheten att förgrena projektversioner och slå samman separata grenar, byta namn på och flytta filer och kataloger samtidigt som förändringshistoriken bibehålls och många andra trevliga funktioner.

Kräver ingen speciell tjänst för nätverksförrådet och kan använda protokoll som FTP, SFTP eller WebDAV och så vidare.

Men tyvärr är det bara UNIX-system som stöds, men det borde inte vara svårt att överföra Arch till andra operativsystem.

Det är svårt att notera några i grunden bättre egenskaper i jämförelse med andra. distribuerade system versionskontroll som git, mercurial, bazaar, så om det finns ett val är det bättre att använda något mer kraftfullt och utbrett.

Versionskontrollsystem Perforce.
(www.perforce.com)

Låt oss fortsätta vår granskning av versionskontrollsystem och gå vidare till kommersiella program. Låt oss börja med det centraliserade versionskontrollsystemet, Perforce, utvecklat av Perforce Software.

Perforce-systemet har en klient-server-organisation och låter dig hantera flera projekt samtidigt och skapa ett eget arkiv för varje projekt.

Perforce är ett plattformsoberoende system. Det finns versioner som kan köras under Unix, Mac OS X, Microsoft Windows operativsystem.

För att arbeta med versionskontrollsystemet kan du använda både konsolen och ett specialdesignat grafiskt gränssnitt.

Perforces betydande fördel är förmågan att integrera med många mjukvaruutvecklingsverktyg och applikationer som Autodesk 3D Studio Max, Maya, Adobe Photoshop, Microsoft Office, Eclipse, emacs och många andra.

Stöd för möjligheten att skapa grenar av projektversioner, flexibelt hantera dem, slå samman, rulla tillbaka till tidigare revisioner - gör Perforce till ett ganska konkurrenskraftigt system och bidrar till dess breda distribution. Denna produkt är dock kommersiell, vilket begränsar tillämpningsområdet något och begränsar distributionen. Det används främst i stora kommersiella företag där inte bara funktionalitet är viktigt, utan också teknisk support i rätt tid.

Versionskontrollsystem Team Foundation Server.
(msdn.microsoft.com/en-us/library/ms364061.aspx)

I själva verket kan Team Foundation Server (TFC) inte bara kallas ett versionskontrollsystem - det är en sorts heltäckande lösning som inkluderar ett versionskontrollsystem, ett datainsamlingssystem och rapportering och andra användbara funktioner.

Ett hanterat projekt, när du arbetar med TFC, representerar projektkällgrenar, rapportuppsättningar och anpassade objekt. När du skapar ett projekt väljs dess parametrar i förväg, som du antingen kan välja själv eller använda mallar. Mallar låter dig bestämma vägen för projektutveckling, göra den flexibel eller styvt formaliserad, fastställa en utvecklingsstrategi, ta hänsyn till nödvändiga tomma dokument och rapporter.

TFC integreras enkelt med Microsoft Excel och Microsoft Project, vilket gör det mycket lättare att skapa och spåra kontrollerade projektobjekt.

Som ett versionskontrollsystem låter TFC dig:

Korrigera gemensamt projektfiler;

Lös konflikter;

Skapa grenar av projekt och slå sedan samman dem;

Styr åtkomst till förvaret;

Gå tillbaka till tidigare versioner;

Skapa uppskjutna ändringar - ändringar som inte läggs till direkt i arkivet, men andra användare kan se dem, och du kan ladda ner dessa ändringar endast efter att ha erhållit särskild tillstånd från ägaren av ändringarna;

Markera enskilda versioner av filer i arkivet och gruppera dem;

För att spara data och arkiv för utvecklade projekt används SQL Server 2005-databaser.

TFC är ett kraftfullt och bekvämt verktyg som låter dig inte bara hantera källkodsversioner, utan också att helt organisera hela utvecklingscykeln för ett projekt från att skriva program till att dokumentera dem. Detta kraftfulla och komplexa system är dock mer lämpligt för stora projekt som kräver komplex och detaljerad utvecklingsledning. Om du har en liten utveckling är det vettigt att använda ett mindre kraftfullt verktyg, eller ännu bättre gratis distribution, eftersom detta kommer att spara tid, pengar och nerver.

Generalisering.

Ett brett utbud av versionskontrollsystem låter dig uppfylla alla krav och organisera arbetet som du behöver det. Men bland alla olika system finns det tydliga ledare. Så om du behöver hantera ett enormt projekt som består av tiotusentals filer och tusentals människor arbetar med, då är det bästa valet att välja Git eller Mercurial. Om det viktigaste för dig är ett användarvänligt gränssnitt och projektet som utvecklas inte är särskilt stort, är Bazaar-systemet att föredra för dig.

För soloprogrammerare eller små projekt som inte behöver förgrena sig och bygga flera versioner är Subversion bäst.

Men i slutändan är valet en smaksak, eftersom det nu finns många versionskontrollsystem som ger dig allt du behöver. Så välj ditt val och du kommer inte ångra det. Versionskontrollsystem är absolut nödvändig programvara för alla utvecklare och andra.

Ofta arbetar utvecklare i ett team på ett projekt, vilket innebär att flera personer samtidigt kan modifiera en fil samtidigt. För att undvika förvirring i sådana fall används ett versionskontrollsystem som låter dig lagra historiken för projektändringar och vid behov hjälper dig att återgå till en tidigare version.

Versionering

För att bättre förstå versionsproblemet, överväg ett exempel på en designer som har avslutat arbetet med ett projekt och skickat den slutliga versionen till en kund. Designern har en mapp där den slutliga versionen av projektet lagras:

Källa / barbershop_index_final.psd

Allt är bra, designern avslutade arbetet, men kunden skickade tillbaka redigeringarna. För att kunna återgå till den gamla versionen av projektet skapade designern en ny fil barbershop_index_final_2.psd, gjorde ändringar och skickade till kunden:

Källa / barbershop_index_final.psd barbershop_index_final_2.psd

Detta var inte allt, som ett resultat växte projektstrukturen och började se ut så här:

Källa / barbershop_index_final.psd barbershop_index_final_2.psd… barbershop_index_final_19.psd… barbershop_index_latest_final.psd barbershop_index_latest_final_Final.psd

Förmodligen har många redan stött på detta, till exempel när de skrev terminsuppsatser under studietiden. Inom professionell utveckling är det dålig praxis att använda nya filer för versionshantering. Vanligtvis har utvecklare många filer i sin projektmapp. Dessutom kan flera personer arbeta med ett projekt. Om varje utvecklare för versionering skapar en ny fil och ändrar namnet på den tidigare versionen något, kommer snart kaos att börja i projektet och ingen kommer att förstå vilka filer som måste öppnas.

Git

För att lösa problemet med att spara en ny version av filer är det bekvämt att använda versionskontrollsystem. En av de mest populära är Git. Git kan jämföras med processen att spara och ladda i datorspel:

• om en svår strid väntar, är det innan dess bättre att spara i förväg;
• för att göra detta måste du utföra ett speciellt kommando;
• varefter lagringen går till en speciell mapp och innehåller spelets tillstånd;
• nu, om det behövs, är det alltid möjligt att återgå till den tidigare versionen av spelet.

SomeGame / | - sparar | | - save001.sav | | - save002.sav | | … | | spara mapp | | - game.exe | ... spelfiler

De filer som krävs för att programmet ska köras lagras i arbetsytan. Sparar-mappen innehåller historiken för alla spelsparningar. Git sparar din projektkod på samma sätt: sparar går till en special dold mapp och arbetsområdet är innehållet i rotmappen.

Grundläggande koncept

GUI

Specialprogram kan göra det enklare att arbeta med Git och GitHub. Sådana program i en bekväm form visar ändringar i koden, en lista över åtaganden och har andra. bekväma funktioner... Vanligtvis i liknande program det är möjligt att utföra vanliga Git-kommandon: pull, push, commit, andra, bara genom att klicka på en knapp.

I kontakt med

Telegram

Skicka ditt goda arbete i kunskapsbasen är enkelt. Använd formuläret nedan

Bra jobbat till webbplatsen ">

Studenter, doktorander, unga forskare som använder kunskapsbasen i sina studier och arbete kommer att vara er mycket tacksamma.

Postat på http://www.allbest.ru/

Ministeriet för utbildning och vetenskap i Ryska federationen

Federal State Budgetary Education

Institutionen för högre yrkesutbildning

"TOMSK STATE UNIVERSITY

STYRSYSTEM OCH RADIOELEKTRONIK "(TUSUR)

Institutionen för radiotekniska system (RTS)

Kursarbete

på kursen "Informationsteknik"

VERSIONSKONTROLLSYSTEM

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

Kuleshov M.V., Sadov D.A., Taimasov S.S.

Chef för Nozdrevatykh B.F

Kursuppgifter 46s., 31 figurer, 2 tabeller, källor.

VERSIONSKONTROLLSYSTEM, GIT, SVN, MERCURIAL.

I den här kursen arbetar mest populära system versionskontroll.

Syftet med arbetet är att sätta sig in i versionskontrollsystem, att förstå deras arbete, installation och konfiguration.

Under arbetets gång installerades tre typer av versionskontrollsystem med deras konfiguration och testning.

Som ett resultat kompilerade tre versionskontrollsystem, helt redo för drift, tabeller för jämförelse av funktionerna i dessa system och en ordbok med termer som används när man arbetar med program.

Kursarbetet görs i en textredigerare Microsoft Word 2010 och presenteras i tryckt och elektronisk form.

versionskontrollsystemets gränssnitt

Introduktion

3.1 Komma igång med ett projekt

3.2 Daglig arbetscykel

3.3 Filialer

3.4 Sammanfoga versioner

3.5 Konflikter och deras lösning

3.6 Lås

3.7 Projektversioner, taggar

4.1 Lokala versionskontrollsystem

4.2 Centraliserad modell

5.1.1 Systemkrav

5.1.2 Koncept

5.1.3 Komma igång

5.2.1 Systemkrav

5.2.2 Installation

5.2.3 Grundkoncept

5.2.4 Skapa ett arkiv

5.2.5 Importera ett projekt

5.2.7 Ändringar

5.2.8 Lägga till nya filer

5.2.9 Kasta ändringar

5.3.1 Systemkrav

5.3.2 Koncept

5.3.3 Komma igång

Slutsats

Bilaga A

Bilaga B

Bilaga B

Introduktion

Idag, i en värld där det finns ett stort antal komplexa system, finns det ett behov av att modifiera elektroniska dokument i olika stadier av sin utveckling. Under dess existens kan ett elektroniskt dokument bli föremål för ett stort antal ändringar. Men det händer ofta att ytterligare arbete kräver inte bara den senaste versionen av dokumentet, utan också olika tidigare versioner.

Naturligtvis kan du lagra flera olika alternativ. krävs dokument, men den här vägen ineffektiv. Vi måste lägga ner mycket tid och kraft, särskild uppmärksamhet behövs och sannolikheten för fel är stor. Dessutom måste vi lagra en enorm mängd nästan identiska dokument.

Följaktligen har mjukvaruverktyg utvecklats som förenklar denna mekanism. Dessa verktyg kallas versionskontrollsystem. Det finns flera system av detta slag, som vart och ett är relevant under vissa användningsförhållanden.

Huvudidén med versionskontrollsystem är att komma ihåg allt förändringar gjorda, samt kommentarer från användare som gjort dem. Efter det blir det tydligt vem, när och vad som förändrades, varför och varför. Och, viktigare, alla dessa förändringar kan sedan rullas tillbaka till vilken tidpunkt som helst.

I enlighet med det uppsatta målet är det nödvändigt att lösa följande uppgifter:

Definiera konceptet för ett versionskontrollsystem;

Förstå hur sådana system fungerar;

Tänk på installations- och startregler;

Analysera befintliga versionskontrollsystem;

Tänk på huvudtyperna av denna typ av system.

Arbetets uppgifter förutbestämde dess struktur. Kursarbetet består av fem kapitel, en inledning, en avslutning, en bibliografi och en bilaga.

1. Konceptet med ett versionskontrollsystem

Versionskontrollsystem (VCS) - programvara för att underlätta arbetet med att ändra information. Versionskontrollsystemet låter dig lagra flera versioner av samma dokument, om nödvändigt, återgå till tidigare versioner, bestämma vem och när som gjorde den eller den ändringen.

2. Använda ett versionskontrollsystem

De flesta av dessa system används i mjukvaruutveckling, så att källkoderna för de utvecklade programmen kan lagras. VCS tillåter utvecklare att lagra tidigare versioner av filer från utveckling och hämta dem därifrån. Den lagrar versionsinformation för varje fil (och hela projektstrukturen) i en samling, vanligen kallad ett arkiv. Men inte desto mindre kan dessa system användas inom andra kunskapsområden, som inkluderar ett stort antal elektroniska dokument som ofta ändras. Till exempel används de alltmer i CAD, vanligtvis som en del av produktdatahanteringssystem (PDM). Versionskontroll används i verktyg för konfigurationshantering.

Användningen av SLE är verkligen ett måste för en utvecklare om projektet är mer än några hundra rader eller om flera utvecklare arbetar tillsammans för projektet.

Versionskontrollsystem löser följande problem:

Lagra versioner av filer;

Möjlighet att få alla tidigare versioner av lagrade filer;

Visa ändringar som gjorts mellan de versioner som anges i begäran;

3. Typisk procedur för att arbeta med systemet

Varje VCS har sina egna specifika funktioner i uppsättningen av kommandon, hur användare arbetar och administration. Dock, allmän ordning arbete för de flesta SLE är helt stereotypt. Här förutsätts att projektet, vad det än kan vara, redan existerar och dess arkiv ligger på servern som utvecklaren har tillgång till.

3.1 Komma igång med ett projekt

Det första steget som en utvecklare måste ta är att kolla in en arbetskopia av projektet, eller vilken del av det att arbeta med. Den här åtgärden utförs med standardkommandot för checkout eller clone checkout, eller ett anpassat kommando som faktiskt utför samma åtgärd. Utvecklaren anger vilken version som ska kopieras; som standard kopieras den senaste (eller den som har valts av administratören som huvudversion) som standard.

Extraktionskommandot upprättar en anslutning till servern och projektet kopieras till utvecklarens dator i form av ett träd med kataloger och filer. Det är vanligt att duplicera en arbetskopia: förutom huvudkatalogen med projektet på lokal disk dessutom spelas en annan kopia av den in. När man arbetar med ett projekt, ändrar utvecklaren bara filerna i huvudarbetskopian. Den andra lokala kopian lagras som en referens, vilket gör det möjligt att när som helst utan att kontakta servern avgöra vilka ändringar som gjordes i en viss fil eller projekt som helhet och från vilken version en arbetskopia gjordes; som regel kommer varje försök att manuellt ändra denna kopia att resultera i fel i driften av VCS-programvaran.

3.2 Daglig arbetscykel

Med vissa variationer, bestämt av systemets egenskaper och detaljerna i den antagna affärsprocessen, ser den vanliga arbetscykeln för utvecklaren under arbetsdagen ut så här:

1) Uppdatering av arbetskopian. När ändringar görs i huvudversionen av projektet åldras arbetskopian på utvecklarens dator: dess avvikelse med huvudversionen av projektet ökar. Detta ökar risken för motstridiga förändringar. Därför är det bekvämt att hålla arbetskopian så nära den aktuella huvudversionen som möjligt genom att utvecklaren uppdaterar arbetskopian så ofta som möjligt.

2) Ändring av projektet. Utvecklaren modifierar projektet genom att ändra filerna som ingår i det i arbetskopian i enlighet med projektuppgiften. Detta arbete görs lokalt och kräver inga anrop till VCS-servern.

3) Begå förändringar. Efter att ha slutfört nästa steg i arbetet med uppgiften, förbinder (commit) utvecklaren sina ändringar, överför dem till servern eller till huvudgrenen, om arbetet med uppgiften är helt slutförd, eller till en separat utvecklingsgren av denna uppgift. CLE:n kan kräva att utvecklaren ser till att uppdatera arbetskopian innan den genomförs. Om systemet har hyllstöd kan ändringar överföras till servern utan att binda. Om den godkända arbetspolicyn i SLE tillåter detta, kan korrigeringen av ändringar utföras inte dagligen, utan endast efter avslutat arbete med uppgiften; i det här fallet, till slutet av arbetet, sparas alla ändringar relaterade till jobbet endast i utvecklarens lokala arbetskopia.

3.3 Filialer

Du kan göra mindre korrigeringar i projektet genom att direkt redigera arbetskopian och sedan överföra ändringarna direkt till huvudgrenen (trunken) på servern. Men när man utför någon betydande mängd arbete blir denna procedur obekväm: bristen på att begå mellanliggande ändringar på servern tillåter inte att arbeta med någonting i ett gruppläge, dessutom ökar risken för att förlora förändringar i lokala olyckor och förmågan att analysera och återgå till tidigare går förlorad kodvarianter inom detta arbete. Därför, för sådana förändringar, är det vanligt att skapa filialer, skapa en version av en ny version av projektet eller en del av det, där utvecklingen utförs parallellt med ändringarna i huvudversionen. När arbetet som grenen skapas för är gjort, återintegreras grenen i huvudgrenen. Detta kan göras med ett sammanfogningskommando, eller genom att skapa en patch som innehåller ändringarna som gjorts under utvecklingen av grenen och tillämpa den patchen på den aktuella huvudversionen av projektet.

3.4 Sammanfoga versioner

Tre typer av operationer som utförs i källkontroll kan leda till behovet av att slå samman ändringar:

Uppdatera en arbetskopia;

Begå förändringar;

Slår ihop grenar.

Varje system har en automatisk sammanfogningsmekanism som fungerar baserat på följande principer:

Ändringar kan bestå av att modifiera innehållet i en fil, skapa en ny fil eller katalog, ta bort eller byta namn på en redan existerande fil eller katalog i projektet;

Om två ändringar hänvisar till olika och orelaterade filer och/eller kataloger kan de alltid slås samman automatiskt. Deras kombination är att ändringarna som görs i varje version av projektet kopieras till den sammanslagna versionen;

Skapande, radering och byte av filer i projektkatalogerna kan slås samman automatiskt, så länge de inte kommer i konflikt med varandra. I det här fallet kopieras ändringarna som görs i varje version av projektet till den sammanslagna versionen.

Motstridiga är vanligtvis:

Ta bort och ändra samma fil eller katalog;

Ta bort och byta namn på samma fil eller katalog;

Skapa i olika versioner av en fil med samma namn och olika innehåll;

Förändringar inom ett textfil gjorda i olika versioner kan slås samman om de finns på olika platser i den här filen och inte överlappar varandra. I det här fallet görs alla ändringar som görs i den sammanslagna versionen;

Ändringar inom samma fil, om det inte är en textfil, är alltid motstridiga och kan inte slås samman automatiskt.

I samtliga fall grundläggande version för en sammanslagning, versionen där de sammanslagna versionerna delades upp. Om detta är en commit-operation, kommer basversionen att vara versionen av den senaste uppdateringen före commit, om en uppdatering, sedan versionen av den tidigare uppdateringen, om du slår samman grenar, sedan versionen där motsvarande gren skapades. Följaktligen kommer de jämförda ändringsuppsättningarna att vara de ändringar som gjorts från baslinjen till den nuvarande versionen i alla varianter som slås samman.

De allra flesta moderna versionskontrollsystem är främst inriktade på programvaruutvecklingsprojekt där huvudtypen av filinnehåll är text. Följaktligen styrs mekanismer för automatisk sammanslagning av ändringar av bearbetningen av textfiler.

När man avgör tillåtligheten av att slå samman ändringar inom samma textfil, fungerar en typisk mekanism för att jämföra text rad för rad (ett exempel på dess implementering är GNU diff-systemverktyget), som jämför de sammanslagna versionerna med basversionen och bygger en lista över ändringar, det vill säga tillagda, raderade och ersatta uppsättningar rader ... Hittade uppsättningar av ändrade linjer som inte korsar varandra anses vara kompatibla och sammanslagning sker automatiskt. Om de sammanslagna filerna innehåller ändringar som påverkar samma rad i filen leder detta till en konflikt. Sådana filer kan endast slås samman manuellt. Alla andra filer än textfiler är binära ur SCR-synpunkt och tillåter inte automatisk sammanslagning.

3.5 Konflikter och deras lösning

Situationen när, när flera versioner slås samman, de ändringar som görs i dem korsar varandra, kallas en konflikt. Om det finns en konflikt mellan ändringar, kan källkontrollsystemet inte automatiskt skapa det sammanslagna projektet och tvingas kontakta utvecklaren. Som nämnts ovan kan konflikter uppstå under commit-, uppdaterings- eller merge-faserna. I alla fall, när en konflikt upptäcks, avslutas motsvarande operation tills den är löst.

För att lösa konflikten erbjuder systemet i allmänhet utvecklaren tre alternativ för motstridiga filer: bas, lokal och server. Motstridiga ändringar visas antingen för utvecklaren i en speciell programmodul för sammanfogning av ändringar, eller helt enkelt markerade med speciell uppmärkning i texten i den sammanslagna filen.

Konflikter i filsystemet är lättare att lösa: bara borttagning av en fil kan komma i konflikt med en av de andra operationerna, och ordningen på filerna i katalogen spelar ingen roll, så utvecklaren kan bara välja vilken operation som ska sparas i den sammanslagna versionen .

3.6 Lås

Låsmekanismen tillåter en av utvecklarna att bara använda sin egen fil eller grupp av filer för att göra ändringar i dem. Medan filen är låst förblir den skrivskyddad för alla andra utvecklare, och varje försök att göra ändringar i den avvisas av servern. Blockering kan tekniskt sett organiseras på olika sätt. Följande mekanism är typisk för moderna system:

Filer som kräver blockering för att arbeta med är markerade med en speciell "blockerbar" flagga;

Om en fil markeras som låst tilldelas den ett skrivskyddat attribut på det lokala filsystemet när arbetskopian checkas ut från servern, vilket förhindrar oavsiktlig redigering;

En utvecklare som vill ändra en låst fil anropar ett speciellt låskommando med namnet på denna fil. Som ett resultat av detta kommando inträffar följande:

1. servern kontrollerar om filen redan är blockerad av en annan utvecklare; i så fall misslyckas blockeringskommandot.

2. filen på servern är markerad som "låst", samtidigt som identifieraren för utvecklaren som blockerade den och blockeringstiden behålls;

3. Om låsningen på servern lyckas tas det skrivskyddade attributet bort från arbetskopieringsfilen på det lokala filsystemet, vilket gör att du kan börja redigera den.

Om det under arbetets gång visar sig att filen inte behöver ändras kan den anropa kommandot för att låsa upp (lås upp , frigöringslås). Alla ändringar av filen kommer att avbrytas, den lokala filen kommer att återgå till skrivskyddat tillstånd, attributet "låst" kommer att tas bort från filen på servern och andra utvecklare kommer att kunna ändra den här filen;

Efter avslutat arbete med den låsta filen, begår utvecklaren ändringarna. Vanligtvis frigörs låset automatiskt.

3.7 Projektversioner, taggar

Versionskontrollsystemet ger lagring av alla befintliga filvarianter och som ett resultat av alla projektvarianter som helhet, som har ägt rum sedan början av utvecklingen. Men själva begreppet "version" i olika system kan tolkas på två olika sätt.

Vissa system stöder filversionshantering. Det betyder att alla filer som dyker upp i projektet får ett eget versionsnummer. Varje gång en utvecklare utför en ändring som påverkar en fil, tillämpas motsvarande del av den betingade ändringen på filen, och filen ges ett nytt, vanligtvis nästa, versionsnummer.

För andra system hänvisar versionen inte till en enskild fil, utan till hela förvaret. Det nyskapade tomma arkivet har version 1 eller 0, alla ändringar kommer att öka detta antal. Versionsnumret för en separat fil finns faktiskt inte här.

Båda alternativen är dock inte särskilt bekväma. Versionskontrollsystem stödjer konceptet med taggar för enklare taggning av projektversioner.

En tagg är en symbolisk tagg som kan associeras med en specifik version av en fil och/eller katalog i ett arkiv. Med hjälp av lämpligt kommando kan alla eller delar av projektfilerna som uppfyller vissa villkor tilldelas en given etikett. Således kan du identifiera versionen av projektet och fixa dess tillstånd vid ett önskat tillfälle. Typiskt är taggningssystemet tillräckligt flexibelt för att tagga icke-samtidiga versioner av filer och kataloger med en enda tagg. Detta gör att du kan bygga en "projektversion" på vilket godtyckligt sätt som helst.

4.1 Lokala versionskontrollsystem

Den mest föredragna VCS för att spåra hemutveckling kommer att vara den lokala typen. För att lösa detta problem utvecklades speciella VCS:er med en enkel databas där alla lokala filer lagras.

Figur 4.1 Schema för lokal SCR

En av de mer populära ACS av denna typ är RCS, som fortfarande är installerad på många datorer idag.

4.2 Centraliserad modell

Traditionella versionskontrollsystem använder en centraliserad modell där det finns ett enda arkiv med dokument som hanteras av dedikerad server som utför de flesta versionskontrollfunktionerna. En användare som arbetar med dokument måste först hämta den version av dokumentet han behöver från arkivet; vanligtvis skapas en lokal kopia av dokumentet, en så kallad "arbetskopia". Den senaste versionen kan erhållas, eller någon av de tidigare, som kan väljas efter versionsnummer eller skapandedatum, ibland efter andra kriterier. Efter att nödvändiga ändringar har gjorts i dokumentet, placeras den nya versionen i arkivet. Till skillnad från att bara spara en fil, raderas inte den tidigare versionen, utan finns också kvar i förvaret och kan hämtas därifrån när som helst.

System som CVS, Subversion och Perforce har en central server som lagrar alla versionsfiler och ett antal klienter som får kopior av filerna från den. Detta har varit standarden för versionskontrollsystem i många år.

Figur 4.2 Schema för centraliserad versionskontroll

Detta tillvägagångssätt har många fördelar, särskilt jämfört med lokala SLE. Alla vet till exempel vem som gör vad i projektet. Administratörer har tydlig kontroll över vem som kan göra vad, och naturligtvis är det mycket lättare att administrera CSKV än lokala databaser på varje klient.

Detta tillvägagångssätt har emellertid flera allvarliga nackdelar. Den mest uppenbara är att en centraliserad server är en sårbarhet i hela systemet. Om servern är avstängd i en timme, kan utvecklarna inte interagera under en timme, och ingen kan spara en ny version av sitt arbete. Om disken med den centrala databasen blir skadad och nej säkerhetskopiering, du förlorar absolut allt - hela projektets historia, med undantag för ett fåtal fungerande versioner sparade på användarens arbetsmaskiner. Lokala VCS:er är föremål för samma problem: om hela historiken för ett projekt lagras på ett ställe riskerar du att förlora allt.

4.3 Distribuerade versionskontrollsystem

Sådana system använder en distribuerad modell istället för den traditionella klient-server-modellen. I allmänhet behöver de inte en centraliserad lagring: hela historiken för dokumentändringar lagras på varje dator, i den lokala lagringen, och vid behov synkroniseras enskilda fragment av den lokala lagringshistoriken med en liknande lagring på en annan dator. Därför, i händelse av att servern genom vilken arbetet gick ner, kan vilket klientförråd som helst kopieras tillbaka till servern för att återställa databasen. På vissa av dessa system finns lokal lagring direkt i arbetskopiornas kataloger.

Figur 4.3 Distribuerad SCR-modell

När en användare av ett sådant system utför normala åtgärder, såsom att checka ut en specifik version av ett dokument, skapa en ny version och liknande, arbetar han med sin lokala kopia av förvaret. När ändringar görs, börjar förråd som tillhör olika utvecklare att skilja sig åt, och det blir nödvändigt att synkronisera dem. Denna synkronisering kan göras genom att byta patchar eller så kallade kit mellan användare.

Den beskrivna modellen är logiskt sett nära att skapa en separat gren för varje utvecklare i det klassiska versionskontrollsystemet. Skillnaden är att andra utvecklare inte ser denna gren förrän synkroniseringen. Så länge en utvecklare bara byter egen gren så påverkar hans arbete inte andra projektdeltagare och vice versa. Efter slutförandet av den isolerade delen av arbetet slås de ändringar som gjorts i grenarna samman med huvudgrenen (allmänna). Både vid sammanslagning av grenar och vid synkronisering av olika repositories är versionskonflikter möjliga. I det här fallet tillhandahåller alla system en eller annan metod för att upptäcka och lösa sammanslagningskonflikter.

Ur användarens synvinkel kännetecknas ett distribuerat system av behovet av att skapa ett lokalt arkiv och närvaron på kommandospråket för två ytterligare kommandon: kommandon för att hämta ett arkiv från en fjärrdator och överföra ditt arkiv till fjärrdator... Det första kommandot slår samman ändringar i de fjärranslutna och lokala arkiven och placerar resultatet i det lokala arkivet; den andra, tvärtom, slår samman ändringarna av de två förvaren och placerar resultatet i ett fjärrlager. Som regel låter sammanslagningskommandona i distribuerade system dig välja vilka uppsättningar av ändringar som ska överföras till eller checkas ut från ett annat förråd, fixa sammanslagningskonflikter direkt under operationen eller efter att den misslyckats, göra om eller återuppta en oavslutad sammanslagning. Vanligtvis lyckas det bara att driva dina ändringar till någon annans arkiv om det inte finns några konflikter. Om konflikter uppstår måste användaren först slå samman versionerna i sitt arkiv och först därefter överföra dem till andra.

Det rekommenderas vanligtvis att organisera arbetet med systemet så att användare alltid eller övervägande utför sammanslagningen i sitt förråd. Det vill säga, till skillnad från centraliserade system, där användare skickar in sina ändringar till en central server när de finner det lämpligt, i distribuerade system är det mer naturligt att beställa när sammanslagningen av versioner initieras av den som behöver få sitt resultat (t.ex. utvecklaren som hanterar byggservern) ...

De främsta fördelarna med distribuerade system är deras flexibilitet och betydligt högre (i jämförelse med centraliserade system) autonomi för en separat arbetsplats. Varje utvecklares dator är i själva verket en oberoende och fullt fungerande server, från sådana datorer är det möjligt att bygga ett system av vilken struktur och komplexitetsnivå som helst genom att ställa in önskad synkroniseringsordning.

Nackdelarna med distribuerade system inkluderar en ökning av den nödvändiga mängden diskminne: varje dator måste lagra en fullständig versionshistorik, medan i ett centraliserat system på utvecklarens dator lagras vanligtvis bara en arbetskopia, det vill säga en del av förvaret någon gång i tiden och de ändringar som gjorts. En mindre uppenbar men frustrerande nackdel är att det är nästan omöjligt i ett distribuerat system att implementera en del av de funktioner som tillhandahålls av centraliserade system. Detta:

- Blockering av en fil eller en grupp av filer (för att lagra blockeringstecknet behövs en offentlig och permanent online central server). Detta tvingar dig att vidta särskilda administrativa åtgärder om du måste arbeta med binära filer som inte är lämpliga för automatisk sammanslagning;

- Spåra en specifik fil eller grupp av filer;

- Enhetlig end-to-end-numrering av system- och/eller filversioner, där versionsnumret ökar monotont. I distribuerade system måste du nöja dig med lokala versionsbeteckningar och användningstaggar, vars syfte bestäms av överenskommelse mellan utvecklarna eller företagets företagsstandarder;

- Lokalt arbete av användaren med ett separat, litet urval från lagringen, betydande i storlek och intern komplexitet, på en fjärrserver.

Följande typiska situationer kan urskiljas där användningen av ett distribuerat system ger märkbara fördelar:

- Periodisk synkronisering av flera datorer under kontroll av en utvecklare. Att använda ett distribuerat system eliminerar behovet av att allokera en av datorerna som en server;

- Gemensamt arbete på ett projekt av en liten geografiskt spridd grupp utvecklare utan att allokera gemensamma resurser. Som i det föregående fallet implementeras arbetsschemat utan huvudservern, och relevansen av förråden upprätthålls av periodiska synkroniseringar enligt "varje med varje"-schemat;

Ett stort distribuerat projekt, vars deltagare kan arbeta länge på egen hand, samtidigt som de inte har en fast koppling till nätverket. Ett sådant projekt kan använda en centraliserad server med vilken kopior av alla dess deltagare synkroniseras. Det är möjligt att arbeta utan "grupp"-servrar, sedan synkroniserar utvecklarna av en grupp ändringarna med varandra, varefter någon av dem överför ändringarna till den centrala servern.

5. Exempel på versionskontrollsystem

5.1 Git

5.1.1 Systemkrav

Git körs på följande operativsystem: Windows, Linux och Mac OS.

För att installera Git på Windows behöver du bara ladda ner installationsprogrammets exe-fil från projektets GitHub-sida och köra den. När den är installerad kommer du att ha både konsolversionen (inklusive SSH-klienten) och den grafiska standardversionen.

5.1.2 Koncept

Gitär ett distribuerat versionskontrollsystem. I den kan filer vara i ett av tre tillstånd: engagerad, modifierad och förberedd. "Committed" betyder att filen redan har sparats i din lokal bas... Ändrade filer inkluderar filer som har ändrats men som ännu inte har registrerats. Provisionerade filer är modifierade filer som är markerade för att inkluderas i nästa commit.

Sålunda har projekt som använder Git tre delar: Git-katalogen, arbetskatalogen och iscensättningsområdet.

Git-katalogen är där Git lagrar metadata och objektdatabasen för ditt projekt. Detta är den viktigaste delen av Git och kopieras när du klona förvaret från en annan maskin.

Arbetskatalogen är en kopia av en specifik version av projektet extraherad från databasen. Dessa filer hämtas från en komprimerad databas i Git-katalogen och placeras på disken så att du kan se och redigera dem.

Staging-området är en vanlig fil, vanligtvis lagrad i Git-katalogen, som innehåller information om vad som ska gå in i nästa commit. Kallas ibland för index, men på senare tid har det blivit standard att referera till det som staging-området (uppställningsplats).

Ett typiskt Git-arbetsflöde ser ut ungefär så här:

1. Du gör ändringar i filerna i din arbetskatalog.

2. Förbered filerna genom att lägga till deras ögonblicksbilder i området för förberedda filer.

3. Gör en commit, som tar de förberedda filerna från indexet och placerar dem i Git-katalogen för beständig lagring.

Om arbetsversionen av filen stämmer överens med versionen i Git-katalogen "a, anses filen committed. Om filen ändras men läggs till i det förberedda dataområdet förbereds den. Om filen har ändrats efter att ha laddats ut från databas, men inte förbereddes, anses den vara modifierad.

5.1.3 Komma igång

Alla jobbar i Git händer i ett arkiv som innehåller alla arbetsfiler. Det finns olika sätt att skapa ett arkiv.

1. Via snabbmenyn. För att göra detta behöver du bara högerklicka i den önskade katalogen och välja alternativet Git Init Here.

Figur 5.1.1 Skapa ett arkiv med hjälp av snabbmenyn

2. Använd kommandoraden. För att göra detta, på samma sätt, i den önskade katalogen, välj Git Bash från snabbmenyn. En kommandorad öppnas där vi skapar ett arkiv med kommandot Git Init.

Figur 5.1.2 Skapa ett arkiv med hjälp av kommandoraden

Om du aldrig har använt git tidigare måste du först ange ett namn och en e-postadress med nästan följande kommandon:

git config --global användarnamn "Ditt namn"

git config --global user.email [e-postskyddad]

Det skapade arkivet kommer att innehålla en .git-katalog. För att lägga till en fil till förvaret behöver du bara kopiera den till arbetskatalogen. Låt oss lägga till ex.txt-filen till förvaret. Använd kommandot git status för att se till att Git ser filen.

Figur 5.1.3 Lägg till och kontrollera en fil i arkivet

Vidare, för att lägga till en fil under versionskontroll, är det värt att indexera dessa filer och göra den första commit av ändringar. Detta kan åstadkommas med några få git add-kommandon som anger vilka filer som ska indexeras, och sedan git commit.

Figur 5.1.4 Lägga till en fil under versionskontroll

Kommandot git status är huvudverktyget som används för att avgöra vilka filer som är i vilket tillstånd.

För att börja spåra (lägg till under versionskontroll) en ny fil, använd kommandot git add "filnamn". Detta kommando tar som en parameter sökvägen till en fil eller katalog, om det är en katalog lägger kommandot rekursivt till (indexerar) alla filer i denna katalog.

Git commit -m "comment" - ett kommando för att skapa en commit, commit a change.

Låt oss upprepa föregående operation med Git Gui. För att göra detta, välj alternativet Git Gui i snabbmenyn.

Figur 5.1.5

I fönstret som öppnas väljer du "Skapa ett nytt arkiv". Därefter kommer vi att ange i vilken katalog vi vill placera förvaret.

Figur 5.1.6 Skapa ett arkiv i Git Gui

Lägg till filen Ex.txt i katalogen. Sedan trycker vi på knappen "Reread". För att lägga till en fil i versionskontrollsystemet måste du klicka på knappen "Förbered allt". Ex.txt-filen bör flyttas från Modified till Prepared. För att genomföra ändringen, använd knappen "Spara".

5.1.5 Göra en kopia av förvaret

Nuförtiden har du ett stort antal värdalternativ att välja mellan, alla med sina egna fördelar och nackdelar.

Det här avsnittet leder dig genom processen att skapa ett konto och ett nytt projekt på GitHub. Detta kommer att ge dig en uppfattning om vad som är involverat.

GitHub är den största Git-värdsidan för projekt med öppen källkod idag, och en av få som tillhandahåller både offentlig och privat värd.

Det första du ska göra är att skapa ett konto och skapa ditt arkiv på http://github.com/plans.

Därefter, på Git-kommandoraden, skriv in de kommandon vi redan känner till:

Git add ex.txt

Git commit -m "comment"

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

Git push -u origin master

Git remote add-kommandot lägger till fjärrlager, och git push-kommandot driver lokala ändringar till en fjärrserver.

Figur 5.1.7

Ange användarnamnet och lösenordet som angavs vid registreringen:

Figur 5.1.8

Nu finns vårt projekt på GitHub, i arkivet - MyHomework med Tusur.txt-filen och vi kan länka till den till vem som helst som vi vill dela projektet med.

Figur 5.1.9 GitHub-förråd

5.2 TortoiseSVN

5.2.1 Systemkrav

TortoiseSVN körs på Windows XP (med Service Pack 3) eller högre, och finns i både 32-bitars och 64-bitarsversioner. Installationsprogrammet för 64-bitars Windows innehåller också en 32-bitars del.

5.2.2 Installation

TortoiseSVN kommer som en lättanvänd installationsfil.

5.2.3 Grundkoncept

Lagring. Subversion använder en central databas som innehåller alla versionerade filer från deras fullständig historia... Denna databas kallas ett arkiv. Lagret är vanligtvis placerat på en filserver på vilken Subversion är installerad, och serverar data till Subversion-klienter på begäran (t.ex. TortoiseSVN). Om du gör en säkerhetskopia, kopiera sedan ditt valv, eftersom detta är originalet av alla dina data.

Arbetsexemplar. Det är precis där du jobbar. Varje utvecklare har sin egen arbetskopia, ibland kallad en sandlåda, på sin lokala dator. Du kan hämta den senaste versionen av filer från förvaret, arbeta med det lokalt utan att interagera med någon annan, och när du är säker på ändringarna kan du överföra dessa filer tillbaka till förvaret. En arbetskopia innehåller inte historiken för projektet, men den innehåller en kopia av alla filer som fanns i förvaret innan du började göra ändringar.

TortoiseSVN är ett Windows Explorer-tillägg, så först måste du starta Explorer.

Figur 5.2.1 Visa i Utforskaren

5.2.4 Skapa ett arkiv

För ett riktigt projekt behöver vi ett arkiv som är installerat på en säker plats och en Subversion-server för att hantera det. Vi kommer att använda Subversions lokala arkivfunktion, som ger direkt åtkomst till ett arkiv skapat på din hårddisk och inte kräver en server.

Låt oss först skapa en ny tom katalog på datorn. Det kan vara var som helst, men i det här arbetet kommer vi att kalla det s: \ svn_repos. Nu genom att högerklicka på den nya mappen och in innehållsmeny välj TortoiseSVN> Skapa arkiv här ... Lagret som skapats i mappen är klart att använda. Vi kommer också att skapa en intern mappstruktur genom att klicka på knappen "Skapa katalogstruktur".

Figur 5.2.2 Skapa ett arkiv

Figur 5.2.3 visar förvaret

5.2.5 Importera ett projekt

Vi har nu ett förråd, men det är helt tomt för tillfället. Låt oss anta att vi har en uppsättning filer i E: \ \ TortoiseSVN som vi skulle vilja lägga till. Låt oss gå till mappen TortoiseSVN i Utforskaren och högerklicka på den. Välj nu TortoiseSVN> Importera ... vilket kommer att få upp en dialogruta.

Figur 5.2.4 Importfönster

Ett Subversion-förråd nås av en URL som gör att vi kan peka förvaret var som helst på Internet. V I detta fall vi måste peka på vårt lokala arkiv som har url-filen: /// s: / svn_repos och till vilket vi lägger till namnet på vårt TortoiseSVN-projekt.

En annan viktig funktion i den här dialogrutan är fönstret Importera meddelande, där du kan lägga till ett meddelande om vad vi gör. Närhelst vi behöver granska historiken för ett projekt kommer dessa meddelanden att vara ett värdefullt verktyg för att se vilka ändringar som gjordes och när.

5.2.6 Kolla in en arbetskopia

Vi har nu ett projekt i vårt arkiv och vi behöver skapa en arbetskopia för vårt dagliga arbete. Det är värt att notera att import av en mapp inte automatiskt förvandlar den mappen till en arbetskopia. Subversion använder termen "Checkout" för att skapa en ny arbetskopia. Vi kommer att extrahera mappen TortoiseSVN från vårt arkiv till en utvecklingsmapp som heter e: \ \ TortoiseSVN \ svn_repos. Skapa den här mappen, högerklicka sedan på den och välj TortoiseSVN> Checka ut ... Ange webbadressen till kassan, i det här fallet filen: /// s: / svn_repos / TortoiseSVN, och klicka på OK. Vår utvecklingsmapp kommer att fyllas med filer från förvaret.

Den här mappen ser annorlunda ut än en vanlig mapp. Varje fil har en grön kryssruta i det vänstra hörnet. Dessa är TortoiseSVN-statusikonerna som bara finns i arbetskopian. Grön status betyder att filen inte skiljer sig från versionen av filen i förvaret.

5.2.7 Ändringar

Du kan ta dig till jobbet. I mappen TortoiseSVN börjar vi modifiera filer - anta att vi gör ändringar i TortoiseSVN.docx-filer. Observera att ikonerna på dessa filer nu är röda för att indikera att ändringarna gjordes lokalt.

Högerklicka på en av de modifierade filerna och välj TortoiseSVN> Skillnader. Detta kommer att starta filjämförelseverktyget TortoiseSVN och visa dig exakt vilka rader i filerna som har ändrats.

Figur 5.2.5 Filjämförelse

Låt oss nu uppdatera förvaret. Denna åtgärd kallas Commit Changes. Högerklicka på mappen TortoiseSVN och välj TortoiseSVN> Commit. En commit-dialogruta kommer att visas med en lista över ändrade filer och det kommer att finnas en bock bredvid varje. Vi kan bara välja ett fåtal filer från listan att begå.

Figur 5.2.6 Kommittera filer

5.2.8 Lägga till nya filer

När vi arbetar med ett projekt behöver vi lägg till nya filer, anta att vi lagt till nya funktioner i filen och lagt till hjälp i den befintliga filen. Högerklicka på mappen och välj TortoiseSVN> Lägg till. Lägg till dialogrutan visar alla filer utan version och vi kan välja de filer som vi vill lägga till. Ett annat sätt att lägga till filer är att högerklicka på själva filen och välja TortoiseSVN> Lägg till.

Om vi ​​nu öppnar mappen för att commit, kommer den nya filen att visas som tillagd och den befintliga filen som modifierad.

5.2.9 Kasta ändringar

En vanlig funktion för alla revisionskontrollsystem är funktionen som gör att vi kan ångra ändringar som vi gjort tidigare.

Om vi ​​vill bli av med ändringarna som vi ännu inte har hunnit genomföra och återställa den önskade filen i den form den var innan ändringarna började, välj sedan kommandot TortoiseSVN> Ta bort ändringar. Detta kommer att ångra våra ändringar och returnera den fasta versionen av filen vi började med. Om vi ​​bara vill ta bort några av ändringarna kan vi använda verktyget TortoiseMerge för att se ändringarna och selektivt ta bort de ändrade raderna.

Om vi ​​vill ångra åtgärderna för en specifik revision börjar vi från loggdialogrutan och hittar den problematiska revisionen. Välj kontextmenyn> Ångra ändringar från det här revisionskommandot och dessa ändringar kommer att avbrytas.

5.2.10 TortoiseSVN-funktioner. Shell integration

TortoiseSVN integreras direkt i Windows-skalet (dvs. Utforskaren). Det betyder att du kan arbeta med de verktyg du redan känner till utan att behöva byta till en annan applikation varje gång du behöver versionskontrollfunktioner!

Och du behöver inte ens använda Explorer. TortoiseSVN-kontextmenyer fungerar i många andra filhanterare och filöppningsdialoger som används i de flesta vanliga Windows-program. Du bör dock ta hänsyn till att TortoiseSVN ursprungligen designades som en förlängning för Windows Utforskaren, och eventuellt i andra applikationer kommer integreringen inte att vara komplett, till exempel kan överlagringar på ikoner inte visas.

Statusen för varje versionsfil och mapp visas med en liten överlagring över huvudikonen. På så sätt kan du omedelbart se statusen för din arbetskopia.

5.2.11 Grafiskt användargränssnitt

När du tittar på listan över ändringar av en fil eller mapp kan du klicka på en revision för att se kommentarerna för den commit. En lista över modifierade filer finns också - dubbelklicka bara på en fil för att se vilka specifika ändringar som har gjorts.

commit-dialogrutan är en lista som listar alla filer och mappar som kommer att inkluderas i commit. Varje listobjekt har en kryssruta så att du kan välja exakt vad du vill inkludera i commit. Omvända filer kan också visas i den här listan så att du inte glömmer att lägga till en ny fil eller mapp till commit.

Alla Subversion-kommandon är tillgängliga från Utforskarens snabbmeny. TortoiseSVN lägger till sin egen undermeny där.

5.3 Mercurial

5.3.1 Systemkrav

P Mercurial-paket är tillgängliga för alla populära operativsystem: Windows, Mac OS, Linux (Ubuntu, Debian, Fedora, OpenSUSE, Gentoo), Solaris.

Den bästa versionen av Mercurial för Windows är TortoiseHg, som finns på http://tortoisehg.org. Detta paket låter dig använda kommandoraden och det grafiska användargränssnittet.

5.3.2 Koncept

Mercurial är ett distribuerat (decentraliserat) versionskontrollsystem. Det betyder att arbetsflödet vanligtvis ser ut så här:

1. Ett nytt arkiv skapas på en persondator (genom kloning befintligt förvar, skapa en ny, etc.);

2. Filer i arbetskatalogen för detta arkiv ändras / läggs till / tas bort;

3. Ändringarna gäller det givna arkivet (det vill säga det lokala arkivet på persondatorn);

4. Steg 2 och 3 upprepas så många gånger som behövs;

5. Vid behov synkroniseras ändringar med andra arkiv: någon annans ändringsuppsättningar tas (pull) och/eller deras egna ändringar ges (push).

Det vill säga att allt dagligt arbete sker i det lokala förvaret och när behov uppstår skickas resultatet av deras arbete till ett eller flera andra förvar. Stegen som är involverade i att arbeta med fjärrlager kan reduceras genom att konfigurera Mercurial till automatisk avsändningändringar till andra arkiv när du commit.

5.3.3 Komma igång

Du kan arbeta i Mercurial genom utforskarens snabbmeny, arbetsytafönstret TortoiseHg Workbench (programmet skapar motsvarande genväg under installationen) eller kommandoraden med hjälp av hg-kommandot.

5.3.4 Skapa ett arkiv och arbeta med filer

I Mercurial händer allt i ett förråd. Projektförrådet innehåller alla filer som "tillhör" projektet, såväl som historiken för ändringar av dessa filer. Det finns tre olika sätt att skapa ett arkiv.

För att skapa ett arkiv via utforskarens snabbmeny, högerklicka helt enkelt på önskad mapp och välj lämpligt objekt.

Figur 5.3.1 Skapa ett arkiv

I fönstret som visas kan du bekräfta platsen för arkivmappen och öppna det skapade arkivet i arbetsmiljön.

Figur 5.3.2 Placering av arkivmappen

På liknande sätt skapas förvaret direkt i TortoiseHg Workbench-fönstret: sekvensen File \ New repository anropar ovanstående fönster med samma namn. På kommandoraden, för att skapa ett arkiv i den aktuella katalogen, använd kommandot hg init<имя хранилища>... Det skapade arkivet kommer att innehålla .hg-katalogen.

Figur 5.3.3 Skapa en arkivmapp via kommandoraden

Om vi ​​vill lägga till befintliga filer till förvaret kopierar vi dem in i arbetskatalogen och använder kommandot hg add för att säga till Mercurial att börja övervaka dem. Låt oss lägga till filen i arkivet och skapa en ny version.

Figur 5.3.4 Lägga till en fil i arkivet och skapa en ny revision

Se till att Mercurial ser den sparade filen. Statuskommandot visar statusen för arbetskopian jämfört med statusen för det lokala arkivet. Mercurial visar att den ser filen example.txt, men den filen är ännu inte under versionskontroll (symbolen "?" till vänster om filnamnet). För att tala om för Mercurial att versionera den kör vi hg add. Ett "A" visas till vänster om filnamnet, vilket betyder att filen readme.txt kommer att läggas till i källkontrollen vid nästa commit (när du skapar en ny version), som exekveras av kommandot hg commit.

Första gången hg commit-kommandot körs kan misslyckas. Mercurial registrerar ditt namn och din adress i varje revision så att du eller andra kan kontakta författaren till varje ändring. För att ställa in användarnamnet, ändra hgrc-filen som finns i .hg-katalogen i arbetskatalogen. Det ursprungliga innehållet i den här filen bör se ut ungefär så här:

# Detta är en Mercurial-konfigurationsfil.

användarnamn = Förnamn Efternamn [e-postskyddad]

Raden "" deklarerar en del av konfigurationsfilen. Du kan läsa "användarnamn = ..." som "ställ in värdet på användarnamnsvariabeln i användargränssnittet." Sektioner fortsätter tills början av nya sektioner. Tomma rader och rader som börjar med "#" ignoreras. Du kan använda vilken text som helst för användarnamnsvärdet, eftersom denna information är avsedd för andra personer och inte för Mercurials tolkning.I exemplet ovan användes en vanlig konvention för detta: en kombination av ett namn och en e-postadress.

När vi genomför ändringarna, placerar Mercurial oss i en textredigerare för att skriva in en kommentar som beskriver ändringarna vi gjort i denna ändringsuppsättning. Denna beskrivning kallas ett ändringsmeddelande (ändringsbeskrivning, revisionsbeskrivning). Detta kommer att vara en post för läsarna om vad vi gjorde och varför, och kommer att visas när vi kör kommandot hg log efter att vi har publicerat revisionen.

Editorn som öppnas med kommandot hg commit kommer att innehålla en tom rad och flera rader som börjar med "HG:".

HG: Ange commit-meddelande. Rader som börjar med "HG:" tas bort.

HG: Lämna meddelande tomt för att avbryta commit.

HG: -

HG: användare: användare

HG: branch "default"

HG: ändrat exempel.txt

Mercurial ignorerar rader som börjar med "HG:". Han använder dem bara för att berätta vilka filer han kommer att skriva ändringar till. Att redigera eller ta bort dessa rader kommer inte att påverka någonting. Om du ändrar dig om att göra ett inlägg medan du redigerar en kommentar, avsluta helt enkelt redigeraren utan att spara filen du redigerar. Detta kommer inte att orsaka ändringar i vare sig förvaret eller arbetskatalogen.

Kommandot hg log, som standard, skriver endast ut den första raden i ändringsbeskrivningen. Därför är det bättre att skriva kommentaren så att den första raden separeras. Det finns inga hårda och snabba regler för resten av revisionsbeskrivningen. Mercurial själv bearbetar eller bryr sig inte om innehållet i ändringsmeddelanden, även om ditt projekt kan ha regler som dikterar viss formatering.

Låt oss upprepa dessa operationer med TortoiseHg Workbench GUI. Innan du lägger till filen i arbetskatalogen ser fönstret ut så här.

Figur 5.3.5 Lägg till fil i arbetskatalogen

Låt oss överföra filen till förvaret och uppdatera fönstret genom att klicka på knappen till vänster i verktygsfältet. Låt oss lägga till filen i versionskontrollsystemet med hjälp av lämpligt kommando i snabbmenyn (analogt med hg add).

Figur 5.3.6 Kommandon i snabbmenyn

Figur 5.3.7 Lägg till fil

Efter att filen har lagts till skrivs beskrivningen av revisionen i det övre högra fönstret, och en ny version skapas genom att klicka på knappen "Bekräfta". En förteckning över de ändringar som gjorts visas i det nedre högra fönstret. Du kommer att märka att ändringarna presenteras i form av grafer.

Figur 5.3.8 Ändra grafer

Du kan också utföra ändringar med kommandot Hg Commit i snabbmenyn för filen som placerats i förvaret utan att starta Workbench.

Figur 5.3.9 Begå ändringar

Kommandot hg log eller hg diff här motsvarar "Jämför filversioner" (högerklicka på filnamnet).

Figur 5.3.10 Jämföra filrevisioner

I samma fönster kan du återgå till en av de tidigare versionerna genom att använda kommandot "Återgå till revision ..." eller "Återställ ändringar ..." i huvudfönstret. Låt oss demonstrera med ett exempel, efter att tidigare ha gjort några fler ändringar i filen example.txt. Den rödmarkerade linjen är omvända ändringar.

Figur 5.3.11 Kasta ändringar

5.3.5 Göra en kopia av förvaret

Även om du kan kopiera arkivet som en vanlig katalog, är det bättre att använda det inbyggda Mercurial-kommandot. Det kallas hg clone eftersom det skapar en identisk kopia av det befintliga förvaret. En av fördelarna med att använda hg clone är att det gör att repositories kan klonas över nätverket. En annan är att den kommer ihåg var vi klonade den ifrån.

Varje Mercurial-förråd är komplett, fristående och oberoende. Den innehåller en egen kopia av projektfilerna och deras historik. Det klonade förvaret kommer ihåg varifrån det klonades, men kommunicerar inte med det förvaret, eller med något annat, förrän du berättar det. Därför är du fri att experimentera med ditt arkiv. Detta är säkert eftersom ditt förråd är en "stängd sandlåda", ändringar som inte kommer att påverka något annat än sig själv.

Låt oss skapa en fjärrkopia av vårt arkiv (vi använder mappen Google Drive, som i sig är en molntjänst) genom att utföra kommandosekvensen File \ Clone repository i TortoiseHg Workbench. Resultatet visas i följande figur.

Figur 5.3.12 Skapa en fjärrlagringskopia

Mercurial låter dig överföra ändringar till ett annat arkiv från arkivet vi för närvarande befinner oss i. Lägg till en ny version (under den lokala ändringskommentaren) till det ursprungliga förvaret och kör kommandot Storage \ Synchronization \ Push. Arbetsbänkens gränssnitt låter dig välja endast de revisioner som behöver "pushas". Observera att en ny gren har skapats i fjärrvalvet för den resulterande revisionen.

...

Liknande dokument

Funktionerna hos versionskontrollsystemet - ett program utformat för att arbeta med att ändra dokument. Dess egenskaper och användningsmetoder. Intern lagringsenhet. Arbetskopia av versionerade dokument. Centraliserad och distribuerad hårdvaluta.

presentation tillagd 2014-05-01


Analys av metoder och verktyg för att kontrollera åtkomst till filer. Säkerhetsproblem med att arbeta med filer, verktyg för åtkomstkontroll. Ideologin för att bygga gränssnittet, krav på arkitektur. Systemets klassers arbete. Uppskattning av kostnaden för en mjukvaruprodukt.

avhandling, tillagd 2012-12-21


Analys av arkitekturen för Windows 8. Jämförelse med tidigare versioner (Modernt UI, arbete med konton, säkerhetsmodell, uppgiftshanterare, filhistorik, systemåterställning, Lagringsutrymmen). Funktioner av olika Windows-versioner 8.

terminsuppsats, tillagd 2016-01-25


Etapper av att utveckla ett automatiserat system för att ta emot och boka bordsbeställningar i anläggningar. Miljöanalys android utveckling Utvecklings verktyg. Allmänna egenskaper hos komponentdiagrammet IOS-applikationer... Hänsyn till serverns versionskontrollsystem.

Terminuppsats tillagd 2014-05-14


Grafiska gränssnitt och tillägg för DOS. Historien om utvecklingen av operativsystemet Microsoft Windows. Innovationerna i dess moderna versioner: användargränssnitt, språkintegration, säkerhetssystem. Kronologi för utveckling och arkitektur för GNU / Linux-systemet.

abstrakt, tillagt 2010-10-25


DirectX-utvecklingskit för Microsoft Windows, egenskaper hos uppsättningarna av COM-kompatibla objekt i dess sammansättning. Nyckelfunktioner i versioner, shader-språk. Beskrivning av de huvudsakliga funktioner som används. Källkoden för programmet, exempel på dess arbete.

Terminuppsats tillagd 2015-02-16


Windows som en mellanhand mellan användaren och operativsystemet, vilket underlättar kommunikationsprocessen mellan dem, historien om bildandet och utvecklingen av dess första versioner. Funktionella egenskaper och Windows skillnader 95/98 / ME och Windows NT / 2000 / XP / Vista / 7, deras arkitektoniska lösningar.

presentation tillagd 2013-10-23


Minska kostnaderna för reparationsarbeten för att eliminera defekter som uppstår när informationssystemet används för att kontrollera dem. Analys av ämnesområdet och mjukvara. Beräkna besparingar genom att öka användarens produktivitet.

avhandling, tillagd 2017-01-19


Koncept, essens, struktur och typer av operativsystem. Operationsrummets egenskaper Windows-system XP, krav för dess installation, jämförande analys av versioner, anpassningsfunktioner, versionsuppdateringar, installation av enhetsdrivrutiner och tillägg av nya.

abstrakt, tillagt 2009-10-20


Utseendet på de första versionerna av Windows, deras grafiska gränssnitt och tillägg för DOS. Windows 3.x och Windows 9.x familjer, deras funktioner och huvudfunktioner. Utvecklingen av Plug and Play-teknik. De viktigaste förbättringarna i moderna versioner av Windows.

Distribuerat versionskontrollsystem Git. Del 1

Introduktion

Innehållsserie:

1. Introduktion

När de arbetar med ett projekt stöter dess deltagare ofta på problem med synkronisering och filhistorik, vilket kan lösas med versionskontrollsystem (VCS). Syftet med denna artikelserie är att introducera läsaren till principerna för VCS och att titta närmare på en av dem, nämligen Git. Varför Git? Nyligen har detta system blivit populärt, och dess betydelse för fri programvara (och för GNU / Linux-projektet i synnerhet) kan knappast överskattas.

Vi kommer sekventiellt, i allmänna termer, att analysera egenskaperna hos styrsystem, prata om deras arkitektur och huvuddragen i applikationen i fråga. Dessutom kommer vi att ge en översikt över de för närvarande befintliga gränssnitten för att arbeta med Git.

Författaren utelämnar medvetet terminologin för funktioner, nycklar och andra subtiliteter för att tydligt, tydligt och allmänt presentera bilden för dig. Den här artikeln förutsätter att läsaren är bekant med Unix-liknande operativsystem (OS), och även har grundläggande kunskap inom området algoritmer och informatik i allmänhet.

I följande material kommer vi att fördjupa oss i Gits struktur och filosofi, detaljerna i detta system och finesserna i praktiskt arbete med det. Cykeln kommer att avslutas med en artikel om hur Git interagerar med andra VCS:er (som Subversion, CVS, Mercurial, etc.).

2. Git är...

Git är ett distribuerat filversionskontrollsystem. Programkoden skrivs huvudsakligen på språket C. Projektet skapades av Linus Torvalds 2005 för att hantera utvecklingen av Linuxkärnan och är liksom GNU/Linux fri programvara (mjukvara), medan tredje parts användning licensierad under GNU GPL version 2. Kortfattat kan detta avtal beskrivas som programvara med fri kod, som måste utvecklas öppet, d.v.s. alla programmerare har rätt att fortsätta att förbättra projektet i vilket skede som helst. Under dess korta existens introducerades detta system av många ledande utvecklare. Git används i projekt som är kända för Linux-gemenskapen som Gnome, GNU Core Utilities, VLC, Cairo, Perl, Chromium, Wine.

3. Versionskontrollsystem

Version Control Systems är en mjukvara utformad för att automatisera historiken för en fil (eller grupp av filer), övervaka ändringar, synkronisera data och organisera ett säkert projektförråd. Kortfattat är huvudsyftet med versionskontrollsystem att göra det lättare att arbeta med att ändra information. Låt oss ta en titt på den allmänna synen på utveckling med hjälp av ett exempel.

Anta att det finns ett projekt som du utvecklar, flera avdelningar av programmerare och du är koordinator (eller ledare). I förhållande till styrsystemet, om det är en server (när det gäller ett centraliserat system) eller lokal maskin, alla projektutvecklare begränsas endast av åtkomsträttigheterna att modifiera och/eller läsa versioner av filerna i detta arkiv. Du kan när som helst återställa data till den version du behöver. Du som samordnare kan begränsa åtkomsten till vissa användare för att uppdatera filversionen. VCS tillhandahåller också ett gränssnitt för att observera och söka efter filversioner. Du kan till exempel skapa en fråga: "Var och när ändrades denna kodbit?".

Systemet förutsätter säker lagring av data, d.v.s. alla block som lagras i det har många kloner. Så, till exempel, om en fil är skadad, kan du omedelbart ersätta den med en kopia. För att minska mängden projektdata används ofta deltakomprimering - en typ av lagring där inte själva filversionerna lagras, utan endast ändras mellan successiva revisioner.

4. Skillnader mellan distribuerade versionskontrollsystem

Distribuerade versionskontrollsystem är VCS, vars huvudparadigm är lokaliseringen av data från varje projektutvecklare. Med andra ord, om i en centraliserad VCS alla åtgärder, på ett eller annat sätt, beror på det centrala objektet (servern), så behåller varje utvecklare i en distribuerad VCS sin egen version av hela projektet. Bekvämligheten med ett sådant system är att varje utvecklare har möjlighet att arbeta självständigt, då och då utbyta mellanliggande versioner av filer med andra projektdeltagare. Låt oss överväga den här funktionen och fortsätta med föregående exempel.

Varje utvecklare på maskinen har sitt eget lokala arkiv - platsen där filversionerna lagras. Arbete med projektdata implementeras på ditt lokala arkiv, och för detta är det inte nödvändigt att hålla kontakt med resten (även de viktigaste) utvecklingsgrenarna. Kommunikation med andra arkiv behövs endast när du ändrar / läser versioner av filer från andra grenar. Samtidigt ställer varje projektdeltagare in läs- och skrivbehörigheter för sitt eget arkiv. Således är alla grenar i distribuerad VCS lika med varandra, och den huvudsakliga tilldelas av koordinatorn. Huvudgrenen skiljer sig bara i det faktum att utvecklarna mentalt kommer att vara lika med den.

5. Huvuddrag och funktioner hos Git

Det är värt att säga att systemet, om det inte gjorde ett stänk, rörde upp VMS-gemenskapen något med sin nyhet och erbjöd ett nytt sätt att utvecklas. Git tillhandahåller flexibla, lättanvända verktyg för att hålla projekthistorik.

Det speciella med Git är att arbetet med versionerna av projektet kanske inte sker i kronologisk ordning. Utveckling kan ske i flera parallella grenar, som kan slås samman och delas upp när som helst under designprocessen.

Git är ett ganska flexibelt system, och dess omfattning är inte bara begränsad till utvecklingssfären. Till exempel kan journalister, författare av teknisk litteratur, administratörer, universitetsprofessorer mycket väl använda det i sin typ av verksamhet. Dessa uppgifter inkluderar versionskontroll av all dokumentation, rapport, läxor.

Låt oss lyfta fram de viktigaste skillnaderna mellan Git och andra distribuerade och centraliserade VCS:er.

Git arkitektur

SHA1 (Secure Hash Algorithm 1) är en algoritm kryptografisk hashing... Varje fil i ditt Git-projekt består av ett namn och ett innehåll. Namnet är de första 20 byten med data, det är tydligt skrivet med fyrtio tecken in hexadecimalt system beräkning. Denna nyckel erhålls genom att hasha innehållet i filen. Så om vi till exempel jämför två namn kan vi med nästan hundra procents sannolikhet säga att de har samma innehåll. Namnen på identiska objekt i olika grenar (repositories) är också desamma, vilket gör att du direkt kan använda data. Ett bra tillägg till ovanstående är det faktum att hashen låter dig exakt bestämma skadorna på filer. Till exempel, genom att jämföra innehållets hash med namnet, kan vi ganska exakt avgöra om data är skadad eller inte. I det följande kommer vi att förstå namnet på filen som namnet, och teckensträngen kommer att kallas SHA1-hash.

Det är värt att nämna de så kallade kollisioner. "Det är ganska korrekt att fastställa skadan" betyder att det finns sådana filer med olika innehåll, vars SHA1-hash är densamma. Sannolikheten för sådana kollisioner är mycket liten, och enligt preliminära uppskattningar är den lika med 2 till -80:e potensen (~ 10 till -25:e potensen). Det finns ingen exakt bedömning, eftersom världssamfundet för närvarande inte har kunnat effektivt dekryptera detta kryptografiska system.

Git objekt

Att arbeta med filversioner i Git kan jämföras med rutinmässiga operationeröver filsystemet. Strukturen består av fyra typer av objekt: Blob, Tree, Commit och References; några av dem är i sin tur indelade i delobjekt.

Blob (Binary Large Object) är en datatyp som endast innehåller innehållet i en fil och sin egen SHA1-hash. Blob är det huvudsakliga och enda lagringsmediet i Git-strukturen. En parallell kan dras mellan detta objekt och inoder i filsystem, eftersom deras struktur och syfte är mycket lika.

Träd

• egen SHA1-hash;
• SHA1 hash av blobbar och/eller träd;
• åtkomsträttigheter för Unix-system;
• symboliskt namn på objektet (namn för internt bruk i systemet).

I huvudsak är ett objekt analogt med en katalog. Den definierar hierarkin för projektfilerna.

Begå- datatyp som innehåller:

• egen SHA1-hash;
• en länk till exakt ett träd;
• en länk till föregående commit (det kan finnas flera av dem);
• namnet på författaren och tidpunkten när commit skapades;
• namnet på committen (commiter är den person som tillämpade commit på arkivet, det kan skilja sig från författaren) och tidpunkten när commit tillämpades;
• en godtycklig databit (blocket kan användas för en elektronisk signatur eller till exempel för att förklara ändringar i en commit).

Detta objekt är utformat för att lagra en ögonblicksbild (version) av en grupp filer vid en viss tidpunkt, du kan jämföra den med en kontrollpunkt. Commit's kan slås samman, förgrenas eller till exempel sättas i en linjär struktur, och reflekterar därigenom projektets versionshierarki.

Referens är en datatyp som innehåller en referens till något av de fyra objekten (Blob, Tree, Commit och References). Dess huvudsakliga syfte är att peka direkt eller indirekt på ett objekt och vara en synonym för filen det refererar till. Detta ökar förståelsen för projektstrukturen. Det är väldigt obekvämt att arbeta med en meningslös uppsättning tecken i namnet, länken, i motsats till SHA1-hash, kan namnges eftersom det är bekvämare för utvecklaren.

Från länkarna kan i sin tur urskiljas ett antal delobjekt som har vissa skillnader: Branch, Tag. Låt oss överväga dem.

Filial (huvud, filial)- en symbolisk länk (Symbolisk länk), som pekar på den sista commit i kronologin för en viss gren och lagrar SHA1-hash för objektet. Det är en datatyp för journalföring av filsystem. Den här typen av objekt definieras inte i själva Git, utan ärvs från operativsystemet och filsystemen. En gren används synonymt med filen den refererar till, d.v.s. Git låter dig manipulera det direkt. Du har råd att inte tänka på om du arbetar med den senaste versionen eller inte.

Märka- en datatyp som, till skillnad från grenar, alltid refererar till samma objekt av typen blob, träd, commit eller tagg. Den kan i sin tur delas in i lätt (lätt tag) och tung eller kommenterad (kommentarerad tagg). En lätt tagg, förutom länkens oföränderlighet, skiljer sig inte från vanliga grenar, d.v.s. innehåller endast SHA1-hash för det refererade objektet i sig själv. En kommenterad tagg har två delar:

• den första delen innehåller sin egen SHA1-hash;
• den andra delen består av:
  • SHA1 för objektet som den kommenterade taggen pekar på;
  • typen av det refererade objektet (blob, träd, commit eller tagg);
  • det symboliska namnet på taggen;
  • datum och tid när taggen skapades;
  • namn och e-postadress för skaparen av taggen;
  • en godtycklig bit data (detta block kan användas för en elektronisk signatur eller för att förklara en tagg).

Med andra ord är ett Git-projekt en samling blobbar som är sammanlänkade av ett nätverk av träd. Den resulterande hierarkiska strukturen kan, beroende på tid, reflekteras i form av commit's - versioner, och för att förstå deras struktur i Git finns det objekt såsom länkar. Exklusive åtgärder med länkar, är nästan allt arbete med systemobjekt automatiserat så mycket som möjligt från insidan. Med utgångspunkt från länkmekanismen kommer vi till nästa idé - att arbeta med grupper av filer. Enligt författaren är tanken central i Gits filosofi. Genom att till exempel ställa in en operation för en given commit, kommer den att utföra sin del rekursivt längs trädet den refererar till. Som en förlängning av den allmänt accepterade synen att "agera på varje fil", förenklar innovationen implementeringen och tillvägagångssättet från programmerarens sida över dagliga VCS-uppgifter som att slå samman / dela grenar, vilket återigen automatiserar processen rekursivt. Detta tillvägagångssätt är lätt att förstå, snabbt och flexibelt för att uppnå sina mål. Många av dessa funktioner uppnås på grund av systemets Unix-centricitet, dvs. fungerar standardenheter, Git bygger på de som redan finns tillgängliga i operativ system lösningar.

Låt oss förtydliga punkten för datalagring. Innehållet i filer av olika versioner i kronologin tar upp ganska mycket minne. Så, till exempel, i ett projekt med tjugo filer med tjugo versioner, kommer arkivet att väga 20 gånger mer (kanske ungefär hundra megabyte), men vad händer om antalet av båda är 10 gånger mer (till synes inte mycket)? Storleken på det använda utrymmet kommer att öka med 100 gånger (dvs cirka 1 GB). I verkliga problem är tillväxthastigheten för det ockuperade minnet långt ifrån linjärt beroende av tid. Det finns flera optimeringar för att lösa detta problem:

• varje Git-objekt lagras som ett vanligt arkiv (tar.gz);
• sekventiell deltakomprimering tillämpas på hela filhierarkin.

Låt oss ta ett exempel.

Du har en treårig historia av ditt projekt, det innehåller cirka tusen filer och hundra versioner. Om du någon gång behöver gå till den tidigaste versionen måste Git packa upp deltakompressionen av hela filens historik. En besvikelse kan den här processen ta upp till kl. Git föreslår att man gör så kallade brytpunkter, d.v.s. lagra en veckoarkiverad fil efter ett visst antal versioner, vilket vi kommer att kalla komprimeringsdjupet. Sedan, i vårt exempel, begränsas hela historien till ett visst förutbestämt antal deltakompressioner, efter att ha packat upp dem kan du titta på vilken version som helst i kronologin. Observera att deltakomprimering är mest ändamålsenligt att använda över vissa typer av objekt närmast i hierarkin; för detta måste förvaret sorteras efter typ och storlek. Denna serie av operationer som beskrivs i det här avsnittet utförs av git-repack-funktionen (och git-gc som innehåller den).

Sammanfoga och dela grenar

Denna fråga är mycket mödosam och mättad, i samband med vilken vi kommer att introducera begreppen fusion och separation endast i allmänna termer. Låt oss titta på ett exempel igen.

Föreställ dig ögonblicket för projektutveckling, när huvudmålet är programmets hastighet. En av de möjliga taktiska lösningarna är att dela upp utvecklarna i två grupper som var och en löser samma problem. I det här fallet bör grenen av projektets historia delas upp. Denna procedur kallas förgrening. Åtgärden att förgrena en gren är en enkel skapelse av en kopia av den, som sedan kommer att ha sin egen historia.

Anta att vi fick två redan slutförda resultat av samma uppgift, som två grupper av programmerare arbetade med. Hur ska vi vara? Se vilken kod som är snabbare och mer pålitlig? Det är för enkelt, men inte alltid den bästa lösningen. En bra lösning är, efter att ha grävt lite i koden och filerna, dela upp dem i deluppgifter eller kodblock. Och först då kan vi identifiera styrkorna och svagheterna hos dessa bitar. Naturligtvis är det här alternativet endast lämpligt om du i förväg har förutsett att du senare kan samla alla dessa partiklar tillsammans. Fallet när du själv utvecklar koden, förbättrar och fixar några buggar, motsvarar exemplet som ges. Denna process att slå samman två heltal till ett kallas sammanfogning. Processen att kombinera de två versionerna är nyckelpunkten i projektet. Hur som helst, det är värt att undvika den automatiska exekveringen av denna operation. Utmärkande drag Git är den mest pålitliga och vackraste snabbt sätt lösa förgreningsproblemet.

Fördelarna med systemet inkluderar:

1. Unix-orienterad.
2. Ideologisk konsekvens (om man följer reglerna för att använda systemet är det mycket svårt att hamna i en hopplös situation eller få något som man inte förväntade sig).
3. Hög prestanda (detta är en av de mest uppenbara fördelarna med systemet, vars pris är "Ideologisk konsistens" och "Unix-orientering").
4. Integrering av Git med tredjeparts VCS som Subversion, Mercurial, ...
5. Hantera en grupp av filer (systemet behöver inte överväga ändringar i varje fil separat, det kommer ihåg alla ändringar i hela projektet, och om du plötsligt behöver spåra enstaka ändringar kommer det att ge ut exakt den del som är associerad med detta fil).
6. Merge operation (den mest automatiserade implementeringen av en komplex uppgift).

Nackdelarna inkluderar:

1. Unix-orienterad (det är värt att notera bristen på en mogen implementering av Git på icke-Unix-system).
2. Behovet av att regelbundet köra git-gc-kommandot (packar grupper av filer och tar bort de som inte är länkade av länkar).
3. Hashkollisioner (SHA1-hashmatchningar av filer med olika innehåll).

6. Git-gränssnitt

"Hur många människor, så många åsikter." Låt oss försöka lyfta fram ett antal typer av gränssnitt för att arbeta med systemet. För vissa ändamål är var och en av följande typer av applikationer bättre på sitt sätt.

För människor som inte är inblandade i utvecklingen nära, för "konservativa" - de som älskar "knappar och bockar" och medvetet vill skydda sig från de orimliga ansträngningarna att memorera funktioner, nycklar och många finesser, ett alternativ i stil med TortoiseGit eller Git Extensions är mer lämpligt - enkla gränssnitt. De låter dig arbeta i första hand med en mus och arbeta i det vanliga Windows OS.

Exakt den motsatta typen av gränssnitt. För programmerare som ständigt behöver interagera med anställda, för att lösa typiska uppgifter för att kontrollera koden, för personer som är vana vid att arbeta i Unix-liknande system som använder terminalen, är konsolvyn av applikationer bäst lämpad. De är lika lätta att använda, lite snabbare och mer funktionella, men de kommer att få ta tid att komma på hur de ska användas.

En tredje typ av gränssnitt kan också urskiljas - att blanda de två första. De där. du har en konsolapplikation som det ursprungliga git-skalet. Du kan använda ett antal ytterligare verktyg, som Gitk eller QGit, för att visa träd, göra det lättare att bläddra i versionshierarkin, skilja mellan versioner och hitta de objekt du vill ha.