Grundlæggende om VCS

Introduktion

Før du taler om et specifikt versionskontrolsystem, skal du forstå, hvad det er, hvad de er, og hvorfor de dukkede op i første omgang. Dette foredrag har til formål at give en indledende introduktion til versionskontrol og versionskontrolsystemer, og først vil jeg tale om oprindelsen af ​​versionskontrolværktøjer, hvilke versionskontrolsystemer der er populære i øjeblikket, og hvad de vigtigste forskelle er mellem dem.

Om versionskontrol

Hvad er versionskontrol, og hvorfor har du brug for det?

Det er nok værd at starte med definitionen af ​​et versionskontrolsystem (VCS) – dette er et system, der registrerer ændringer i en eller flere filer, så det i fremtiden er muligt at vende tilbage til visse gamle versioner af disse filer.

På det seneste er filer slutresultatet for mange erhverv (for eksempel skrivning, videnskabeligt arbejde og selvfølgelig softwareudvikling). Der bruges meget tid og kræfter på at udvikle og vedligeholde disse filer, og ingen ønsker at skulle bruge endnu mere tid og kræfter på at gendanne data, der er tabt som følge af ændringer.

Lad os forestille os, at en programmør udvikler et projekt, der består af en lille fil (eksemplet er i øvrigt ret virkeligt, ikke syntetisk og er blevet stødt på i det virkelige liv). Efter at have frigivet den første version af projektet, står han over for et vanskeligt valg: det er nødvendigt at løse de problemer, der er rapporteret af brugere af den første version og samtidig udvikle noget nyt til den anden. Selvom du blot skal løse problemer, der opstår, er der stor sandsynlighed for, at projektet efter nogle ændringer holder op med at fungere, og du skal finde ud af, hvad der er ændret for at gøre det lettere at lokalisere problemet. Det er også tilrådeligt at føre en form for log over ændringer og rettelser, der er foretaget, for ikke at udføre det samme arbejde flere gange.

I det enkleste tilfælde kan ovenstående problem løses ved at gemme flere kopier af filerne, for eksempel en til at rette fejl i den første version af projektet og en anden til nye ændringer. Da ændringerne normalt ikke er særlig store i forhold til filstørrelsen, er det muligt kun at gemme de ændrede linjer ved hjælp af diff-værktøjet og senere flette dem ved hjælp af patch-værktøjet. Men hvad nu hvis projektet består af flere tusinde filer og hundrede mennesker arbejder på det? Hvis vi i dette tilfælde bruger metoden med opbevaring separate kopier filer (eller endda bare ændringer), så vil projektet gå i stå meget hurtigt. I de efterfølgende forelæsninger vil jeg bruge programmets kildekoder til eksempler, men faktisk kan næsten enhver filtype lægges under versionskontrol.

Hvis du er grafiker eller webdesigner og gerne vil gemme alle versioner af et billede eller layout - og det ville du sandsynligvis - så er det en meget klog beslutning at bruge et versionskontrolsystem. VCS gør det muligt at returnere individuelle filer til deres tidligere form, returnere hele projektet til dets tidligere tilstand, se ændringer, der er sket over tid, afgøre, hvem der var den sidste til at foretage ændringer til et modul, der pludselig holdt op med at fungere, hvem og hvornår der blev introduceret en slags fejl i koden og meget mere. Generelt, hvis du, mens du bruger VCS, ødelægger alt eller mister filer, kan alt nemt gendannes. Plus, overhead for alt, hvad du får, vil være meget lille.

Lokale versionskontrolsystemer

Som nævnt tidligere er et eksempel på en lokal SUV ekstremt simpelt: mange mennesker foretrækker at kontrollere versioner ved blot at kopiere filer til en anden mappe (normalt tilføjer nuværende dato til katalognavnet). Denne tilgang er meget almindelig, fordi den er enkel, men den fejler også oftere. Det er meget nemt at glemme, at du er i den forkerte mappe og ved et uheld ændrer den forkerte fil, eller kopierer filer til det forkerte sted og overskriver de filer, du har brug for. For at løse dette problem har programmører længe udviklet lokal VCS med en simpel database, der gemmer alle ændringer til de nødvendige filer

En af de mest populære VCS'er af denne type er RCS (Revision Control System), som stadig er installeret på mange computere. Selv på en moderne operationsstue Mac system OS X rcs-værktøjet er installeret sammen med udviklerværktøjer. RCS blev udviklet i begyndelsen af ​​1980'erne af Walter F. Tichy. Systemet giver dig mulighed for at gemme versioner af kun én fil, så du skal håndtere flere filer manuelt. For hver fil under systemets kontrol gemmes versionsoplysningerne i en speciel fil med navnet på den originale fil, hvortil tegnene ",v" tilføjes til sidst. For eksempel for filen file.txt vil versionerne blive gemt i filen file.txt,v. Dette værktøj er baseret på at arbejde med sæt patches mellem par af versioner (en patch er en fil, der beskriver forskellen mellem filerne). Dette giver dig mulighed for at genskabe enhver fil på et hvilket som helst tidspunkt og anvende patches sekventielt. Systemet bruger diff-værktøjet til at gemme versioner. Selvom RCS opfylder minimumskravene til et versionskontrolsystem, har det følgende hovedulemper, som også tjente som drivkraften til oprettelsen af ​​følgende system under overvejelse:

• Arbejd med kun én fil, hver fil skal styres separat;
• En ubekvem mekanisme for flere brugere til at arbejde samtidigt med systemet, lageret er simpelthen blokeret, indtil brugeren, der blokerede det, låser det op;
• Ingen befrier dig fra sikkerhedskopier; du risikerer at miste alt.

Centraliserede versionskontrolsystemer

Den næste store udfordring var behovet for at samarbejde med udviklere på andre computere. For at løse dette blev der skabt centraliserede versionskontrolsystemer (CVCS). Sådanne systemer, såsom CVS, Subversion og Perforce, har en central server, der gemmer alle filer under versionskontrol, og et antal klienter, der modtager kopier af filerne fra den. Dette har været standarden for versionskontrolsystemer i mange år.

Denne tilgang har mange fordele, især i forhold til lokal SLE. For eksempel ved alle, hvem der laver hvad i projektet. Administratorer har klar kontrol over, hvem der kan gøre hvad, og selvfølgelig er CSKB meget nemmere at administrere end lokale databaser på hver klient. Der er dog flere alvorlige ulemper ved denne tilgang. Den mest åbenlyse er, at den centraliserede server er det svage punkt i hele systemet. Hvis serveren går ned i en time, kan udviklere ikke interagere i en time, og ingen kan gemme en ny version af deres arbejde. Hvis disken med den centrale database er beskadiget, og der ikke er nogen sikkerhedskopi, mister du absolut alt - hele projektets historie, med mulig undtagelse af flere arbejdsversioner gemt på brugernes arbejdsmaskiner.

CVS

CVS (Concurrent Versions System) er stadig det mest udbredte system, men mister hurtigt sin popularitet på grund af mangler, som jeg vil diskutere nedenfor. Dick Grune udviklede CVS i midten af ​​1980'erne. For at gemme individuelle filer bruger CVS (såvel som RCS) filer i RCS-formatet, men giver dig mulighed for at administrere grupper af filer, der er placeret i mapper. CVS bruger også en klient-server-arkitektur, hvor al versionsinformation er gemt på serveren. Ved at bruge en klient-server-arkitektur kan CVS bruges selv af geografisk distribuerede teams af brugere, hvor hver bruger har deres egen arbejdsmappe med en kopi af projektet. Som navnet antyder, kan brugere dele systemet.

Mulige konflikter ved ændring af samme fil løses ved, at systemet kun tillader ændringer til de fleste nyeste version fil. Derfor anbefales det altid at opdatere din arbejdskopi af filerne, før du uploader dine ændringer i tilfælde af mulige modstridende ændringer. Ved opdatering foretager systemet automatisk ændringer i arbejdskopien og kun i tilfælde af modstridende ændringer i en af ​​filplaceringerne kræves manuel rettelse af konfliktplaceringen.

CVS giver dig også mulighed for at opretholde flere udviklingslinjer på et projekt ved hjælp af udviklingsgrene. Som nævnt ovenfor kan du således rette fejl i den første version af projektet og samtidig udvikle ny funktionalitet.

CVS blev brugt stort beløb projekter, men det var selvfølgelig ikke uden sine mangler, hvilket senere førte til fremkomsten af ​​det næste system, der overvejes. Lad os se på de vigtigste ulemper:

• Da versioner er gemt i RCS-filer, er det ikke muligt at gemme mappeversioner. Standard metode at komme uden om denne forhindring er at gemme en fil (for eksempel README.txt) i en mappe;
• Flytning eller omdøbning af filer er ikke underlagt versionskontrol. Standardmåden at gøre dette på er først at kopiere filen, fjerne den gamle ved hjælp af cvs remove-kommandoen og derefter tilføje den med sit nye navn ved hjælp af cvs add-kommandoen;

Subversion

Subversion (SVN) blev udviklet i 2000 på initiativ af CollabNet. SVN blev oprindeligt udviklet som et "bedre CVS", og udviklernes hovedmål var at rette fejl i CVS-designet og samtidig bevare en lignende grænseflade. SVN bruger ligesom CVS en klient-server-arkitektur. De mest markante ændringer sammenlignet med CVS omfatter:

• Atomændringer (commit). Hvis commit-behandlingen afbrydes, vil der ikke blive foretaget ændringer.
• Omdøbning, kopiering og flytning af filer bevarer hele historikken for ændringer.
• Mapper, symbolske links og metadata er underlagt versionskontrol.
• Effektiv ændringslagring til binære filer.

Distribuerede versionskontrolsystemer

Og i denne situation kommer distribuerede versionskontrolsystemer (DVCS) i spil. I systemer som Git, Mercurial, Bazaar eller Darcs tjekker klienter ikke blot de seneste versioner af filer, men kopierer hele lageret. Derfor, i tilfælde af at serveren, som arbejdet gik igennem, "dør", kan ethvert klientlager kopieres tilbage til serveren for at gendanne databasen. Hver gang en klient henter en ny version af filer, opretter han til sig selv fuld kopi alle data.

Derudover giver de fleste af disse systemer dig mulighed for at arbejde med flere fjerndepoter, så du kan arbejde forskelligt med forskellige grupper af mennesker på det samme projekt på samme tid. Således kan du i ét projekt udføre flere typer arbejdsprocesser samtidigt, hvilket er umuligt i centraliserede systemer.

Hvorfor er der behov for distribuerede systemer?

Som navnet antyder, er en af ​​hovedideerne ved distribuerede systemer fraværet af et klart udpeget centralt versionslager - et lager. I tilfælde af distribuerede systemer kan et sæt versioner distribueres helt eller delvist mellem forskellige lagre, inklusive fjerntliggende. Denne model passer perfekt ind i arbejdet i distribuerede teams, for eksempel et team af udviklere fordelt rundt om i verden, der arbejder på det samme open source-projekt. Udvikleren af ​​et sådant team kan downloade alle versionsoplysningerne og derefter kun arbejde på den lokale maskine. Så snart resultatet af et af arbejdsstadierne er opnået, kan ændringerne uploades til et af de centrale depoter eller publiceres til visning på udviklerens websted eller i mailinglisten. Andre projektdeltagere vil til gengæld være i stand til at opdatere deres kopi af versionslagret med nye ændringer eller prøve de offentliggjorte ændringer på en separat testudviklingsgren. Desværre, uden en god projektorganisation, kan manglen på ét centralt lager være en ulempe ved distribuerede systemer. Hvis der i tilfælde af centraliserede systemer altid er ét fælles lager, hvorfra du kan hente den seneste version af projektet, så skal du i tilfælde af distribuerede systemer organisatorisk beslutte, hvilken af ​​projektgrenene der skal være den vigtigste. Hvorfor ville et distribueret versionskontrolsystem være interessant for en person, der allerede bruger et centraliseret system - såsom Subversion? Ethvert job involverer at træffe beslutninger, og i de fleste tilfælde er det nødvendigt at prøve forskellige muligheder: når man arbejder med versionskontrolsystemer, skal man overveje forskellige muligheder og arbejder med store forandringer er udviklingsgrene. Selvom dette er et ret naturligt koncept, er det ikke nemt at bruge i Subversion. Desuden bliver alt mere kompliceret i tilfælde af flere sekventielle fusioner fra en gren til en anden - i dette tilfælde skal du præcist angive de indledende og endelige versioner af hver ændring for at undgå konflikter og fejl. For distribuerede versionskontrolsystemer er udviklingsgrene et af de grundlæggende koncepter - i de fleste tilfælde er hver kopi af et versionslager en udviklingsgren. Således er mekanismen til at flette ændringer fra en gren til en anden i tilfælde af distribuerede systemer en af ​​de vigtigste, hvilket giver brugerne mulighed for at lægge mindre indsats, når de bruger systemet.

Kort beskrivelse af populære distribuerede SUV'er

• Git er et distribueret versionskontrolsystem udviklet af Linus Torvalds. Git var oprindeligt beregnet til brug i udviklingsprocessen Linux kerner, men begyndte senere at blive brugt i mange andre projekter - som for eksempel X.org og Ruby on Rails, Drupal. På dette øjeblik Git er det hurtigst distribuerede system, der bruger den mest kompakte revisionsbutik. Men samtidig, for brugere, der migrerer, for eksempel fra Subversion, kan Git-grænsefladen virke kompliceret;
• Mercurial er et distribueret system skrevet i Python sprog med flere udvidelser i C. Projekter, der bruger Mercurial, omfatter Mozilla og MoinMoin.
• Bazaar er et system udviklet af Canonical, kendt for sin Ubuntu-distribution og hjemmeside https://launchpad.net/. Systemet er hovedsageligt skrevet i Python og bruges af projekter som MySQL.
• Codeville er et distribueret system skrevet i Python, der bruger en innovativ algoritme til at kombinere ændringer (fletning). Systemet bruges for eksempel i udviklingen af ​​den originale BitTorrent-klient.
• Darcs er et distribueret versionskontrolsystem skrevet i Haskell, som f.eks. bruges af Buildbot-projektet.
• Monotone er et system skrevet i C++ og bruger SQLite som revisionslagring.

Har du en god ny forretningsidé relateret til softwareudvikling?Du skal udvikle dig teknologisk svær beslutning? Eller har du et stort team af programmører, der arbejder med den samme opgave? Husk så disse tre ord:versionskontrolsystem .

Versionskontrolsystem (cvs), 2017 - Sammenlign: Git, SVN, Mercurial

, eller vcs- det er det, der forhindrer et projekt i at falde fra hinanden, når der er mange mennesker, der arbejder på det. Programmører, ledere, tekstforfattere kan hver arbejde på deres eget stykke uden at forstyrre hinanden og uden at forårsage skader, der ikke kunne rettes.

Hvis du endnu ikke er bekendt med konceptetversionskontrolsystemer, så her alt er meget tydeligt vist.

Eller se videoen fra GitHub.

Så hvilket versionskontrolsystem passer til dit projekt?

Vi sammenlignede flere populære løsninger for at gøre det nemmere for dig at træffe et valg.

Dette er et højt specialiseret teknisk emne. Vi har forsøgt at gøre vores anmeldelse forståelig for alle. Men hvis du ikke har programmeringserfaring, skal du sørge for at rådføre dig med din udviklingsafdeling, før du træffer beslutninger.

Versionskontrolsystemer, inklusive det velkendte SVN (Subversion) og Git, blev oprindeligt skabt for at give teams af udviklere mulighed for at arbejde på samarbejdsprojekter uden at skabe forvirring. I kontrolsystemet behøver du ikke selvstændigt at spore kodegrene og studere noterne til dem. I stedet bruges et centralt depot, hvor alt er organiseret og struktureret. Det er praktisk at opdatere filer, tilføje kommentarer og endda flette projektgrene.

Meninger om hvadversionskontrolsystemden bedste varierer meget, og det fører til heftig debat blandt programmører. At udvælge og studereversionskontrolsystemerfor dit projekt skal du huske, at fordelene ved en bestemt løsning ofte er subjektive. For eksempel programmørens personlige præferencer eller f.eks. indikatorer som ydeevne, muligheder for IDE-plugins osv.

Den største forskel mellem versionskontrolsystemer er, om de er klient-server eller decentraliserede (p2p). Har de et centralt lager (server), hvor koden er taget fra og hvor den returneres med ændringer. Eller det er en kopi i lokalt lager, opdateret gennem peers: et mere decentraliseret netværk, der bruges til synkronisering, deling af patches (ændre sæt) og vedligeholdelse af kørende kode.

Det er også værd at tage højde for hastigheden, funktionaliteten og tærsklen for adgang/beherskelse af en specifikkontrolsystemer. Lad os se på de mest almindeligeversionskontrolsystemerog grundene til, at programmører foretrækker bestemte løsninger.

Simultan version system (CVS)

CVS dukkede op i 1980'erne og er stadig populær blandt både kommercielle produktudviklere og open source-udviklere.

CVS fordelt på vilkåreneGNU Open License Agreement og giver dig mulighed for at få den ønskede version af projektet fra serveren - "check-out" (udtræk) , og send det derefter tilbage til serveren, "check-in" (retur),med de foretagne ændringer.

Oprindeligt CVS blev oprettet for at undgå versionskonflikter. Alle deltagere fik kun den nyeste version af koden at arbejde med. Dette var det første versionskontrolsystem. Brugeren skulle hurtigt foretage ændringer til depotet, før andre slog ham til det.

Nu CVS har support til at arbejde på projekter med kodegrene. Dette resulterer i flere produktmuligheder med forskellige egenskaber, som senere kan kombineres.

CVS servere kører normalt under Unix, men CVS -klienter er også tilgængelige i andre populære operativsystemer. CVS - "moden", tidstestetversionskontrolsystem. Det er stadig et open source-system, men i dag tilføjes nye funktioner ret sjældent.

Samtidig er CVSNT en version adskilt i et separat projekt CVS Til Windows-servere, - udvider nu ganske aktivt sin funktionalitet.

Fordele:

• Tidsprøvet teknologi, der har været på markedet i årtier.

Fejl:

• Omdøbning eller flytning af filer afspejles ikke i historikken
• Sikkerhedsrisici forbundet med symbolske links til filer
• Ingen støtte til atomoperationer, hvilket kan føre til kodekorruption
• Operationer med programkodegrene er dyre, da dettekontrolsystemikke beregnet til langsigtede projekter med kodegrene

Apache Subversion (SVN)

SVN blev skabt som et alternativ CVS for at rette op på mangler CVS og samtidig sikre høj kompatibilitet med det.

Ligesom CVS SVN er et gratis system versionskontrol åben kildekode. Den eneste forskel er, at den distribueres under Apache-licensen og ikke underÅben licensaftale GNU.

For at bevare databasens integritet bruger SVN såkaldte atomoperationer. Når en ny version frigives, anvendes enten alle eller ingen af ​​rettelserne på det endelige produkt. Dermed er koden beskyttet mod kaotiske delvise redigeringer, der er inkonsistente med hinanden og forårsager fejl.

Mange udviklere har skiftet tilSVN, da den nye teknologi arver bedre funktioner CVS og udvidede dem samtidig.

Mens han var på CVS operationer med kodegrene er dyre og leveres ikke af systemarkitekturen; SVN blev oprettet netop til dette. Altså til større projekter med kodeforgrening og mange udviklingsområder.

Ulemperne ved SVN inkluderer forholdsvis langsom hastighed og mangel på distribueret versionskontrol. Distribueret versionskontrol bruger en peer-to-peer-model i stedet for en centraliseret server til at gemme softwarekodeopdateringer. Og selvom peer-to-peer-modellen fungerer bedre i open source-projekter, er den ikke ideel i andre tilfælde. Ulempen ved server-side tilgangen er, at når serveren går ned, har klienter ikke adgang til koden.

Fordele:

• System baseret CVS
• Tillader atomoperationer
• Kodeforgreningsoperationer er billigere
• Bredt udvalg af IDE-plugins
• Bruger ikke en peer-to-peer-model

Fejl:

• Fejlene fortsætter stadig relateret til omdøbning af filer og mapper
• Utilfredsstillende sæt af kommandoer til at arbejde med lageret
• Relativ lav hastighed

Git

Dette system blev skabt til at styre Linux-kerneudvikling og bruger en tilgang, der er helt anderledes end CVS og SVN.

Grundlaget Git koncepter blev fastlagt for at skabe hurtigere distribueretversionskontrolsystem, i modsætning til de regler og løsninger, der bruges i CVS . Da Git primært blev udviklet til Linux, kører det hurtigst på dette OS.

Git kører også på Unix-lignende systemer (som MacOS), og mSysGit-pakken bruges til at køre på Windows-platformen.

Programkoden er muligvis ikke tilgængelig, når du bruger en computer uden et lager. Der er løsninger på dette problem, og nogle udviklere mener, at Gits hastighed er en rimelig pris at betale for ulejligheden.

Git har også mange værktøjer til at navigere i din ændringshistorik. Hver arbejdskopi af kildekoden indeholder hele udviklingshistorikken, hvilket er yderst nyttigt ved programmering uden internetforbindelse.

Fordele:

• Fantastisk til dem, der hader CVS/SVN
• Betydelig stigning i ydeevnen
• Billig drift med kodegrene
• Fuld udviklingshistorik tilgængelig offline
• Distribueret peer-to-peer model

Fejl:

• Høj adgangsbarriere (læring) for dem, der tidligere har brugt SVN
• Begrænset understøttelse af Windows (sammenlignet med Linux)

Mercurial

Mercurial blev udgivet samtidig med Git. det er det samme fordelt versionskontrolsystem.

Mercurial blev skabt som et alternativ til Git til udvikling af Linux-kernemoduler. Men da vi valgte Git, bruges Mercurial mindre. Men mange førende udviklere arbejder f.eks. med dette systemOpenOffice.org .

Mercurials versionskontrolsystem er anderledes end andreversionskontrolsystemerfordi det hovedsageligt er skrevet i Python (ikke C). Nogle dele er dog implementeret som udvidelsesmoduler i C.

Da systemet er decentraliseret og skrevet i Python, er mange Python-programmører tilbøjelige til at skifte til Mercurial.

Brugere bemærker, at Mercurial bevarer nogle af SVN's egenskaber, mens det er et distribueret system, og på grund af denne lighed har det en lavere adgangsbarriere for dem, der allerede er bekendt med SVN. Mercurials dokumentation er også mere komplet, hvilket hjælper dig til hurtigere at vænne dig til forskellene.

En af væsentlige mangler Mercurial er, at den i modsætning til Git ikke kan flette to overordnede grene, da Mercurial bruger et plugin-system i stedet for script-understøttelse. Dette er fantastisk for nogle programmører, men mange ønsker ikke at opgive Git's kraft.

Fordele:

• Lettere at lære sammenlignet med Git
• Detaljeret dokumentation
• Distribueret modelversionskontrolsystemer

Fejl:

• Der er ingen mulighed for at flette to overordnede grene
• Brug af plugins i stedet for scripts
• Færre muligheder for ikke-standardiserede løsninger

Hvilkenversionskontrol virker for mig?

I de fleste tilfælde bruger udviklere CVS fordi det er mere velkendt for dem. Hvis et team allerede arbejder på et projekt, så er udsigten til at overføre alle udviklinger til et andetkontrolsystempå en eller anden måde ikke inspirerende. Hvis de skulle ændre systemet, ville de højst sandsynligt skifte til SVN.

CVS har allerede nået status som en "moden teknologi", hvilket betyder, at radikalt nye funktioner og løsninger ikke længere vil dukke op i den. Vanens momentum går tabt, når folk flytter til SVN. Det betyder, at CVS efterhånden er ved at være fortid.

I dag har SVN håndfladen blandt serverservereversionskontrolsystemer. Det inkluderer fordele CVS og overgår dem. Hvis vi taler om prævalens, så vil du højst sandsynligt støde på oftere CVS eller SVN end med Git eller Mercurial. Så kendskab til én server-teknologi, selvom det ikke er afgørende, vil lette din overgang.

Tak til udbredt brug og teknologiens modenhed har SVN en stor videnbase, hvilket gør det nemt for brugerne at få hjælp.

Git er klart hurtigere end sine konkurrenter. For projekter, der er skabt til distribueretversionskontrolsystemer, dette er en åbenlys forbedring.

En væsentlig ulempe ved Git er, at det nogle gange er svært at forklare nuancerne i, hvordan det fungerer.kontrolsystemer, og dette sænker arbejdsgangen, mens programmører vænner sig til det. Men når først "indgangstærsklen" er overstået, øges produktiviteten, og bekvemmeligheden ved at administrere kodegrene vil fuldt ud tilbagebetale den brugte tid.

For dem, der hader Git (og det har sine modstandere blandt udviklere), er Mercurial et kompromis mellem SVN og Git. Dette system bruges i mange kendte projekter og har også god dokumentation.

Den Windows-kompatible version af Git udvikler sig også mod Linux-versionens hastighed, så den kan være relevant for dig, selvom du ikke udvikler på Linux.

For at forstå, hvilken der er bedst for dig, skal du tage højde for projektets og dit teams egenskaber. Tal med udviklerne!

Hvis et projekt kræver et enkelt kildekodetræ, som vil blive arbejdet på af en lille gruppe programmører, så er SVN din mulighed. Den er pålidelig og designet netop til sådanne tilfælde.

Hvis du lancerer et open source-projekt, hvor flere programmører vil arbejde på forskellige tidspunkter, eller hvis det forventes konstant opdatering kode, og vælg derefter Git. Styringen af ​​hastigheden og kildetræet er meget bedre her end i SVN.

Hvis du står ved en skillevej eller bare ikke kan lide måden SVN eller Git fungerer på, så er Mercurial noget for dig.

Alle disse systemer er fuldt funktionsdygtige. Og også gratis. De bruges til at skabe software, websteder og endda operativsystemer, som du bruger og kender.

Først og fremmest skal du beslutte, om det ene eller det andet er egnetkontrolsystemversioner til din virksomhed, og så - lige så vigtigt - sørg for, at dette valg ikke vil irritere programmører.

Kom godt i gang med SVN

Hvis du aldrig har arbejdet med SVN eller Git og ikke aner, hvordan du kommer i gang, såhostingløsning kombineret med GUIvil hjælpe dig med at vænne dig til det hurtigt.

Som i de fleste tilfælde er det vigtigste at begynde at arbejde, og så vil forståelsen komme. Betjening af et versionskontrolsystem ligner meget at arbejde med filer på en server ved hjælp af en FTP-klient.

BEMÆRK:Der er mange hostingløsninger tilversionskontrolsystemer, inklusive en gratis prøveperiode. Du kan oprette dit første depot (et sted at samarbejde med kodefiler) på deres basis gratis. Her er nogle af disse tjenester:

SVN & GIT Hosting

Oprettelse af det første lager

Efter du har oprettet en konto, skal du oprette et repository - for hver platform separat. Det ser normalt sådan ud:

• Log ind på din konto, klik på dine projekter.
• Oprettelse af et projekt:

• I linjen "Opret et nyt projekt" skal du indtaste navnet på dit projekt
• Klik på knappen "Opret projekt".

• SVN-forbindelse:

• Efter oprettelse af projektet skal du vælge fanen "Kildekontrol" (kildekodeversioner)
• Klik på linket "Aktiver kildekontrol"
• Giv lageret et navn
• Klik på "Gem"

Grafiske klienter SVN og GIT

Så depotet er blevet oprettet. Nu har vi brug for, at alt vises i den enkelt og tydeligt. For at gøre dette skal du bruge en GUI.

— praktisk program at arbejde medversionskontrolsystemerpå Microsoft Windows og måske den bedste Apache Subversion-klient, der findes. TortoiseSVN er implementeret som en Windows shell-udvidelse, hvilket gør det nemt at integrere i browser. Det er også et open source-program med 34 tilgængelige sprogpakker

SmartGit

– Git grafisk klient (open source distribueretversionskontrolsystem). Virker på Windows, Mac OS X og Linux.Licenspris - $39

"Tjekker" lageret ("Kasse")

Så klienten er blevet valgt. Nu skal du oprette et lager til kontrolsystemet. Skal indDit depot-URL, brugernavn og adgangskode.

URL'en ser normalt sådan ud:https://svn .hostname.com/svn/ > (du kan bruge https:// (SSL), hvis du har en betalt konto)

1. Gå til rodmappen, klik på knappen "Tjek ud" og opret arbejdsmappe for klient. Nu kan du tilføje filer til den.
2. Når projektfilerne er pakket ud, kan du redigere dem i en lokal mappe på din computer.

Når du har foretaget ændringer i filerne, skal du klikke på knappen Check-in på værktøjslinjen for at gemme dem. Du kan gennemgå ændringer og tilføje kommentarer til dem - det er en ret god idé, da du i fremtiden vil vide præcis, hvad du har arbejdet på, hvilke ændringer der er foretaget og vil holde andre projektdeltagere orienteret.

Din klient bør også give mulighed for at begynde at arbejde med revisioner til enhver tid ved at åbne revisionsloggen eller ændringshistorikken - så kan du om nødvendigt "rulle tilbage" til den tidligere version for hver fil individuelt. Nu hvor du er fortrolig med de grundlæggende begreber, dokumentationen

Da vores team af programmører udvikler flere projekter på én gang, opstod behovet for et versionskontrolsystem hurtigt.

Naturligvis begyndte eftersøgningen med undersøgelsen af ​​Habr - og førte til et uventet resultat. På trods af at versionskontrolsystemer dukkede op tilbage i 1986, var de fleste tutorials om at arbejde med moderne Versionskontrolsystemer viste sig at være ufuldstændige og stærkt bundet til at arbejde med kommandolinjen.

Vi har intet imod kommandolinjen generelt, men i vores lille team af udviklere (4 personer) er der ingen fans af at arbejde med kommandolinjen :).

Hvorfor tror vi, at det er ineffektivt at arbejde med kommandolinjen?

1. Spild tid på dataindtastning. Det tager meget længere tid at skrive kommandoer end at klikke med musen.
2. Spild af tid på at studere. At lære en ny syntaks i en tid med klare grænseflader tager bestemt længere tid end at lære en grafisk grænseflade.
3. Sandsynlighed for fejl. Det er lettere at lave en fejl, når du indtaster data via kommandolinjen (den menneskelige faktor er ikke blevet annulleret).
4. Krænkelse automatiseringsprincipper. Måske er dette det vigtigste punkt. Computeren er designet til at fremskynde arbejdet og erstatte en person, når der udføres rutineoperationer. I tilfælde af kommandolinjen arbejder vi altid manuelt faktisk er det nødvendigt hver gang skrive det samme programkode(omend primitivt).

Desværre var vi ikke i stand til at finde en fuldgyldig russisksproget manual til at arbejde med moderne versionskontrolsystemer. Efter at have indsamlet information fra forskellige artikler og engelsksprogede videoer på YouTube, besluttede vi at lave vores egen guide, som:

1. Der vil være trin-for-trin instruktioner (vores programmører vil arbejde i henhold til dem).
2. Det vil fungere fra start til slut (det vil sige, at du får et lille, men komplet resultat - et fungerende distribueret versionskontrolsystem).
3. Fungerer kun ved brug af GUI'er (se årsagerne ovenfor).

Introduktion

I modsætning til forventningerne fra erfarne systemadministratorer og andre elskere og fans af at arbejde med kommandolinjen, vil denne artikel ikke indeholde nogen kommandoer, der udføres ved hjælp af kommandolinjen. Hele artiklen er skrevet på et sprog, der er forståeligt selv for dem, der først for nylig er begyndt at programmere, men allerede overvejer at implementere et VCS (versionskontrolsystem). Hvert trin i opsætning af VCS tygges ned til mindste detalje, med skærmbilleder og yderligere forklaringer.

Hvis du ikke er fan af "For Dummies"-manualer, kan du springe over at læse denne artikel og gå din egen vej for at løse problemet med at hæve VCS.

Anvendte programmer og tjenester

For at implementere et VCS (versionskontrolsystem), vil vi bruge følgende programmer og tjenester:

• Mercurial er et distribueret versionskontrolsystem på tværs af platforme designet til effektivt arbejde med meget store kodelagre.
• TortoiseHg er en grafisk frontend til Mercurial versionskontrolsystemet.
• Bitbucket er en webservice til hosting af projekter og deres fælles udvikling, baseret på Mercurial og Git versionskontrolsystemerne.

Implementering af et versionskontrolsystem - trin-for-trin instruktioner

1. Download og installer TortoiseHg på din computer fra den officielle hjemmeside: http://tortoisehg.bitbucket.org/

Denne klient skal installeres på alle computere, hvorfra fælles udvikling af projekter vil blive udført.

I denne manual vil alle trin til opsætning og arbejde med versionskontrolsystemet blive udført vha TortoiseHg version: 2.10.1 til Windows 64-bit med Mercurial 2.8.1.

2. Tilmeld dig i Bitbucket-webtjenesten: https://bitbucket.org/
Hele registreringsprocessen kommer ned til at udfylde kontaktoplysninger (brugernavn, e-mail osv.) og bekræfte den e-mailadresse, der blev angivet under registreringen, ved at klikke på knappen "Bekræft denne e-mailadresse" i brevet modtaget efter registreringen.

Alle medlemmer af dit udviklingsteam skal også registrere sig hos Bitbucket. Til stor lykke for startups i denne service Der er en gratis konto, der giver dig mulighed for at oprette private repositories med 5 brugere. Det er også muligt at øge det maksimale antal teammedlemmer involveret i udvikling på den gratis plan til 8 personer.

Du kan se den fulde liste over takster ved at følge linket: https://bitbucket.org/plans

3. Ved at logge ind på din konto i Bitbucket-tjenesten kan du straks ændre grænsefladesproget på din konto til russisk.

For at gøre dette skal du i øverste højre hjørne af hovedmenuen vælge sektionen "Administrer konto" fra rullelisten, og på den side, der åbnes, skal du vælge det grænsefladesprog, du har brug for, fra rullelisten "Sprog".

4. For at oprette et arkiv til dit projekt skal du gå til hovedsiden af ​​din konto (https://bitbucket.org/dashboard/overview) og klikke på knappen "Opret dit første arkiv"

5. Angiv følgende indstillinger på siden for oprettelse af et nyt lager:

Navn – Indtast et navn til dit nye lager. Dette navn bruges til at bygge et adgangslink til dit lager.
Vigtig! Det er bedre at angive navnet med latinske bogstaver, ellers vil linket til depotet ende med bindestreger og have et svært at forstå: https://[email protected]/yourlogin/--------

Beskrivelse – Giv en kort beskrivelse af dit lager (valgfrit)
- Adgangsniveau – Marker afkrydsningsfeltet, hvis du ønsker, at kun medlemmer af dit udviklingsteam skal have adgang til dit arkiv (privat arkiv).
- Oprettelse af gafler – Indstil "Tillad kun private gafler"
- Lagertype - Vælg "Mercurial"
- Projektstyring - Marker afkrydsningsfelterne "Opgavesporing" og "Wiki".
- Sprog – Vælg det udviklingssprog, som dit projekt er skrevet på. I mit tilfælde er det PHP.

Når alle indstillinger er blevet specificeret, vil siden se sådan her ud:

Tjek de indtastede data igen, og hvis alt er indtastet korrekt, skal du klikke på knappen "Opret lager".

6. Når du har oprettet et nyt lager, vil du blive ført til siden "Kom godt i gang":

7. Opret en tom mappe på din computer, hvor dine projektfiler, der er forbundet med Mercurial-versionskontrolsystemet, vil blive gemt i fremtiden.

Vigtig! Mappen skal være tom. For eksempel, for at forbinde en mappe med et allerede eksisterende projekt (en masse programkode), måtte jeg midlertidigt flytte alle filerne til en anden mappe (lave en sikkerhedskopi). Senere vil vi returnere alle filerne til deres plads, men for nu skal vi fuldstændig rydde forbindelsesmappen.

8. I vinduet, der åbnes, skal du angive et link i feltet "Kilde" for at oprette forbindelse til det lager, du oprettede fra trin 6

Og klik på knappen "Klon".

9. Systemet vil bede dig om en adgangskode til din konto i Bitbucket-tjenesten, indtast den.

10. Hvis alt er udført uden afvigelser fra disse instruktioner, så vil der komme en ny ".hg" mappe i mappen med servicefiler oprettet depot.

11. Nu kan du sikkert returnere filerne (programkoden) for dit projekt til mappen beregnet til lagring af projektfiler forbundet med Mercurial versionskontrolsystemet

Vigtig! Rør ikke ved servicebiblioteket ".hg". Det er nødvendigt for at VCS kan fungere.

12. Tryk igen Højreklik musen på vores projektmappe og fra rullemenuen vælg "Hg Commit..."

13. Du vil se en dialogboks designet til at registrere alle ændringer, der er foretaget i dit projekt (i I dette tilfælde vi tilføjede vores programkoder til den oprindeligt tomme projektmappe).

Du skal vælge alle ændrede (tilføjede) filer, angive en kommentar (f.eks. version 1.00) til ændringen og klikke på knappen "Bekræft".

Systemet vil bede dig om at bekræfte tilføjelsen, klik på "Tilføj".

14. Hvis alt blev gjort korrekt, vil systemet registrere de foretagne ændringer, og du vil se noget som dette:

Faktisk vil du i fremtiden, når du udvikler, efter at have udfyldt et lille stykke kode, udføre handlingen fra trin 12 (klik på "Hg Commit ...") for at foretage ændringen i versionskontrolsystemet. Dette giver dig mulighed for at rulle systemet tilbage til en tidligere commit til enhver tid.

I betragtning af ovenstående bør du i praksis skrive en mere detaljeret kommentar end "Version 1.00" for hver af commits.

16. I vinduet, der åbnes, kan du se hele historikken for gemte (committerede) ændringer i koden, du kan rulle tilbage til den ønskede commit, og også sende ændringer til det repository, du oprettede tidligere.

For at gøre dette skal du i kontrolpanelet vælge knappen "Skub indgående ændringer til".

Du vil derefter blive præsenteret for dialogbokse, der beder dig bekræfte "push" og beder dig om at angive adgangskoden til din Bitbucket-konto. Accepter og angiv din adgangskode.

Systemet vil begynde at kopiere filer til dit lager på Bitbucket-serveren. Tag dig tid og vent på, at processen er fuldført.

17. Nu er en kopi af dine projektfiler gemt i dit lager på Bitbucket-serverne. På din Bitbucket-konto kan du se hele historikken for dit projekt.

Mellemresultater af tilslutning af et versionskontrolsystem (VCS)

På dette tidspunkt har vi oprettet et lager og placeret alle filerne i vores projekt i det. Det vil sige, nu kan du oprette forbindelse til dit lager fra enhver computer og få stabil version filer gemt i den.

Processen med at forbinde din anden computer involverer kopiering af filer fra lageret til den anden computer. Du skal gennemgå trin 1 - Installation af TortoiseHg og 7 - Import af lagerfiler for at kopiere filerne til din anden, tredje og næste fungerende computer.

Tilslutning af medarbejdere til dit lager.

Hovedformålet med at forbinde et versionskontrolsystem (VCS) til dit projekt er at organisere samarbejde. De der. Mens du udvikler et system alene, kan du i de fleste tilfælde undvære VCS, men hvis der er flere udviklere, så er sandsynligheden for regelmæssigt tab (overskrivning) af programkoder og konflikter mellem systemversioner meget høj.

Lad os derfor nu koble en anden programmør til vores projekt (inviter en deltager) og indrette hans arbejdsplads.

Tilslutning af en medarbejder til vores repository

18. Alle medarbejdere, der vil have adgang til dit lager, skal være registreret på Bitbucket-tjenesten. De bør også have TortoiseHg installeret på deres computere.

Jeg fortalte dig, hvordan du tilmelder dig tjenesten og installerer TortoiseHg lidt tidligere i denne manual. Derfor denne proces bør ikke forårsage vanskeligheder for dig og dine kolleger.

19. Log ind på din Bitbucket-konto:

Klik på knappen "Send en invitation" i sektionen "Inviter et medlem til dette lager".

20. Systemet viser en dialogboks, der beder dig specificere email adresse den bruger, du vil give adgang til depotet. Derudover skal du angive adgangsrettigheder (læse eller skrive). Fordi I disse instruktioner viser vi, hvordan du forbinder en anden udvikler til depotet, og derefter angiver "entry".

Når du har indtastet medarbejderens e-mail og specificeret adgangsrettigheder, skal du klikke på knappen "Del".

21. Den inviterede deltager modtager e-mail brev med et link til invitationen. Han bliver nødt til at følge dette link og acceptere invitationen til at få adgang til dit lager.

Endnu en gang skal alle deltagere i dit lager være registreret i Bitbucket-tjenesten.

22. Efter at invitationen er accepteret, vil den nye deltager se dette lager på sin konto og sit link for at få adgang til det ved hjælp af TortoiseHg.

Alle ændringer foretaget af dig og dine bidragydere vil blive gemt i dit lager. Du vil til enhver tid kunne se, hvad der blev ændret og hvornår, og om ønsket kan du rulle dit projekt tilbage til den ønskede version.

Jeg tror, ​​at den indledende artikel om implementering af et versionskontrolsystem uden brug af kommandolinjen kan slutte her. Gennemgang af trinene beskrevet ovenfor vil give dig mulighed for at implementere en fuldgyldig VCS i dit projekt, dvs. Når du har gennemgået alle trinene, vil du få, selvom det ikke er fantastisk, et komplet resultat.

Vi brugte denne tilgang til at udvikle projektet.

Ofte arbejder udviklere i et team på et projekt, hvilket betyder, at flere personer kan ændre en fil på samme tid. For at undgå forvirring i sådanne tilfælde bruges et versionskontrolsystem, som giver dig mulighed for at gemme en historik over projektændringer og om nødvendigt hjælper dig med at vende tilbage til den tidligere version.

Versionering

For bedre at forstå problemet med versionering, overvej eksemplet med en designer, der afsluttede arbejdet med et projekt og sendte den endelige version til kunden. Designeren har en mappe, hvori den endelige version af projektet er gemt:

Kilde/ barbershop_index_final.psd

Alt er fint, designeren afsluttede arbejdet, men kunden sendte rettelser tilbage. At kunne vende tilbage til gammel version projekt, designeren skabte ny fil barbershop_index_final_2.psd , foretaget ændringer og sendt til kunden:

Kilde/ barbershop_index_final.psd barbershop_index_final_2.psd

Dette stoppede ikke der; som et resultat voksede projektstrukturen og begyndte at se sådan ud:

Kilde/ 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

Det er der formentlig mange, der allerede er stødt på, f.eks. når de skriver semesteropgaver under studiet. I professionel udvikling er det en dårlig praksis at bruge nye filer til versionering. Typisk har udviklere mange filer gemt i deres projektmappe. Desuden kan flere personer arbejde på et projekt. Hvis hver udvikler opretter en ny fil til versionering, og ændrer lidt navnet på den tidligere version, begynder kaos snart i projektet, og ingen vil forstå, hvilke filer der skal åbnes.

Git

For at løse problemet med at gemme en ny version af filer er det praktisk at bruge versionskontrolsystemer. En af de mest populære er Git. Git kan sammenlignes med processen med at gemme og indlæse i computerspil:

• hvis der er en vanskelig kamp forude, så er det bedre at spare på forhånd;
• for at gøre dette skal du gøre særligt hold;
• hvorefter sparingen går til speciel mappe og indeholder spiltilstanden;
• Nu kan du om nødvendigt altid vende tilbage til den tidligere version af spillet.

SomeGame/ | - sparer | | - save001.sav | | - save002.sav | | ... | | gem mappe | | - game.exe | ...spilfiler

De filer, der er nødvendige for, at programmet kan køre, gemmes i arbejdsområdet. Gem-mappen gemmer historikken for alle gemte spil. Git gemmer din projektkode efter samme princip: gemmer går ind i en speciel skjult mappe, og arbejdsområde er indholdet af rodmappen.

Basale koncepter

GUI

Særlige programmer kan gøre arbejdet med Git og GitHub lettere. Sådanne programmer i bekvem form vis ændringer i kode, en liste over commits og har andre praktiske funktioner. Normalt i sådanne programmer er det muligt at udføre standard Git-kommandoer: pull , push , begå andre - blot ved at klikke på en knap.

I kontakt med

Telegram

Send dit gode arbejde i videnbasen er enkel. Brug formularen nedenfor

Godt arbejde til webstedet">

Studerende, kandidatstuderende, unge forskere, der bruger videnbasen i deres studier og arbejde, vil være dig meget taknemmelig.

opslået på http://www.allbest.ru/

Ministeriet for Uddannelse og Videnskab i Den Russiske Føderation

Forbundsstatsbudget uddannelse

Institut for videregående faglig uddannelse

"TOMSK STATE UNIVERSITY

STYRESYSTEMER OG RADIOELEKTRONIK" (TUSUR)

Institut for Radiotekniske Systemer (RTS)

Kursusarbejde

i kurset "Informationsteknologier"

VERSIONS STYRINGSSYSTEMER

Elever fra gruppe 121-3 Korolev D.O.,

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

Leder Nozdrevatykh B.F.

Kursusarbejde 46 s., 31 figurer, 2 tabeller, kilder.

VERSIONS STYRINGSSYSTEM, GIT, SVN, MERCURIAL.

Dette kursusarbejde undersøger de mest populære versionskontrolsystemer.

Formålet med arbejdet er at sætte sig ind i versionskontrolsystemer, forstå deres drift, installation og konfiguration.

Under arbejdet blev tre typer versionskontrolsystemer installeret, konfigureret og testet.

Som et resultat heraf er der kompileret tre fuldt brugsklare versionskontrolsystemer, tabeller, der sammenligner disse systemers funktioner, og en ordbog over termer, der bruges, når der arbejdes med programmer, er tilvejebragt.

Kursusarbejdet blev gennemført i teksteditoren Microsoft Word 2010 og præsenteret i trykt og elektronisk form.

kontrolversion systemgrænseflade

Introduktion

3.1 Kom godt i gang med projektet

3.2 Daglig arbejdscyklus

3.3 Filialer

3.4 Sammenlægning af versioner

3.5 Konflikter og deres løsning

3.6 Låse

3.7 Projektversioner, tags

4.1 Lokale systemer versionskontrol

4.2 Centraliseret model

5.1.1 Systemkrav

5.1.2 Koncept

5.1.3 Kom godt i gang

5.2.1 Systemkrav

5.2.2 Installation

5.2.3 Grundkoncept

5.2.4 Oprettelse af et lager

5.2.5 Import af et projekt

5.2.7 Foretage ændringer

5.2.8 Tilføjelse af nye filer

5.2.9 Annuller ændringer

5.3.1 Systemkrav

5.3.2 Koncept

5.3.3 Kom godt i gang

Konklusion

Bilag A

Bilag B

Bilag B

Introduktion

I dag i en verden, hvor der er stor mængde komplekse systemer, er der behov for at ændre elektroniske dokumenter på forskellige stadier af deres udvikling. Under dets eksistens kan et elektronisk dokument være genstand for en lang række ændringer. Det sker dog ofte, at der ikke kun er brug for den seneste version af dokumentet, men også forskellige tidligere versioner til det videre arbejde.

Du kan selvfølgelig gemme flere forskellige muligheder påkrævet dokument, men denne metode er ineffektiv. Vi skal bruge meget tid og kræfter, der kræves særlig opmærksomhed, og der er stor sandsynlighed for fejl. Derudover skal vi opbevare et stort antal næsten identiske dokumenter.

Som et resultat er der udviklet softwareværktøjer, der forenkler denne mekanisme. Disse værktøjer kaldes versionskontrolsystemer. Der er flere systemer af denne art, som hver især er relevante under visse betingelser for deres brug.

Hovedideen med versionskontrolsystemer er at huske alt foretaget ændringer, samt kommentarer fra de brugere, der har bidraget med dem. Herefter bliver det klart, hvem, hvornår og hvad ændrede sig, hvorfor og hvorfor. Og vigtigst af alt, alle disse ændringer kan derefter rulles tilbage på et hvilket som helst tidspunkt.

I overensstemmelse med målet er det nødvendigt at løse følgende opgaver:

Definer konceptet for et versionskontrolsystem;

Forstå, hvordan sådanne systemer fungerer;

Gennemgå installations- og lanceringsregler;

Analysere eksisterende systemer versionskontrol;

Overvej hovedtyperne af denne type system.

Målene for arbejdet forudbestemte dets struktur. Kursusarbejdet består af fem kapitler, introduktion, konklusion, litteraturliste og bilag.

1. Konceptet med et versionskontrolsystem

Version Control System (VCS) er software til at lette arbejdet med skiftende information. Et versionskontrolsystem giver dig mulighed for at gemme flere versioner af det samme dokument og om nødvendigt vende tilbage til flere tidligere versioner, bestemme, hvem og hvornår der har foretaget denne eller hin ændring.

2. Brug af et versionskontrolsystem

Disse typer systemer bruges mest i softwareudvikling, så kildekoderne til de programmer, der udvikles, kan gemmes. VCS giver udviklere mulighed for at gemme tidligere versioner af filer fra udvikling og hente dem derfra. Det gemmer versionsoplysninger for hver fil (og hele projektstrukturen) i en samling, der normalt kaldes et lager. Men ikke desto mindre kan disse systemer bruges på andre vidensområder, som omfatter et stort antal hyppigt skiftende elektroniske dokumenter. For eksempel bruges de i stigende grad i CAD, normalt som en del af produktdatastyringssystemer (PDM). Versionering bruges i konfigurationsstyringsværktøjer.

Brugen af ​​VCS er bestemt obligatorisk for udvikleren, hvis projektet er mere end et par hundrede linjer, eller hvis flere udviklere arbejder sammen om projektet.

Versionskontrolsystemer løser følgende problemer:

Lagring af filversioner;

Evnen til at hente tidligere versioner af lagrede filer;

Se ændringer foretaget mellem de versioner, der er angivet i anmodningen;

3. Typisk procedure for at arbejde med systemet

Hver VCS har sine egne specifikke funktioner i sættet af kommandoer, hvordan brugere arbejder og administration. Imidlertid er den generelle betjeningsprocedure for de fleste VCS'er fuldstændig stereotyp. Her antages det, at projektet, hvad end det måtte være, allerede eksisterer, og dets repository er placeret på den server, som udvikleren får adgang til.

3.1 Kom godt i gang med projektet

Det første skridt, en udvikler skal tage, er at hente en arbejdskopi af projektet eller den del af det, der skal arbejdes på. Denne handling udføres ved hjælp af en standardversion checkout-kommando (checkout eller clone) eller en speciel kommando, der faktisk udfører den samme handling. Udvikleren angiver den version, der skal kopieres; som standard kopieres den seneste version (eller den, der er valgt af administratoren som den primære) normalt.

Udtrækningskommandoen etablerer en forbindelse til serveren, og projektet i form af et træ af mapper og filer kopieres til udviklerens computer. En almindelig praksis er at duplikere en arbejdskopi: ud over hovedbiblioteket med projektet på lokal disk Desuden optages endnu en kopi af den. Når du arbejder på et projekt, ændrer udvikleren kun filerne i hovedarbejdskopien. Den anden lokale kopi gemmes som en reference, så du til enhver tid, uden at kontakte serveren, kan bestemme, hvilke ændringer der er foretaget i en specifik fil eller projektet som helhed, og fra hvilken version arbejdskopien blev lavet; som regel fører ethvert forsøg på manuelt at ændre denne kopi til fejl i driften af ​​VCS-softwaren.

3.2 Daglig arbejdscyklus

Med nogle variationer bestemt af funktionerne i systemet og detaljerne i den vedtagne forretningsproces, ser den sædvanlige cyklus af en udviklers arbejde i løbet af en arbejdsdag således ud:

1) Opdatering af arbejdskopien. Efterhånden som der foretages ændringer i hovedversionen af ​​projektet, bliver arbejdskopien på udviklerens computer gammel: dens uoverensstemmelse med hovedversionen af ​​projektet øges. Dette øger risikoen for modstridende ændringer. Derfor er det praktisk at opretholde en arbejdskopi i en tilstand så tæt som muligt på den aktuelle hovedversion, for hvilken udvikleren udfører en opdateringsoperation på arbejdskopien så ofte som muligt.

2) Ændring af projektet. Udvikleren ændrer projektet ved at ændre de inkluderede filer i arbejdskopien i overensstemmelse med designspecifikationen. Dette arbejde udføres lokalt og kræver ikke opkald til VCS-serveren.

3) Rettelse af ændringer. Efter at have afsluttet den næste fase af arbejdet med en opgave, forpligter udvikleren sine ændringer og overfører dem til serveren, enten til hovedgrenen, hvis arbejdet med opgaven er fuldstændig afsluttet, eller til en separat udviklingsgren for denne opgave. VCS kan kræve, at udvikleren opdaterer arbejdskopien, før den forpligter sig. Hvis systemet understøtter reolændringer, kan ændringer overføres til serveren uden at forpligte sig. Hvis den godkendte arbejdspolitik i hårdvalutasystemet tillader dette, kan ændringer ikke registreres dagligt, men kun efter afslutning af arbejdet med opgaven; i dette tilfælde gemmes alle ændringer forbundet med jobbet kun i udviklerens lokale arbejdskopi, indtil jobbet er fuldført.

3.3 Filialer

Du kan lave mindre rettelser i projektet ved direkte at redigere arbejdskopien og derefter committe ændringerne direkte til hovedgrenen (trunken) på serveren. Men når der udføres en betydelig mængde arbejde, bliver denne ordre ubelejlig: manglen på registrering af mellemliggende ændringer på serveren tillader ikke arbejde på noget i en gruppetilstand; desuden øges risikoen for at miste ændringer under lokale ulykker, og evnen til at analysere og vende tilbage til tidligere er mistet kodevarianter inden for dette arbejde. Derfor, for sådanne ændringer, er den sædvanlige praksis at oprette filialer, oprette en version af en ny version af projektet eller en del af det, hvis udvikling udføres parallelt med ændringer i hovedversionen. Når det arbejde, som filialen blev oprettet til, er afsluttet, genintegreres filialen i hovedgrenen. Dette kan gøres med flettekommandoen eller ved at oprette en patch, der indeholder ændringer foretaget under udviklingen af ​​grenen og anvende denne patch til den aktuelle hovedversion af projektet.

3.4 Sammenlægning af versioner

Tre typer operationer udført i versionskontrol kan resultere i behovet for at flette ændringer:

Opdatering af arbejdskopien;

Registrering af ændringer;

Sammenlægning af grene.

Hvert system har en automatisk flettemekanisme, der fungerer baseret på følgende principper:

Ændringer kan bestå i at ændre indholdet af en fil, oprette en ny fil eller mappe, slette eller omdøbe en allerede eksisterende fil eller mappe i projektet;

Hvis to ændringer refererer til forskellige og ikke-relaterede filer og/eller mapper, kan de altid flettes automatisk. Deres sammenlægning er, at de ændringer, der er foretaget i hver version af projektet, kopieres til den flettede version;

Oprettelse, sletning og omdøbning af filer i projektmapper kan flettes automatisk, så længe de ikke er i konflikt med hinanden. I dette tilfælde kopieres ændringer foretaget i hver version af projektet til den flettede version.

De modstridende er normalt:

Sletning og ændring af den samme fil eller mappe;

Sletning og omdøbning af den samme fil eller mappe;

Oprettelse af en fil med samme navn og forskelligt indhold i forskellige versioner;

Ændringer inden for samme tekstfil foretaget i forskellige versioner kan flettes, hvis de er i forskellige steder denne fil og krydser ikke. I dette tilfælde er alle ændringer inkluderet i den flettede version;

Ændringer i den samme fil, medmindre det er en tekstfil, er altid modstridende og kan ikke flettes automatisk.

I alle tilfælde er den basisversion, der skal flettes, den version, hvori de flettede versioner blev opdelt. Hvis dette er en commit-operation, vil basisversionen være versionen sidste ændring før forpligtelse, hvis opdatering - derefter version tidligere opdatering, hvis du fletter grene, så den version, hvor den tilsvarende gren blev oprettet. Følgelig vil de ændringssæt, der sammenlignes, være de sæt af ændringer, der er foretaget fra basis til den aktuelle version i alle flettede varianter.

Absolut flertal moderne systemer Versionskontrol er primært rettet mod softwareudviklingsprojekter, hvor hovedtypen af ​​filindhold er tekst. Følgelig er mekanismerne til automatisk fletning af ændringer fokuseret på behandling af tekstfiler.

Når det skal afgøres, om det er tilladt at flette ændringer inden for den samme tekstfil, fungerer en standardmekanisme til linje-for-linje sammenligning af tekster (et eksempel på dens implementering er systemværktøj GNU diff), som sammenligner de flettede versioner med basisversionen og opbygger en liste over ændringer, det vil sige rækkesæt tilføjet, fjernet og erstattet. Fundne sæt af modificerede strenge, der ikke krydser hinanden, anses for at være kompatible, og deres fletning sker automatisk. Hvis de flettede filer indeholder ændringer, der påvirker den samme fillinje, fører dette til en konflikt. Sådanne filer kan kun flettes manuelt. Alle andre filer end tekstfiler er binære fra VCS-synspunktet og tillader ikke automatisk fletning.

3.5 Konflikter og deres løsning

En situation, hvor ændringerne i dem overlapper hinanden ved sammenlægning af flere versioner, kaldes en konflikt. Hvis der er en konflikt mellem ændringer, kan versionskontrolsystemet ikke automatisk oprette et fusioneret projekt og er tvunget til at kontakte udvikleren. Som nævnt ovenfor kan der opstå konflikter i stadierne af begå ændringer, opdatering eller sammenlægning af filialer. I alle tilfælde, når en konflikt opdages, stoppes den tilsvarende handling, indtil den er løst.

For at løse en konflikt tilbyder systemet generelt udvikleren tre muligheder for modstridende filer: base, lokal og server. Modstridende ændringer vises enten til udvikleren i et specielt softwaremodul til fletning af ændringer, eller er blot markeret med speciel markup direkte i teksten i den flettede fil.

Konflikter i filsystemet løses nemmere: kun sletning af en fil kan være i konflikt med en af ​​de andre operationer, og rækkefølgen af ​​filerne i mappen er ligegyldig, så udvikleren kan kun vælge, hvilken handling der skal gemmes i sammenlagt version.

3.6 Låse

Låsemekanismen tillader en af ​​udviklerne kun at tage eget brug en fil eller gruppe af filer at foretage ændringer i. Mens filen er låst, forbliver den skrivebeskyttet for alle andre udviklere, og ethvert forsøg på at foretage ændringer i den afvises af serveren. Teknisk set kan blokering organiseres på forskellige måder. Følgende mekanisme er typisk for moderne systemer:

Filer, der kræver låsning for at arbejde med, er markeret med et særligt flag "låst";

Hvis en fil er markeret som låst, så får den, når en arbejdskopi hentes fra serveren, en skrivebeskyttet attribut på det lokale filsystem, som forhindrer den i at blive redigeret ved et uheld;

En udvikler, der ønsker at ændre en låst fil, kalder en speciel låsekommando, der angiver filnavnet. Resultatet af denne kommando er følgende:

1. serveren kontrollerer, om filen allerede er blokeret af en anden udvikler; hvis det er tilfældet, mislykkes blokeringskommandoen.

2. filen på serveren er markeret som "blokeret", med ID'et på den udvikler, der blokerede den, og blokeringstiden gemmes;

3. Hvis blokeringen på serveren lykkes, fjernes "read-only"-attributten fra arbejdskopifilen på det lokale filsystem, hvilket giver dig mulighed for at begynde at redigere den.

Hvis det under driften viser sig, at filen ikke skal ændres, kan han kalde oplåsningskommandoen , udløserlås). Alle ændringer af filen fortrydes, den lokale fil vil vende tilbage til en skrivebeskyttet tilstand, den "låste" attribut vil blive fjernet fra filen på serveren, og andre udviklere vil være i stand til at ændre denne fil;

Når arbejdet med den låste fil er afsluttet, forpligter udvikleren ændringerne. Normalt fjernes blokeringen automatisk.

3.7 Projektversioner, tags

Versionskontrolsystemet sikrer lagring af alle eksisterende versioner af filer og som følge heraf alle versioner af projektet som helhed, der er opstået siden begyndelsen af ​​dets udvikling. Men selve begrebet "version" i forskellige systemer kan fortolkes på to forskellige måder.

Nogle systemer understøtter filversionering. Det betyder, at enhver fil, der optræder i et projekt, får sit eget versionsnummer. Når en udvikler forpligter ændringer til en fil, anvendes den tilsvarende del af de forpligtede ændringer til filen, og filen modtager et nyt, normalt sekventielt, versionsnummer.

For andre systemer refererer begrebet "version" ikke til en individuel fil, men til hele depotet. Et nyoprettet tomt lager har en version på 1 eller 0, enhver commit-ændring fører til en stigning i dette antal. Der er faktisk ikke noget versionsnummer for en individuel fil her.

Begge muligheder er dog ikke særlig bekvemme. For mere bekvemt at markere projektversioner understøtter versionskontrolsystemer konceptet med tags.

Et tag er en symbolsk etiket, der kan knyttes til en specifik version af en fil og/eller et bibliotek i et lager. Ved at bruge den passende kommando kan alle eller dele af projektfilerne, der opfylder visse betingelser, tildeles en given etiket. På denne måde kan du identificere versionen af ​​projektet ved at rette dens tilstand på et ønsket tidspunkt. Som regel er tagging-systemet ret fleksibelt og giver dig mulighed for at tagge flere versioner af filer og mapper med ét tag. Dette giver dig mulighed for at bygge en "projektversion" på enhver vilkårlig måde.

4.1 Lokale versionskontrolsystemer

Den mest foretrukne VCS til overvågning af boligudvikling vil være den lokale type. For at løse dette problem blev der udviklet specielle VCS'er med en simpel database, hvori alle lokale filer er gemt.

Figur 4.1 Skema over lokal SCR

En af de mest populære VCS'er af denne type er RCS, som stadig er installeret på mange computere.

4.2 Centraliseret model

Traditionelle versionskontrolsystemer bruger en centraliseret model, hvor der er et enkelt dokumentlager, der administreres speciel server, som udfører de fleste versionskontrolfunktioner. En bruger, der arbejder med dokumenter, skal først hente den version af dokumentet, han har brug for, fra depotet; Normalt oprettes en lokal kopi af dokumentet, den såkaldte "arbejdskopi". Den seneste version eller en af ​​de tidligere kan fås, som kan vælges efter versionsnummer eller oprettelsesdato, nogle gange efter andre kriterier. Efter at de nødvendige ændringer er foretaget i dokumentet, placeres den nye version i depotet. I modsætning til blot at gemme en fil, slettes den tidligere version ikke, men forbliver også i lageret og kan hentes derfra til enhver tid.

Sådanne systemer, såsom CVS, Subversion og Perforce, har en central server, der gemmer alle filer under versionskontrol, og et antal klienter, der modtager kopier af filerne fra den. Dette har været standarden for versionskontrolsystemer i mange år.

Figur 4.2 Centraliseret versionskontrolskema

Denne tilgang har mange fordele, især i forhold til lokal SLE. For eksempel ved alle, hvem der laver hvad i projektet. Administratorer har klar kontrol over, hvem der kan gøre hvad, og selvfølgelig er CSKB meget nemmere at administrere end lokale databaser på hver klient.

Der er dog flere alvorlige ulemper ved denne tilgang. Det mest åbenlyse er, at den centraliserede server er det svage punkt i hele systemet. Hvis serveren går ned i en time, kan udviklere ikke interagere i en time, og ingen kan gemme en ny version af deres arbejde. Hvis disken med den centrale database er beskadiget, og der ikke er en sikkerhedskopi, mister du absolut alt - hele projektets historie, med undtagelse af nogle få fungerende versioner gemt på brugernes arbejdsmaskiner. Lokale VCS'er er underlagt det samme problem: Hvis hele projekthistorikken er gemt ét sted, risikerer du at miste alt.

4.3 Distribuerede versionskontrolsystemer

Sådanne systemer bruger en distribueret model i stedet for den traditionelle klient-server-model. Generelt har de ikke brug for en central lagring: hele historikken for dokumentændringer gemmes på hver computer, i lokal lagring, og om nødvendigt synkroniseres individuelle fragmenter af den lokale lagringshistorik med en lignende lagring på en anden computer. Derfor, i tilfælde af at serveren, som arbejdet gik ned igennem, går ned, kan ethvert klientlager kopieres tilbage til serveren for at gendanne databasen. I nogle af disse systemer lokal opbevaring er placeret direkte i arbejdskopibibliotekerne.

Figur 4.3 Distribueret VCS-model

Når en bruger af et sådant system udfører normale handlinger, såsom at hente en specifik version af et dokument, oprette en ny version og lignende, arbejder han med sin lokale kopi af depotet. Efterhånden som der foretages ændringer, begynder depoter, der tilhører forskellige udviklere, at adskille sig, og der er behov for at synkronisere dem. En sådan synkronisering kan opnås ved at udveksle patches eller såkaldte sæt mellem brugere.

Den beskrevne model er logisk tæt på at skabe en separat gren for hver udvikler i klassiske system versionskontrol. Forskellen er, at indtil synkronisering kan andre udviklere ikke se denne gren. Så længe en udvikler kun ændrer sin egen gren, påvirker hans arbejde ikke andre projektmedlemmer og omvendt. Efter afslutningen af ​​den separate del af arbejdet sammenlægges ændringerne i grenene med hovedgrenen (fælles). Både ved sammenlægning af grene og ved synkronisering af forskellige repositories er versionskonflikter mulige. I dette tilfælde giver alle systemer visse metoder til at opdage og løse flettekonflikter.

Fra brugerens synspunkt er et distribueret system kendetegnet ved behovet for at oprette et lokalt lager og tilstedeværelsen af ​​to yderligere kommandoer på kommandosproget: kommandoen om at modtage et lager fra en fjerncomputer og at overføre dets lager til fjerncomputer. Den første kommando fletter ændringer fra de eksterne og lokale arkiver og placerer resultatet i det lokale arkiv; den anden, tværtimod, slår ændringer fra to depoter sammen og placerer resultatet i et fjernlager. Typisk giver flettekommandoer i distribuerede systemer dig mulighed for at vælge, hvilke sæt ændringer der skal skubbes til eller trækkes fra et andet lager, rette flettekonflikter direkte under operationen eller efter dens fejl, og gentage eller genoptage en ufærdig fletning. Det lykkes typisk kun at overføre dine ændringer til en andens lager, hvis der ikke er nogen konflikter. Hvis der opstår konflikter, skal brugeren først flette versionerne i sit lager, og først derefter overføre dem til andre.

Det anbefales normalt at organisere arbejdet med systemet, så brugere altid eller overvejende udfører fletninger i deres repositories. Det vil sige, at i modsætning til centraliserede systemer, hvor brugere sender deres ændringer til den centrale server, når de finder det passende, er det i distribuerede systemer mere naturligt at få versionsfletningen initieret af den person, der skal modtage resultatet (f.eks. en udvikler, der administrerer en build-server).

De vigtigste fordele ved distribuerede systemer er deres fleksibilitet og betydeligt større (sammenlignet med centraliserede systemer) autonomi på en individuel arbejdsplads. Hver udviklers computer er faktisk en uafhængig og fuldt funktionel server; fra sådanne computere kan du bygge et system af enhver struktur og kompleksitetsniveau ved at indstille den ønskede synkroniseringsrækkefølge.

Ulemperne ved distribuerede systemer omfatter en stigning i den nødvendige mængde diskhukommelse: hver computer skal gemme en komplet versionshistorik, mens der i et centraliseret system normalt kun er en arbejdskopi gemt på udviklerens computer, det vil sige et udsnit af depotet på et tidspunkt og de ændringer, der er foretaget. En mindre indlysende, men ubehagelig ulempe er, at det er næsten umuligt at implementere noget af den funktionalitet, som centraliserede systemer leverer i et distribueret system. Det her:

- Blokering af en fil eller gruppe af filer (for at gemme blokeringsattributten kræves en central server, der er offentligt tilgængelig og konstant online). Dette tvinger særlige administrative foranstaltninger til at blive taget, hvis man skal arbejde med binære filer, der ikke er egnede til automatisk fletning;

- Overvågning af en specifik fil eller gruppe af filer;

- En enkelt kontinuerlig nummerering af systemversioner og/eller filer, hvor versionsnummeret stiger monotont. I distribuerede systemer må man nøjes med lokale versionsbetegnelser og brugstags, hvis formål er bestemt af en aftale mellem udviklere eller virksomhedens virksomhedsstandarder;

- Lokale brugere arbejder med en separat prøve med lille volumen fra en lagerfacilitet af betydelig størrelse og intern kompleksitet på en ekstern server.

Følgende typiske situationer kan identificeres, hvor brugen af ​​et distribueret system giver mærkbare fordele:

- Periodisk synkronisering af flere computere under kontrol af én udvikler. Brug af et distribueret system eliminerer behovet for at allokere en af ​​computerne som en server;

- Samarbejde om et projekt af en lille, geografisk fordelt gruppe af udviklere uden tildeling af delte ressourcer. Som i det foregående tilfælde implementeres et arbejdsskema uden en hovedserver, og arkivernes relevans vedligeholdes af periodiske synkroniseringer i henhold til "alle med alle"-skemaet;

Et stort distribueret projekt, hvor deltagerne kan arbejde på hver deres side i lang tid, men ikke har en konstant forbindelse til netværket. Et sådant projekt kan bruge en centraliseret server, hvormed kopier af alle dets deltagere synkroniseres. Det er muligt at arbejde uden "gruppe"-servere, så synkroniserer udviklere af en gruppe ændringer indbyrdes, hvorefter enhver af dem overfører ændringerne til den centrale server.

5. Eksempler på versionskontrolsystemer

5.1 GIT

5.1.1 Systemkrav

Git Fungerer under følgende styresystemer: Windows, Linux og Mac OS.

For at installere Git på Windows skal du blot downloade installationsprogrammets exe-fil fra projektsiden på GitHub og køre den. Efter installationen har du både en konsolversion (inklusive en SSH-klient) og en standard grafisk.

5.1.2 Koncept

Git er et distribueret versionskontrolsystem. I den kan filer være i en af ​​tre tilstande: engageret, ændret og forberedt. "Committed" betyder, at filen allerede er gemt i din lokale database. Ændrede filer inkluderer filer, der er ændret, men som endnu ikke er blevet committet. Iscenesatte filer er ændrede filer, der er markeret til medtagelse i den næste commit.

Projekter, der bruger Git, har således tre dele: Git-mappen, arbejdsmappen og iscenesættelsesområdet.

Git-mappen er hvor Git gemmer dit projekts metadata og objektdatabase. Det er den vigtigste del af Git, og det er det, der kopieres, når du kloner et lager fra en anden computer.

Arbejdsbiblioteket er en kopi af en specifik version af projektet udtrukket fra databasen. Disse filer hentes fra en komprimeret database i Git-mappen og placeres på disken, så du kan se og redigere dem.

Staging-området er en almindelig fil, normalt gemt i Git-mappen, som indeholder information om, hvad der skal ind i den næste commit. Det kaldes nogle gange indekset, men for nylig er det blevet standard at kalde det staging-området ( staging area) .

En standard arbejdsgang, der bruger Git, ser sådan ud:

1. Du foretager ændringer i filer i din arbejdsmappe.

2.Forbered filer ved at tilføje deres snapshots til området for forberedte filer.

3. Foretag en commit, der tager de forberedte filer fra indekset og placerer dem i Git-mappen til permanent opbevaring.

Hvis arbejdsversionen af ​​filen matcher versionen i Git-mappen, betragtes filen som forpligtet. Hvis filen ændres, men tilføjes til det forberedte dataområde, forberedes den. Hvis filen ændres efter aflæsning fra databasen, men ikke var udarbejdet, så anses det for ændret.

5.1.3 Kom godt i gang

Alle arbejder i Git foregår inde i et lager, der indeholder alle værkets filer. Du kan oprette et lager på forskellige måder.

1. Via kontekstmenuen. For at gøre dette skal du blot højreklikke i den ønskede mappe og vælge Git Init Here.

Figur 5.1.1 Oprettelse af et lager ved hjælp af kontekstmenuen

2. Brug af kommandolinjen. For at gøre dette på samme måde skal du i den nødvendige mappe vælge Git Bash i kontekstmenuen. En kommandolinje åbnes, hvor vi opretter lageret ved hjælp af Git Init-kommandoen.

Figur 5.1.2 Oprettelse af et lager ved hjælp af kommandolinjen

Hvis du aldrig har brugt git før, skal du først indtaste dit navn og din e-mail ved hjælp af henholdsvis følgende kommandoer:

git config --global bruger.navn "Dit navn"

git config --global bruger.e-mail [e-mail beskyttet]

Det oprettede lager vil indeholde en .git-mappe. For at tilføje en fil til depotet, skal du blot kopiere den til din arbejdsmappe. Lad os tilføje ex.txt-filen til depotet. Ved at bruge git status kommandoen vil vi sikre os, at Git har set filen.

Figur 5.1.3 Tilføjelse og kontrol af en fil i depotet

Dernæst, for at tilføje en fil under versionskontrol, skal du indeksere disse filer og udføre den første commit af ændringer. Dette kan gøres med et par git add-kommandoer, der specificerer de filer, der skal indekseres, og derefter git commit.

Figur 5.1.4 Tilføjelse af en fil under versionskontrol

Git status kommandoen er det vigtigste værktøj, der bruges til at bestemme, hvilke filer der er i hvilken tilstand.

For at begynde at spore (tilføj under versionskontrol) en ny fil, brug git add "filnavn" kommandoen. Denne kommando tager som parameter stien til en fil eller et bibliotek, hvis det er et bibliotek, tilføjer (indekserer) kommandoen rekursivt alle filer i den givne mappe.

Git commit -m “comment” er en kommando til at oprette en commit, rette en ændring.

Ved at bruge den grafiske grænseflade til Git Gui gentager vi den forrige operation. For at gøre dette skal du vælge punktet Git Gui i kontekstmenuen.

Figur 5.1.5

I det vindue, der åbnes, skal du vælge "Opret et nyt lager." Dernæst angiver vi den mappe, hvori vi ønsker at placere depotet.

Figur 5.1.6 Oprettelse af et lager i Git Gui

Tilføj Ex.txt-filen til mappen. Klik derefter på knappen "Genlæs". For at tilføje en fil til versionskontrol skal du klikke på knappen "Forbered alle". Ex.txt-filen skal flytte fra vinduet "Ændret" til vinduet "Forberedt". For at rette ændringen skal du bruge knappen "Gem".

5.1.5 Oprettelse af en kopi af depotet

I disse dage har du et stort antal hostingmuligheder at vælge imellem, alle med deres egne fordele og ulemper.

I dette afsnit gennemgår vi processen med at oprette en konto og et nyt projekt på GitHub. Dette vil give dig en ide om de ting, der er involveret.

GitHub er den største Git-hostingside for open source-projekter i dag, og en af ​​de få, der tilbyder både offentlig og privat hosting.

Den første ting du skal gøre er at oprette en konto og oprette dit lager på http://github.com/plans.

Indtast derefter de kommandoer, vi allerede kender på Git-kommandolinjen:

Git tilføje ex.txt

Git commit -m "kommentar"

Git remote tilføje oprindelse https://github.com/Arbuz-z-z/MyHomework.git

Git push -u origin master

Git remote add-kommandoen er til at tilføje remote repositories, og git push-kommandoen er til at pushe lokale ændringer til en ekstern server.

Figur 5.1.7

Indtast brugernavn og adgangskode, der blev angivet under registreringen:

Figur 5.1.8

Nu er vores projekt lagt ud på GitHub, i depotet - MyHomework med filen Tusur.txt og vi kan give et link til det til alle, som vi vil dele projektet med.

Figur 5.1.9 Repository på GitHub

5.2 TortoiseSVN

5.2.1 Systemkrav

TortoiseSVN kører på Windows XP (med Service Pack 3) eller højere og er tilgængelig i både 32-bit og 64-bit versioner. Installationsprogrammet til 64-bit Windows inkluderer også en 32-bit del.

5.2.2 Installation

TortoiseSVN kommer som en nem at bruge installationsfil.

5.2.3 Grundkoncept

Opbevaring. Subversion bruger en central database, der indeholder alle versionerede filer med deres fuld historie. Denne database kaldes et repository. Lagret er normalt placeret på en filserver, hvor Subversion er installeret, og leverer data til Subversion-klienter (for eksempel TortoiseSVN) efter anmodning. Hvis du laver en sikkerhedskopi, skal du kopiere dit lager, da det er originalen af ​​alle dine data.

Arbejdskopi. Det er præcis her, du arbejder. Hver udvikler har deres egen arbejdskopi, nogle gange kaldet en sandkasse, på deres lokale computer. Du kan hente den seneste version af filer fra lageret, arbejde på det lokalt uden at interagere med andre, og når du er sikker på ændringerne, kan du overføre disse filer tilbage til lageret. Arbejdskopien indeholder ikke historien om projektet, men indeholder en kopi af alle de filer, der var i lageret, før du begyndte at foretage ændringer.

TortoiseSVN er en Windows Stifinder-udvidelse, så først skal du starte Stifinder.

Figur 5.2.1 Visning i Stifinder

5.2.4 Oprettelse af et lager

Til dette projekt har vi brug for et lager oprettet på en sikker placering og en Subversion-server til at administrere det. Vi bruger Subversions lokale lagerfunktion, som giver direkte adgang til lager oprettet på din harddisk og ikke kræver en server.

Lad os først oprette en ny tom mappe på pc'en. Det kunne være hvor som helst, men til denne tutorial vil vi kalde det s:\svn_repos. Nu ved at højreklikke på den nye mappe og ind kontekstmenu vælg TortoiseSVN > Opret et depot her... Depotet, der er oprettet inde i mappen, er klar til brug. Vi vil også oprette en intern mappestruktur ved at klikke på knappen "Create Directory Structure".

Figur 5.2.2 Oprettelse af et lager

Figur 5.2.3 Gennemse lager

5.2.5 Import af et projekt

Vi har i øjeblikket lager, men det er helt tomt i øjeblikket. Lad os antage, at vi har et sæt filer i E:\\TortoiseSVN, som vi gerne vil tilføje. Lad os gå til TortoiseSVN-mappen i Stifinder og højreklikke på den. Vælg nu TortoiseSVN > Importer..., som åbner en dialogboks.

Figur 5.2.4 Importvindue

Subversion-depotet tilgås af en URL, som giver os mulighed for at pege på depotet hvor som helst på internettet. I dette tilfælde skal vi pege på vores lokale lager, som har URL-filen:///s:/svn_repos, og som vi tilføjer navnet på vores TortoiseSVN-projekt til.

Andet vigtig funktion i denne dialogboks er vinduet Importer meddelelse, hvor du kan tilføje en meddelelse om, hvad vi laver. Når vi skal gennemgå et projekts historie, vil disse beskeder være en værdifuld hjælp til at se, hvilke ændringer der blev foretaget, og hvornår.

5.2.6 Tjek en arbejdskopi

Nu har vi et projekt i vores repository, og vi skal lave en arbejdskopi til det daglige arbejde. Det er værd at bemærke, at import af en mappe ikke automatisk gør den mappe til en arbejdskopi. For at skabe en frisk arbejdskopi bruger Subversion udtrykket "Check Out". Vi vil udpakke TortoiseSVN-mappen fra vores lager til en udviklingsmappe kaldet e:\\TortoiseSVN\svn_repos. Lad os oprette denne mappe, højreklik derefter på den og vælg TortoiseSVN > Udpak... Indtast den URL, der skal udpakkes, i dette tilfælde file:///s:/svn_repos/TortoiseSVN, og klik på OK. Vores udviklingsmappe vil blive fyldt med filer fra depotet.

Udseendet af denne mappe er anderledes end en almindelig mappe. Hver fil har nu et grønt flag i venstre hjørne. Disse er TortoiseSVN-statusikoner, der kun er til stede i arbejdskopien. Grøn status betyder, at filen ikke adskiller sig fra versionen af ​​filen i depotet.

5.2.7 Foretage ændringer

Du kan begynde at arbejde. I mappe TortoiseSVN vi begynder at ændre filer - lad os sige, at vi laver ændringer til TortoiseSVN.docx filerne. Bemærk, at ikonerne på disse filer nu er røde og indikerer, at der er foretaget ændringer lokalt.

Højreklik på en af ​​de ændrede filer og vælg TortoiseSVN > Forskelle. TortoiseSVN-filsammenligningsværktøjet starter og viser dig præcis, hvilke linjer i filerne der blev ændret.

Figur 5.2.5 Filsammenligning

Lad os nu opdatere lageret. Denne handling kaldes "Commit Changes". Højreklik på TortoiseSVN-mappen, og vælg TortoiseSVN > Commit. En forpligtelsesdialog vises med en liste over ændrede filer, og der vil være et flueben ud for hver enkelt. Vi kan kun vælge nogle få filer fra listen til at begå.

Figur 5.2.6 Committing filer

5.2.8 Tilføjelse af nye filer

Mens vi arbejder på projektet, skal vi bruge tilføje nye filer, antag at vi har tilføjet nye funktioner i en fil og tilføjet hjælp i en eksisterende fil. Højreklik på mappen og vælg TortoiseSVN > Tilføj. Tilføj dialogen viser alle uversionerede filer, og vi kan vælge de filer, vi vil tilføje. En anden måde at tilføje filer på er at højreklikke på selve filen og vælge TortoiseSVN > Tilføj.

Hvis vi nu åbner commit-mappen, vil den nye fil blive vist som "Tilføjet" og den eksisterende fil som "Ændret".

5.2.9 Annuller ændringer

Et fællestræk ved alle revisionsstyringssystemer er den funktion, der giver os mulighed for at fortryde ændringer, som vi tidligere har foretaget.

Hvis vi ønsker at slippe af med ændringer, som vi endnu ikke har formået at registrere og gendanne påkrævet fil i den form, den var i før ændringerne begyndte, og vælg derefter kommandoen TortoiseSVN > Fjern ændringer. Denne handling vil fortryde vores ændringer og returnere den faste version af den fil, vi startede med. Hvis vi kun ønsker at fjerne nogle af ændringerne, så kan vi bruge TortoiseMerge-værktøjet til at se ændringerne og selektivt fjerne de ændrede rækker.

Hvis vi ønsker at fortryde en specifik revision, starter vi med log-dialogen og finder den problematiske revision. Vælg kommandoen Kontekstmenu > Kassér ændringer fra denne revision, og disse ændringer vil blive kasseret.

5.2.10 TortoiseSVN funktioner. Shell integration

TortoiseSVN integreres direkte i Windows-skallen (dvs. Explorer). Det betyder, at du kan arbejde med de værktøjer, du allerede er bekendt med, og ikke behøver at skifte til en anden applikation, hver gang du har brug for versionskontrolfunktioner!

Og du behøver ikke engang bruge Explorer. TortoiseSVN-kontekstmenuer fungerer i mange andre filhåndteringer, og i filen åbner dialoger, der bruges i de fleste standard Windows-applikationer. Du skal dog være opmærksom på, at TortoiseSVN oprindeligt er designet som en udvidelse til Windows Stifinder, og andre applikationer har muligvis ikke fuld integration, såsom ikonoverlejringer, der muligvis ikke vises.

Status for hver version af fil og mappe er angivet med et lille mærke øverst på hovedikonet. På denne måde kan du se status for din arbejdskopi med et øjeblik.

5.2.11 Grafisk brugergrænseflade

Når du ser en liste over ændringer til en fil eller mappe, kan du klikke på en revision for at se kommentarerne til den forpligtelse. En liste over ændrede filer er også tilgængelig - bare dobbeltklik på en fil for at se, hvilke specifikke ændringer der er foretaget.

Forpligtelsesdialogen er en liste, der viser alle de filer og mapper, der vil blive inkluderet i forpligtelsen. Hvert listeelement har et afkrydsningsfelt, så du kan vælge præcis, hvad du vil inkludere i commit. Uversionerede filer kan også være til stede på denne liste, så du ikke glemmer at tilføje en ny fil eller mappe til commit.

Alle Subversion-kommandoer er tilgængelige fra Explorer-kontekstmenuen. TortoiseSVN tilføjer sin egen undermenu der.

5.3 Mercurial

5.3.1 Systemkrav

P Mercurial-pakker er tilgængelige for alle populære operativsystemer: Windows, Mac OS, Linux (Ubuntu, Debian, Fedora, OpenSUSE, Gentoo), Solaris.

Den bedste version af Mercurial til Windows er TortoiseHg, som kan findes på http://tortoisehg.org. Denne pakke tillader kommandolinje og grafisk brugergrænseflade.

5.3.2 Koncept

Mercurial er et distribueret (decentraliseret) versionskontrolsystem. Det betyder, at arbejdsgangen typisk ser sådan ud:

1. Et nyt lager oprettes på en personlig computer (ved at klone et eksisterende lager, oprette et nyt osv.);

2. Filer ændres/tilføjes/slettes i arbejdsbiblioteket i dette lager;

3. Ændringer er forpligtet til dette lager (det vil sige til et lokalt lager på en personlig computer);

4. Trin 2 og 3 gentages så mange gange som nødvendigt;

5. Om nødvendigt synkroniseres ændringer med andre arkiver: andres ændringssæt trækkes og/eller deres egne skubbes.

Det er alt daglig arbejde sker i et lokalt depot, og når behovet opstår, sendes resultaterne af dets arbejde til et eller flere andre depoter. Du kan reducere antallet af trin, når du arbejder med eksterne lagre ved at indstille Mercurial til automatisk at skubbe ændringer til andre lagre, når du forpligter dig.

5.3.3 Kom godt i gang

Du kan arbejde i Mercurial gennem Explorer-kontekstmenuen, arbejdsområdevinduet TortoiseHg Workbench (programmet opretter en tilsvarende genvej under installationen) eller kommandolinjen ved hjælp af hg-kommandoen.

5.3.4 Oprettelse af et lager og arbejde med filer

I Mercurial sker alt inde i depotet. Projektlageret indeholder alle de filer, der er "relateret" til projektet, samt ændringshistorikken for disse filer. Der er tre forskellige måder at oprette et lager på.

For at oprette et arkiv gennem Stifinder-kontekstmenuen skal du blot højreklikke på den ønskede mappe og vælge det relevante element.

Figur 5.3.1 Oprettelse af et lager

I det vindue, der vises, kan du bekræfte placeringen af ​​depotmappen og åbne det oprettede depot i produktionsmiljøet.

Figur 5.3.2 Placering af arkivmappe

Depotet oprettes på lignende måde direkte i TortoiseHg Workbench-vinduet: sekvensen File\New Repository kalder ovenstående vindue frem med samme navn. På kommandolinjen skal du bruge hg init-kommandoen til at oprette et lager i den aktuelle mappe<имя хранилища>. Det oprettede lager vil indeholde en .hg-mappe.

Figur 5.3.3 Oprettelse af en depotmappe via kommandolinjen

Hvis vi ønsker at tilføje eksisterende filer til depotet, kopierer vi dem inde i arbejdsmappen og bruger hg add-kommandoen til at fortælle Mercurial om at begynde at overvåge dem. Lad os tilføje filen til depotet og oprette en ny revision.

Figur 5.3.4 Tilføjelse af en fil til depotet og oprettelse af en ny revision

Lad os sikre os, at Mercurial ser den gemte fil. Statuskommandoen viser status for arbejdskopien sammenlignet med status for det lokale lager. Mercurial viser, at den ser filen example.txt, men den fil er endnu ikke under versionskontrol (tegnet "?" til venstre for filnavnet). For at fortælle Mercurial, at det skal versioneres, kører vi hg add. Symbolet "A" vises til venstre for filnavnet, hvilket betyder, at readme.txt-filen vil blive tilføjet til versionskontrolsystemet under næste commit (når der oprettes en ny revision), som udføres med hg commit-kommandoen .

hg commit-kommandoen kan mislykkes første gang. Mercurial registrerer dit navn og din adresse ved hver revision, så du eller andre brugere kan kontakte forfatteren af ​​hver ændring. For at indstille brugernavnet skal du foretage ændringer i hgrc-filen, der findes i .hg-mappen inde i arbejdsmappen. Det oprindelige indhold af denne fil skulle se nogenlunde sådan ud:

# Dette er en Mercurial-konfigurationsfil.

brugernavn = Fornavn Efternavn [e-mail beskyttet]

Linjen "" erklærer en sektion konfigurationsfil. Du kan læse "brugernavn =..." som "indstil værdien af ​​brugernavnsvariablen i ui-sektionen". Afsnit fortsætter, indtil nye afsnit begynder. Tomme linjer og linjer, der starter med "#", ignoreres. Du kan bruge en hvilken som helst tekst som brugernavnsværdi, da denne information er beregnet til at andre mennesker kan bruge og ikke for Mercurial at fortolke. Eksemplet ovenfor brugte en fælles konvention for dette: en kombination af navn og e-mailadresse.

Når vi begår ændringerne, tager Mercurial os til tekst editor for at indtaste en kommentar, der beskriver de ændringer, vi har foretaget i dette ændringssæt. En sådan beskrivelse kaldes en ændringsmeddelelse (beskrivelse af ændringer, beskrivelse af revision). Dette vil være en rekord for læsere af, hvad vi gjorde og hvorfor, og vil blive udlæst, når vi kører hg-log, efter vi er færdige med at udgive revisionen.

Den editor, der åbner, når du kører hg commit, vil indeholde en tom linje og flere linjer, der starter med "HG:".

HG: Indtast commit besked. Linjer, der begynder med "HG:" fjernes.

HG: Lad beskeden være tom for at afbryde commit.

HG: --

HG: bruger: bruger

HG: branch "default"

HG: ændret eksempel.txt

Mercurial ignorerer linjer, der starter med "HG:". Den bruger dem kun til at fortælle os, hvilke filer den vil skrive ændringer til. Redigering eller sletning af disse linjer vil ikke påvirke noget. Hvis du ændrer mening om at udgive ændringer, mens du redigerer en kommentar, skal du blot afslutte editoren uden at gemme den fil, du ændrer. Dette vil ikke forårsage ændringer i hverken depotet eller arbejdsmappen.

Kommandoen hg log udskriver som standard kun den første linje i ændringsbeskrivelsen. Derfor er det bedre at skrive kommentaren, så den første linje er adskilt. Der er ingen faste regler for resten af ​​revisionsbeskrivelsen. Mercurial selv behandler eller bekymrer sig ikke om indholdet af ændringsmeddelelser, selvom dit projekt kan have regler, der dikterer bestemt formatering.

Lad os gentage disse operationer ved at bruge TortoiseHg Workbench GUI. Før du tilføjer filen til arbejdsmappen, ser vinduet sådan ud.

Figur 5.3.5 Tilføjelse af en fil til arbejdsmappen

Lad os overføre filen til depotet og opdatere vinduet ved at klikke på knappen til venstre på værktøjslinjen. Lad os tilføje filen til versionskontrolsystemet ved hjælp af den passende kontekstmenukommando (svarende til hg add).

Figur 5.3.6 Kommando i kontekstmenuen

Figur 5.3.7 Tilføjelse af en fil

Efter at filen er tilføjet, skrives en beskrivelse af revisionen i øverste højre vindue, og en ny revision oprettes ved at klikke på knappen "Bekræft". En registrering af de foretagne ændringer vises i nederste højre vindue. Du vil bemærke, at ændringerne er repræsenteret i form af grafer.

Figur 5.3.8 Ændring af grafer

Du kan også foretage ændringer ved at bruge Hg Commit-kommandoen i kontekstmenuen for en fil, der er placeret i depotet, uden at starte Workbench.

Figur 5.3.9 Forpligtelse til ændringer

Kommandoen hg log eller hg diff svarer her til "Sammenlign filrevisioner" (højreklik på filnavnet).

Figur 5.3.10 Sammenligning af filrevisioner

I samme vindue kan du vende tilbage til en af ​​de tidligere revisioner ved at bruge kommandoen "Return to revision..." eller "Revert changes..." i hovedvinduet. Lad os demonstrere med et eksempel, efter først at have registreret nogle flere ændringer i example.txt-filen. Linjen fremhævet med rødt er omvendte ændringer.

Figur 5.3.11 Annuller ændringer

5.3.5 Oprettelse af en kopi af depotet

Selvom du kan kopiere depotet som en normal mappe, er det bedre at bruge Mercurials indbyggede kommando. Det kaldes hg clone, fordi det skaber en identisk kopi af et eksisterende depot. En af fordelene ved at bruge hg clone er, at det giver dig mulighed for at klone repositories over netværket. En anden er, at den husker, hvor vi klonede den fra.

Hvert Mercurial-lager er komplet, selvstændigt og uafhængigt. Den indeholder sin egen kopi af projektfilerne og deres historie. Et klonet depot husker, hvor det blev klonet fra, men kommunikerer ikke med det depot eller noget andet, før du fortæller det. Derfor er du fri til at eksperimentere med dit lager. Dette er sikkert, fordi dit lager er en "lukket sandkasse", som ændringer ikke vil påvirke andet end sig selv.

Lad os oprette en fjernkopi af vores lager (vi bruger Google Drive-mappen, som i sig selv er en skytjeneste), for hvilken vi udfører sekvensen af ​​kommandoer File\Clone storage i TortoiseHg Workbench. Resultatet er vist i følgende figur.

Figur 5.3.12 Oprettelse af en fjernkopi af lageret

Mercurial giver os mulighed for at skubbe ændringer til et andet lager fra det lager, vi er i i øjeblikket. Lad os tilføje en ny revision (under den lokale ændringskommentar) til kildelageret og udføre kommandoen Storage\Synchronization\Push. Workbench-grænsefladen giver dig mulighed for kun at vælge de revisioner, der skal skubbes. Bemærk venligst, at en ny filial blev oprettet i remote-vault repository til den modtagne revision.

...

Lignende dokumenter

Muligheder for et versionskontrolsystem - et program designet til at arbejde med skiftende dokumenter. Dets egenskaber og brugspraksis. Intern organisation lagerfaciliteter. Arbejdskopi af versionerede dokumenter. Centraliseret og distribueret VCS.

præsentation, tilføjet 01/05/2014


Analyse af metoder og midler til adgangskontrol til filer. Sikkerhedsproblemer ved arbejde med filer, adgangskontrolværktøjer. Ideologi for interfacekonstruktion, arkitekturkrav. Drift af systemklasser. Estimering af omkostningerne ved et softwareprodukt.

afhandling, tilføjet 21-12-2012


Analyse af Windows 8 OS-arkitekturen. Sammenligning med tidligere versioner (Moderne brugergrænseflade, arbejde med konti, sikkerhedsmodel, opgavehåndtering, filhistorik, systemgendannelse, lagerpladser). Funktioner af forskellige Windows versioner 8.

kursusarbejde, tilføjet 25.01.2016


Udviklingsstadier automatiseret system modtage og bestille bordbestillinger i virksomheder. Analyse af Android Development Tools udviklingsmiljø. Generelle karakteristika for IOS-applikationskomponentdiagrammet. Overvejelse af serverversionskontrolsystemet.

kursusarbejde, tilføjet 14/05/2014


Grafiske grænseflader og udvidelser til DOS. Historien om udviklingen af ​​Microsoft Windows-operativsystemet. Innovationer af dens moderne versioner: brugergrænseflade, sprogintegration, sikkerhedssystemer. Kronologi for udvikling og arkitektur af GNU/Linux-systemet.

abstrakt, tilføjet 25/10/2010


DirectX-udviklingssæt til Microsoft Windows, karakteristika for sæt af COM-kompatible objekter i dets sammensætning. Nøglefunktioner i versioner, shader-sprog. Beskrivelse af de vigtigste anvendte funktioner. Programmets kildekode, eksempler på dets arbejde.

kursusarbejde, tilføjet 16/02/2015


Windows som en mellemmand mellem brugeren og operativsystemet, hvilket letter kommunikationsprocessen mellem dem, historien om dannelsen og udviklingen af ​​dens første versioner. Funktionelle funktioner og forskellene mellem Windows 95/98/ME og Windows NT/2000/XP/Vista/7, deres arkitektoniske løsninger.

præsentation, tilføjet 23.10.2013


Reduktion af omkostningerne ved reparationsarbejde for at eliminere defekter, der er opnået under brug informationssystem at kontrollere dem. Domæneanalyse og software. Beregning af besparelser på grund af øget brugerproduktivitet.

afhandling, tilføjet 19/01/2017


Koncept, essens, struktur og typer af operativsystemer. Karakteristika for Windows XP-operativsystemet, krav til dets installation, sammenlignende analyse af versioner, konfigurationsfunktioner, versionsopdateringer, installation af enhedsdrivere og tilføjelse af nye.

abstrakt, tilføjet 20/10/2009


Udseendet af de første versioner af Windows, deres grafiske grænseflader og udvidelser til DOS. Windows familier 3.x og Windows 9.x, deres funktioner og hovedfunktioner. Udviklingen af ​​Plug and Play-teknologi. De væsentligste forbedringer i moderne versioner Windows.