Versionhallintajärjestelmien yleiskatsaus. Gitin tärkeimmät ominaisuudet ja ominaisuudet. Gitiä käyttävä vakiotyönkulku näyttää suunnilleen tältä

Hajautettu versionhallintajärjestelmä Git. Osa 1

Johdanto

Sisältösarja:

1. Esittely

Työskennellessään projektin parissa sen osallistujat kohtaavat usein synkronoinnissa ja tiedostohistorian ylläpidossa ongelmia, joita versionhallintajärjestelmät (VCS) auttavat ratkaisemaan. Tämän artikkelisarjan tarkoituksena on esitellä lukija VMS:n toimintaperiaatteisiin ja tarkastella yksityiskohtaisesti yhtä niistä, nimittäin Gitiä. Miksi Git? SISÄÄN Viime aikoina tämä järjestelmä on saamassa suosiota, ja sen merkitystä vapaille ohjelmistoille (ja erityisesti GNU/Linux-projektille) ei voi yliarvioida.

Selvitämme peräkkäin yleisellä tasolla ohjausjärjestelmien ominaisuuksia, puhumme niiden arkkitehtuurista ja kyseessä olevan sovelluksen pääpiirteistä. Lisäksi tarkastelemme Gitin kanssa työskentelyä varten tällä hetkellä olemassa olevia käyttöliittymiä.

Kirjoittaja jättää tarkoituksella pois toimintojen terminologian, näppäimet ja muut hienoisuudet antaakseen sinulle selkeän, selkeän ja yleisen kuvan. Tässä artikkelissa oletetaan, että lukija tuntee Unix-tyyppiset käyttöjärjestelmät (OS) ja hänellä on myös perustiedot algoritmeista ja tietojenkäsittelytieteestä yleensä.

Seuraavissa materiaaleissa perehdymme Gitin rakenteeseen ja filosofiaan, tämän järjestelmän erityispiirteisiin ja hienouksiin käytännön työ hänen kanssaan. Jakson päättää artikkeli Gitin vuorovaikutuksesta muiden VCS:ien kanssa (kuten Subversion, CVS, Mercurial jne.).

2. Git on...

Git on hajautettu tiedostoversionhallintajärjestelmä. Ohjelmakoodi on kirjoitettu ensisijaisesti C-kielellä. Linus Torvalds loi projektin vuonna 2005 ohjaamaan kehitystä Linux-ytimet ja, kuten GNU/Linux, on ilmaista ohjelmistoa, johon sovelletaan kolmannen osapuolen käyttöä GNU-lisenssit GPL-versio 2. Lyhyesti sanottuna tätä sopimusta voidaan luonnehtia ilmaiseksi koodiohjelmistoksi, jota tulisi kehittää avoimesti, ts. jokaisella ohjelmoijalla on oikeus jatkaa projektin parantamista missä tahansa vaiheessa. Lyhyen olemassaolonsa aikana tämä järjestelmä monet johtavat kehittäjät ovat ottaneet käyttöön. Gitiä käytetään sellaisissa Linux-yhteisön tuntemissa projekteissa kuin Gnome, GNU Core Utilities, VLC, Cairo, Perl, Chromium, Wine.

3. Versionhallintajärjestelmät

Versionhallintajärjestelmät ovat ohjelmistoja, jotka on suunniteltu automatisoimaan tiedoston (tai tiedostoryhmän) historian kanssa työskentelyä, seuraamaan muutoksia, synkronoimaan tietoja ja järjestämään projektin suojattua tallennusta. Lyhyesti sanottuna versionhallintajärjestelmien päätarkoitus on helpottaa muuttuvien tietojen käsittelyä. Selvitetään se yleinen muoto kehitystä esimerkin kautta.

Oletetaan, että olet kehittämässä projektia, useita ohjelmoijien osastoja ja olet koordinaattori (tai johtaja). Ohjausjärjestelmään liittyen, olipa kyseessä palvelin (jos me puhumme keskitetystä järjestelmästä) tai paikallisesta koneesta, ketä tahansa projektin kehittäjää rajoittavat vain käyttöoikeudet muuttaa ja/tai lukea tiedostoversioita tästä arkistosta. Voit milloin tahansa palauttaa tiedot tarvitsemaasi versioon. Koordinaattorina voit rajoittaa pääsyn tiettyihin käyttäjiin päivittääksesi tiedostoversion. SUV tarjoaa myös käyttöliittymän tiedostoversioiden seurantaan ja etsimiseen. Voit esimerkiksi luoda kyselyn: "Missä ja milloin tämä koodinpätkä muutettiin?"

Järjestelmä olettaa turvallisen tiedon tallennuksen, ts. missä tahansa siihen tallennetussa lohkossa on monia klooneja. Joten esimerkiksi jos tiedosto on vaurioitunut, voit korvata sen viipymättä kopiolla. Projektitietojen määrän vähentämiseksi käytetään usein deltapakkausta - tallennustyyppiä, johon ei tallenneta itse tiedostoversioita, vaan vain muutoksia peräkkäisten versioiden välillä.

4. Erot hajautettujen versionhallintajärjestelmien välillä

Hajautetut versionhallintajärjestelmät ovat VCS:itä, joiden pääparadigma on datan lokalisointi kullekin projektin kehittäjälle. Toisin sanoen, jos keskitetyissä katumaastureissa kaikki toiminnot, tavalla tai toisella, riippuvat keskusobjektista (palvelimesta), niin hajautetuissa katumaastureissa jokainen kehittäjä tallentaa oman haaransa versioista koko projektista. Tällaisen järjestelmän mukavuus on, että jokaisella kehittäjällä on mahdollisuus työskennellä itsenäisesti vaihtaen ajoittain tiedostojen väliversioita muiden projektin osallistujien kanssa. Katsotaanpa tätä ominaisuutta jatkaen edellistä esimerkkiä.

Jokaisella kehittäjällä on oma paikallinen arkisto koneessaan - paikka tiedostoversioiden tallentamiseen. Projektitietojen kanssa työskentely tapahtuu paikallisessa arkistossasi, eikä sitä varten tarvitse pitää yhteyttä muihin (edes pääasiallisiin) kehityshaaroihin. Viestintä muiden tietovarastojen kanssa tarvitaan vain, kun muutetaan/luetaan muiden haarojen tiedostojen versioita. Tässä tapauksessa jokainen projektin osallistuja asettaa omalle tallennustilalleen luku- ja kirjoitusoikeudet. Siten kaikki hajautettujen katumaasturien haarat ovat samanarvoisia toistensa kanssa, ja päähaarat allokoi koordinaattori. Ainoa ero päähaarojen välillä on se, että kehittäjät katsovat sitä henkisesti ylöspäin.

5. Gitin pääominaisuudet ja ominaisuudet

On syytä sanoa, että järjestelmä, jos se ei tehnyt roiskeita, herätti hieman yhteisöä SUV-alalla uutuudellaan ja ehdotti uutta kehityspolkua. Git tarjoaa joustavia ja helppokäyttöisiä työkaluja projektihistorian ylläpitämiseen.

Gitin erityispiirre on, että projektiversioiden käsittely ei välttämättä tapahdu kronologisessa järjestyksessä. Kehitystä voidaan toteuttaa useissa rinnakkaisissa haaroissa, jotka voivat sulautua ja jakautua milloin tahansa suunnitteluprosessin aikana.

Git on melko joustava järjestelmä, ja sen soveltamisala ei rajoitu pelkästään kehittämiseen. Esimerkiksi toimittajat, teknisen kirjallisuuden kirjoittajat, hallintovirkailijat ja yliopiston opettajat voivat hyvin käyttää sitä työssään. Näihin tehtäviin kuuluu minkä tahansa dokumentaation, raportin tai kotitehtävän versionhallinta.

Korostetaan tärkeimmät erot Gitin ja muiden hajautettujen ja keskitettyjen hallintajärjestelmien välillä.

Git-arkkitehtuuri

SHA1 (Secure Hash Algorithm 1) on kryptografinen hajautusalgoritmi. Jokainen Git-projektitiedosto koostuu nimestä ja sisällöstä. Nimi on ensimmäiset 20 tavua dataa, se on kirjoitettu selvästi 40 merkillä heksadesimaalilukujärjestelmässä. Tämä avain saatu tiivistämällä tiedoston sisältö. Joten esimerkiksi vertaamalla kahta nimeä voimme melkein sataprosenttisella todennäköisyydellä sanoa, että niillä on sama sisältö. Myös eri haaroissa (varastoissa) olevien identtisten objektien nimet ovat samat, mikä mahdollistaa tietojen käytön suoraan. Hyvä lisä yllä olevaan on se, että hashin avulla voit määrittää tarkasti, ovatko tiedostot vaurioituneet. Esimerkiksi vertaamalla sisällön hajautusarvoa nimeen, voimme varsin tarkasti sanoa, ovatko tiedot vioittuneet vai ei. Seuraavassa nimellä tarkoitamme tiedoston nimeä ja merkkijonoa kutsutaan nimellä SHA1 hash.

On syytä mainita niin sanotut törmäykset. "Melko tarkasti määrittää vahinko" tarkoittaa, että on tiedostoja, jotka ovat sisällöltään erilaisia, joiden SHA1-tiiviste on sama. Tällaisten törmäysten todennäköisyys on hyvin pieni, ja alustavan arvion mukaan se on yhtä suuri kuin 2 -80. potenssiin (~ 10 -25. potenssiin). Tarkkaa arviota ei ole, koska kansainvälinen yhteisö ei ole tällä hetkellä kyennyt tulkitsemaan tätä salausjärjestelmää tehokkaasti.

Git Objects

Tiedostoversioiden käsittelyä Gitissä voidaan verrata tiedostojärjestelmän normaaleihin toimintoihin. Rakenne koostuu neljästä objektityypistä: Blob, Tree, Commit ja References; osa niistä puolestaan ​​on jaettu osaobjekteihin.

Blob (Binary Large Object) on tietotyyppi, joka sisältää vain tiedoston sisällön ja oman SHA1-tiivisteensä. Blob on tärkein ja ainoa tietoväline Git-rakenteessa. Tämän objektin ja tiedostojärjestelmien inodien välille voidaan vetää rinnakkaisuus, koska niiden rakenne ja tarkoitus ovat suurelta osin samanlaiset.

Puu

• oma SHA1 hash;
• SHA1-hajautus möykkyistä ja/tai puista;
• Unix-järjestelmien käyttöoikeudet;
• objektin symbolinen nimi (nimi järjestelmän sisäiseen käyttöön).

Ytimestään objekti on analoginen hakemiston kanssa. Se määrittää projektitiedostojen hierarkian.

Tehdä– tietotyyppi, joka sisältää:

• oma SHA1 hash;
• linkki täsmälleen yhteen puuhun;
• linkki edelliseen sitoumukseen (niitä voi olla useita);
• tekijän nimi ja sitoumuksen luomisaika;
• toimeksiantajan nimi (toimittaja on henkilö, joka on tehnyt sitoumuksen arkistoon; hän voi poiketa tekijästä) ja sitoumuksen tekoaika;
• mielivaltainen tieto (lohkoa voidaan käyttää sähköiseen allekirjoitukseen tai esimerkiksi sitoumusmuutosten selittämiseen).

Tämä objekti on suunniteltu tallentamaan tilannekuvan (version) tiedostoryhmästä tietyllä hetkellä. Voit verrata sitä tarkistuspisteeseen. Toimitukset voidaan yhdistää, haaroittaa tai esimerkiksi asettaa lineaariseen rakenteeseen, mikä heijastaa projektiversioiden hierarkiaa.

Viittaus on tietotyyppi, joka sisältää viittauksen mihin tahansa neljästä objektista (Blob, Tree, Commit ja References). Sen päätarkoitus on viitata suoraan tai epäsuorasti kohteeseen ja olla synonyymi tiedostolle, johon se viittaa. Tämä lisää ymmärrystä projektin rakenteesta. On erittäin hankalaa käyttää nimessä merkityksetöntä merkkijoukkoa, toisin kuin SHA1-hash, se voidaan nimetä kehittäjälle sopivalla tavalla.

Linkeistä voimme puolestaan ​​erottaa joukon aliobjekteja, joilla on joitain eroja: Haara, Tag. Katsotaanpa niitä.

Haara (pää, haara)– symbolinen linkki, joka osoittaa viimeiseen sitoutumiseen tietyn haaran kronologiassa ja tallentaa kohteen SHA1-hajautusarvon. On päiväkirjattujen tiedostojärjestelmien tietotyyppi. Tämä tyyppi objektia ei ole määritelty itse Gitissä, vaan se peritään käyttö- ja tiedostojärjestelmistä. Haaraa käytetään synonyyminä tiedostolle, johon se viittaa, ts. Gitin avulla voit käyttää sitä suoraan. Sinulla on varaa olla ajattelematta, käytätkö uusinta versiota vai et.

Tag– tietotyyppi, joka toisin kuin haarat viittaa aina samaan objektiin, jonka tyyppi on blob, puu, commit tai tag. Se puolestaan ​​voidaan jakaa kevyeen (kevyt tunniste) ja raskaaseen tai huomautettuun (merkitty tunniste). Kevyt tunniste, lukuun ottamatta linkin muuttumattomuutta, ei eroa tavallisista haaroista, ts. sisältää vain viitatun objektin SHA1-tiivisteen itsessään. Annotoitu tunniste koostuu kahdesta osasta:

• ensimmäinen osa sisältää oman SHA1-tiivisteensä;
• toinen osa koostuu:
  • Annotoidun tunnisteen osoittaman objektin SHA1;
  • viitatun objektin tyyppi (blob, puu, commit tai tag);
  • symbolinen tunnisteen nimi;
  • tunnisteen luomispäivämäärä ja -aika;
  • tunnisteen luojan nimi ja sähköpostiosoite;
  • mielivaltainen tieto ( tämä lohko voidaan käyttää sähköiseen allekirjoitukseen tai tunnisteen selittämiseen).

Toisin sanoen projekti Gitissä on joukko blobeja, jotka on yhdistetty puiden verkostolla. Tuloksena oleva hierarkkinen rakenne voi ajasta riippuen heijastua committe -versioina, ja niiden rakenteen ymmärtämiseksi Git sisältää objekteja, kuten linkkejä. Lukuun ottamatta linkeillä tehtyjä toimia, lähes kaikki työ järjestelmäobjektien kanssa on mahdollisimman pitkälle automatisoitu sisältä käsin. Linkkimekanismista alkaen pääsemme seuraavaan ajatukseen - työskennellä erityisesti tiedostoryhmien parissa. Kirjoittajan mukaan ajatus on Git-filosofian avain. Määritettyään esimerkiksi toiminnon tietylle toimitukselle, se laskee rekursiivisesti osansa puuta pitkin, johon se viittaa. Laajennus yleisesti hyväksytylle "toiminto jokaiselle tiedostolle" -näkymään, innovaatio yksinkertaistaa ohjelmoijan toteuttamista ja lähestymistapaa päivittäisiin VCS-tehtäviin, kuten haarojen yhdistämiseen/jakamiseen, mikä taas automatisoi prosessin rekursiivisesti. Tämä lähestymistapa on helppo ymmärtää, toimii nopeasti ja on joustava tavoitteidensa saavuttamisessa. Monet näistä ominaisuuksista saavutetaan järjestelmän Unix-suuntautuneisuuden ansiosta, ts. Git käyttää vakiolaitteita ja luottaa niihin, jotka ovat jo saatavilla käyttöjärjestelmä ratkaisuja.

Selvitetään tietojen tallennushetki. Eri versioiden tiedostojen sisältö kronologiassa vie melko paljon muistia. Joten esimerkiksi projektissa, jossa on kaksikymmentä tiedostoa ja kaksikymmentä versiota, arkisto painaa 20 kertaa enemmän (ehkä noin sata megatavua), mutta mitä tapahtuu, jos molempien määrä on 10 kertaa suurempi (se ei näytä olevan paljon)? Varatun tilan koko kasvaa 100-kertaiseksi (eli noin 1 Gt). Todellisissa ongelmissa varatun muistin kasvunopeus ei ole kaukana lineaarisesti ajasta riippuvainen. Tämän ongelman ratkaisemiseksi on useita optimointeja:

• jokainen Git-objekti tallennetaan tavallisena arkistona (tar.gz);
• Jaksottaista deltapakkausta sovelletaan koko tiedostohierarkiaan.

Katsotaanpa sitä esimerkin avulla.

Sinulla on projektistasi kolmen vuoden historia, noin tuhat tiedostoa ja sata versiota. Jos jossain vaiheessa pitää ottaa yhteyttä itseensä varhainen versio, Gitin on delta-pakkattava koko tiedoston historia. Pettymys, mutta Tämä prosessi Se voi kestää puoleenpäivään asti. Git tarjoaa ns. tarkistuspisteitä, ts. tallentaa ei-arkistoidun tiedoston tietyn version kautta, jota kutsumme pakkaussyvyydeksi. Sitten esimerkissämme koko historia kavennetaan tiettyyn ennalta määrättyyn deltapakkausten määrään, jonka purkaminen voidaan katsoa mitä tahansa versiota kronologisesti. Huomaa, että on suositeltavaa käyttää delta-pakkausta tietyntyyppisille objekteille, jotka ovat lähimpänä hierarkiassa. Tätä varten arkisto on lajiteltava tyypin ja koon mukaan. Tämä sarja Tässä kappaleessa kuvatut toiminnot suorittaa git-repack-funktio (ja sen sisältävä git-gc).

Haarojen yhdistäminen ja halkaisu

Tämä kysymys on erittäin työvoimavaltainen ja intensiivinen, ja siksi esittelemme sulautumisen ja erottamisen käsitteet vain yleisesti. Katsotaanpa esimerkkiä uudelleen.

Kuvitellaanpa projektikehityksen hetki, jolloin päätavoitteena on ohjelman nopeus. Yksi mahdollinen taktinen ratkaisu on jakaa kehittäjät kahteen ryhmään, joista kukin ratkaisee saman ongelman. Tässä tapauksessa hankkeen historian haaran tulisi jakautua kahtia. Tämä menettely kutsutaan haaraksi. Haaroittamisen toiminta on yksinkertaisesti kopion luomista siitä, jolla on myöhemmin oma historiansa.

Oletetaan, että saimme kaksi jo suoritettua tulosta samasta tehtävästä, joiden parissa työskenteli kaksi ohjelmoijaryhmää. Mitä meidän pitäisi tehdä? Katso, kenen koodi on nopeampi ja luotettavampi? Se on liian yksinkertainen, mutta ei aina paras ratkaisu. Hyvä ratkaisu on ymmärtää koodia ja tiedostoja hieman ja jakaa ne alitehtäviin tai koodilohkoihin. Ja vasta sitten voimme tunnistaa vahvuudet ja heikkoja puolia näistä palasista. Tämä vaihtoehto sopii tietysti vain, jos olet ennakoinut etukäteen, että pystyt myöhemmin keräämään kaikki nämä hiukkaset yhteen. Tapaus, jossa kehität koodin itse, parannat ja korjaat joitain virheitä, vastaa annettua esimerkkiä. Tätä prosessia, jossa kaksi kokonaisuutta yhdistetään yhdeksi, kutsutaan sulautumiseksi. Kahden version yhdistäminen on projektinhallinnan avainhetki. Oli miten oli, sinun tulee välttää tämän toiminnon automaattista suorittamista. Erottuva ominaisuus Git on luotettavin ja oikeudenmukaisin nopea tapa haarautumisongelman ratkaiseminen.

Järjestelmän etuja ovat mm.

1. Unix-suuntautunut.
2. Ideologinen johdonmukaisuus (järjestelmän käyttösääntöjä noudattaen on erittäin vaikea päästä sisään toivoton tilanne tai saat jotain, jota et odottanut).
3. Korkea suorituskyky (tämä on yksi järjestelmän ilmeisimmistä eduista, jonka hinta on "ideologinen johdonmukaisuus" ja "Unix-suuntautuneisuus").
4. Gitin integrointi kolmannen osapuolen järjestelmiin, kuten Subversion, Mercurial, ...
5. Tiedostoryhmän hallinta (järjestelmän ei tarvitse huomioida muutoksia jokaisessa tiedostossa erikseen, se muistaa kaikki muutokset koko projektissa ja jos yhtäkkiä joudut seuraamaan yksittäisiä muutoksia, se näyttää tarkalleen osan, joka liittyy tähän tiedostoon ).
6. Yhdistämistoiminto (monimutkaisen tehtävän maksimaalinen automaattinen toteutus).

Haittoja ovat mm.

1. Unix-suuntautunut (on syytä huomata, että muissa kuin Unix-järjestelmissä ei ole kypsää Git-toteutusta).
2. Tarve suorittaa ajoittain git-gc-komento (pakkaa tiedostoryhmiä ja poistaa ne, joita ei ole linkitetty linkeillä).
3. Hash-törmäykset (vastaavat erisisältöisten tiedostojen SHA1-tiivisteitä).

6. Git-liitännät

"Kuinka monta ihmistä, niin monta mielipidettä." Yritetään korostaa useita erityyppisiä käyttöliittymiä järjestelmän kanssa työskentelemiseen. Tiettyihin tarkoituksiin jokainen seuraavista sovelluksista on parempi omalla tavallaan.

Ihmisille, jotka eivät ole läheisesti mukana kehityksessä, "konservatiiveille" - niille, jotka rakastavat "painikkeita ja valintamerkkejä" ja haluavat tietoisesti suojautua äärimmäisiltä ponnisteluilta muistaa toiminnot, näppäimet ja monet hienovaraisuudet, vaihtoehto TortoiseGit-tyyliin tai Git Extensions on sopivampi - yksinkertaiset käyttöliittymät. Niiden avulla voit toimia ensisijaisesti hiirellä ja työskennellä monille tutussa Windows-käyttöjärjestelmässä.

Täsmälleen päinvastainen käyttöliittymä. Ohjelmoijille, joiden on jatkuvasti oltava vuorovaikutuksessa työntekijöiden kanssa ja ratkaistava tyypillisiä koodinhallintaongelmia, ihmisille, jotka ovat tottuneet työskentelemään Unix-tyyppisissä järjestelmissä päätelaitteen avulla, konsolityyppinen sovellus sopii parhaiten. Ne ovat yhtä helppokäyttöisiä, hieman nopeampia ja toimivampia, mutta niiden käytön selvittäminen vie jonkin aikaa.

Kolmas käyttöliittymätyyppi voidaan erottaa – kahden ensimmäisen yhdistelmä. Nuo. sinulla on konsolisovellus, kuten natiivi git-kuori. Voit käyttää useita lisäapuohjelmia, kuten Gitk tai QGit, näyttääksesi puita, yksinkertaistaaksesi versiohierarkian yleiskatsausta, versioiden välisiä eroja ja löytääksesi tarvitsemasi objektit.

Onko sinulla hieno uusi liiketoimintaidea liittyen ohjelmistokehitykseen?Sinun täytyy kehittyä teknologisesti vaikea päätös? Vai onko sinulla suuri joukko ohjelmoijia, jotka työskentelevät saman tehtävän parissa? Muista sitten nämä kolme sanaa:versionhallintajärjestelmä .

Versionhallintajärjestelmä (cvs), 2017 - Vertaa: Git, SVN, Mercurial

, tai vcs- tämä estää projektia hajoamasta, kun sen parissa työskentelee paljon ihmisiä. Ohjelmoijat, johtajat, tekstinkirjoittajat voivat työskennellä kukin oman kappaleensa parissa häiritsemättä toisiaan ja aiheuttamatta vahinkoa, jota ei voitu korjata.

Jos et ole vielä perehtynyt käsitteeseenversionhallintajärjestelmät, sitten täällä kaikki näkyy hyvin selvästi.

Tai katso video GitHubista.

Joten mikä versionhallintajärjestelmä sopii projektiisi?

Vertasimme useita suosittuja ratkaisuja helpottaaksemme valinnan tekemistä.

Tämä on erittäin erikoistunut tekninen aihe. Olemme yrittäneet tehdä arviomme ymmärrettäväksi kaikille. Mutta jos sinulla ei ole ohjelmointikokemusta, muista neuvotella kehitysosastosi kanssa ennen päätösten tekemistä.

Versionhallintajärjestelmät, mukaan lukien tunnetut SVN (Subversion) ja Git, luotiin alun perin mahdollistamaan kehittäjäryhmien työskentely yhteistyöprojekteissa ilman sekaannusta. Ohjausjärjestelmässä sinun ei tarvitse itsenäisesti seurata koodihaaroja ja tutkia niihin liittyviä muistiinpanoja. Sen sijaan käytetään keskusvarastoa, jossa kaikki on järjestetty ja jäsennelty. Täällä on kätevää päivittää tiedostoja, lisätä kommentteja ja jopa yhdistää projektihaaroja.

Mielipiteitä mistäversionhallintajärjestelmäparas vaihtelee suuresti, ja tämä johtaa kiihkeään keskusteluun ohjelmoijien kesken. Valinta ja opiskeluversionhallintajärjestelmätMuista projektissasi, että tietyn ratkaisun hyödyt ovat usein subjektiivisia. Esimerkiksi ohjelmoijan henkilökohtaiset mieltymykset tai esimerkiksi indikaattorit, kuten suorituskyky, IDE-laajennusten ominaisuudet jne.

Suurin ero versionhallintajärjestelmien välillä on, ovatko ne asiakaspalvelin- vai hajautettuja (p2p). Onko heillä keskusvarasto (palvelin), josta koodi otetaan ja jonne se palautetaan tehtyjen muutosten kanssa. Tai se on kopio paikallisessa tallennustilassa, jota päivitetään vertaisverkkojen kautta: hajautetumpi verkko, jota käytetään synkronointiin, korjaustiedostojen (muutossarjojen) jakamiseen ja nykyisen koodin ylläpitämiseen.

On myös syytä ottaa huomioon tietyn kohteen nopeus, toiminnallisuus ja kynnys sisäänpääsyyn/hallintaan.ohjausjärjestelmät. Katsotaanpa yleisimpiäversionhallintajärjestelmätja syyt, miksi ohjelmoijat suosivat tiettyjä ratkaisuja.

Samanaikainen versiojärjestelmä (CVS)

CVS ilmestyi 1980-luvulla ja on edelleen suosittu sekä kaupallisten tuotekehittäjien että avoimen lähdekoodin kehittäjien keskuudessa.

CVS jaetaan ehtojen mukaisestiGNU Open License Agreement ja antaa sinun noutaa palvelimelta vaadittava versio projekti -"uloskirjautuminen" (ote) ja lähetä se sitten takaisin palvelimelle,check-in" (paluu),tehtyjen muutosten kanssa.

Alunperin CVS luotiin versioristiriitojen välttämiseksi. Kaikille osallistujille toimitettiin vain uusin versio koodista käytettäväksi. Tämä oli ensimmäinen versionhallintajärjestelmä. Käyttäjän täytyi nopeasti tehdä muutoksia arkistoon ennen kuin muut lyövät hänet siihen.

Nyt CVS tukee koodihaaroja sisältävien projektien työskentelyä. Tämä johtaa useisiin tuotevaihtoehtoihin erilaisia ​​ominaisuuksia, joita voidaan yhdistää myöhemmin.

CVS-palvelimet toimii yleensä Unixin alla, mutta CVS -asiakkaat ovat saatavilla myös muissa suosituissa käyttöjärjestelmissä. CVS - "kypsä", aika-testattuversionhallintajärjestelmä. Se on edelleen avoimen lähdekoodin järjestelmä, mutta nykyään uusia ominaisuuksia lisätään melko harvoin.

Samalla CVSNT on erilliseksi projektiksi erotettu versio CVS varten Windows-palvelimet, - laajentaa nyt melko aktiivisesti toimintojaan.

Edut:

• Ajan testattu tekniikka, joka on ollut markkinoilla vuosikymmeniä.

Vikoja:

• Tiedostojen uudelleennimeäminen tai siirtäminen ei näy historiassa
• Tietoturvariskit, jotka liittyvät tiedostoihin johtaviin symbolisiin linkkeihin
• Ei tukea atomioperaatioille, mikä voi johtaa koodin korruptioon
• Toiminnot ohjelmakoodihaaroilla ovat kalliita, koska tämäohjausjärjestelmäei ole tarkoitettu pitkäaikaisiin projekteihin, joissa on koodihaaroja

Apache Subversion (SVN)

SVN luotiin vaihtoehtona CVS puutteiden korjaamiseksi CVS ja samalla varmistaa korkea yhteensopivuus sen kanssa.

Kuten CVS SVN on ilmainen järjestelmä versionhallinta avoin lähdekoodi. Ainoa ero on, että sitä jaetaan Apache-lisenssillä, eiGNU:n julkisen lisenssisopimuksen mukaisesti.

Tietokannan eheyden ylläpitämiseksi SVN käyttää niin kutsuttuja atomioperaatioita. Kun uusi versio Joko kaikkia korjauksia tai ei mitään korjauksia sovelletaan lopputuotteeseen. Siten koodi on suojattu kaoottisilta osittaisilta muokkauksilta, jotka ovat ristiriidassa keskenään ja aiheuttavat virheitä.

Monet kehittäjät ovat vaihtaneetSVN koska uusi teknologia perinyt parempia mahdollisuuksia CVS ja samalla laajentanut niitä.

CVS:ssä ollessaan toiminnot koodihaaroilla ovat kalliita, eikä niitä ole järjestelmäarkkitehtuurissa. SVN on luotu juuri tätä varten. Eli lisää suuria hankkeita koodihaaroituksella ja monilla kehityssuunnilla.

SVN:n haittoja ovat suhteellisen hidas nopeus ja hajautetun versionhallinnan puute. Hajautettu versionhallinta käyttää peer-to-peer-mallia keskitetyn palvelimen sijaan ohjelmistokoodipäivitysten tallentamiseen. Ja vaikka peer-to-peer-malli toimii paremmin avoimen lähdekoodin projekteissa, se ei ole ihanteellinen muissa tapauksissa. Palvelinpuolen lähestymistavan haittana on, että kun palvelin kaatuu, asiakkaat eivät pääse käsiksi koodiin.

Edut:

• Järjestelmäpohjainen CVS
• Mahdollistaa atomioperaatiot
• Koodihaaroitustoiminnot ovat halvempia
• Laaja valikoima IDE-laajennuksia
• Ei käytä vertaismallia

Vikoja:

• Virheet jatkuvat edelleen liittyvät tiedostojen ja hakemistojen uudelleennimeämiseen
• Epätyydyttävä komentosarja arkiston kanssa työskentelyä varten
• Suhteellisen alhainen nopeus

Git

Tämä järjestelmä luotiin hallitsemaan Linux-ytimen kehitystä ja käyttää lähestymistapaa, joka on täysin erilainen kuin CVS ja SVN.

Perusta Git käsitteet määriteltiin nopeamman jakelun luomiseksiversionhallintajärjestelmä, toisin kuin kohdassa käytetyt säännöt ja ratkaisut CVS . Koska Git kehitettiin ensisijaisesti Linuxille, se toimii nopeimmin tällä käyttöjärjestelmällä.

Git toimii myös Unixin kaltaiset järjestelmät(kuten MacOS) ja työskentelyyn Windows-alusta mSysGit-pakettia käytetään.

Ohjelmakoodi ei ehkä ole käytettävissä käytettäessä tietokonetta ilman arkistoa. Tähän ongelmaan on ratkaisuja, ja jotkut kehittäjät uskovat, että Gitin nopeus on kohtuullinen hinta vaivasta maksettavaksi.

Gitissä on myös monia työkaluja muutoshistorian navigointiin. Jokainen lähdekoodin työkopio sisältää koko kehityshistorian, mikä on erittäin hyödyllistä ohjelmoitaessa ilman Internet-yhteyttä.

Edut:

• Erinomainen niille, jotka vihaavat CVS/SVN
• Merkittävä suorituskyvyn kasvu
• Halvat toiminnot koodihaaroilla
• Koko kehityshistoria saatavilla offline-tilassa
• Hajautettu, vertaisverkkomalli

Vikoja:

• Korkea markkinoille pääsyn (oppimisen) este niille, jotka ovat aiemmin käyttäneet SVN:ää
• Rajoitettu Windowsin tuki(verrattuna Linuxiin)

Oikukas

Oikukas julkaistiin samaan aikaan kuin Git. se on sama hajautettu versionhallintajärjestelmä.

Mercurial luotiin vaihtoehdoksi Gitille Linux-ydinmoduulien kehittämiseen. Mutta koska valitsimme Gitin, Mercurialia käytetään vähemmän. Kuitenkin monet johtavat kehittäjät työskentelevät esimerkiksi tämän järjestelmän kanssaOpenOffice.org .

Mercurialin versionhallintajärjestelmä eroaa muistaversionhallintajärjestelmätkoska se on kirjoitettu pääasiassa Pythonilla (ei C:llä). Jotkut osat on kuitenkin toteutettu laajennusmoduuleina C:ssä.

Koska järjestelmä on hajautettu ja kirjoitettu Pythonilla, monet Python-ohjelmoijat ovat taipuvaisia ​​vaihtamaan Mercurialiin.

Käyttäjät huomauttavat, että Mercurial säilyttää osan SVN:n ominaisuuksista, vaikka se on hajautettu järjestelmä, ja tämän samankaltaisuuden vuoksi sillä on alhaisempi pääsy SVN:n jo tunteville. Mercurialin dokumentaatio on myös kattavampi, mikä auttaa sinua tottumaan eroihin nopeammin.

Yksi Mercurialin merkittävistä haitoista on, että toisin kuin Git, se ei voi yhdistää kahta päähaaraa, koska Mercurial käyttää laajennusjärjestelmää komentosarjatuen sijaan. Tämä on hienoa joillekin ohjelmoijille, mutta monet eivät halua luopua Gitin voimasta.

Edut:

• Helpompi oppia Gitiin verrattuna
• Yksityiskohtainen dokumentaatio
• Hajautettu malliversionhallintajärjestelmät

Vikoja:

• Ei ole mahdollisuutta yhdistää kahta emohaaraa
• Käytä laajennuksia komentosarjojen sijaan
• Vähemmän mahdollisuuksia epätyypillisille ratkaisuille

Mikäversionhallinta toimii minulla?

Useimmissa tapauksissa kehittäjät käyttävät CVS koska se on heille tutumpaa. Jos tiimi työskentelee jo projektin parissa, on mahdollisuus siirtää kaikki kehitystyöt toiseenohjausjärjestelmäjotenkin ei inspiroi. Jos heidän täytyisi muuttaa järjestelmää, he todennäköisesti vaihtaisivat SVN:ään.

CVS on jo saavuttanut "kypsän teknologian" tilan, mikä tarkoittaa, että siihen ei enää ilmesty radikaalisti uusia ominaisuuksia ja ratkaisuja. Tavan vauhti katoaa ihmisten siirtyessä SVN:ään. Tämä tarkoittaa, että CVS:stä on vähitellen tulossa menneisyyttä.

Nykyään SVN on kämmenellä palvelinpalvelimien joukossaversionhallintajärjestelmät. Se sisältää edut CVS ja ylittää ne. Jos puhumme levinneisyydestä, kohtaat todennäköisesti useammin CVS tai SVN kuin Git tai Mercurial. Joten yhden palvelintekniikan tuntemus, vaikka se ei ole välttämätöntä, helpottaa siirtymistäsi.

Teknologian laajan käytön ja kypsyyden vuoksi SVN:llä on laaja tietokanta, joten käyttäjien on helppo saada apua.

Git on selvästi kilpailijoitaan nopeampi. Projekteille, jotka on luotu hajautettaviksiversionhallintajärjestelmät, tämä on selvä parannus.

Gitin merkittävä haitta on, että joskus on vaikea selittää sen toiminnan vivahteita.ohjausjärjestelmät, ja tämä hidastaa työnkulkua ohjelmoijien tottuessa siihen. Kuitenkin, kun "tulokynnys" on ylitetty, tuottavuus kasvaa ja koodihaarojen hallinnan mukavuus maksaa täysin käytetyn ajan.

Niille, jotka vihaavat Gitiä (ja sillä on kehujia kehittäjien keskuudessa), Mercurial on kompromissi SVN:n ja Gitin välillä. Tätä järjestelmää käytetään monissa tunnetuissa projekteissa ja sillä on myös hyvä dokumentaatio.

Myös Gitin Windows-yhteensopiva versio etenee kohti Linux-version nopeutta, joten se voi olla sinulle tärkeä, vaikka et kehitä Linuxilla.

Ymmärtääksesi, mikä on sinulle paras, ota huomioon projektin ja tiimisi ominaisuudet. Keskustele kehittäjien kanssa!

Jos projekti vaatii yhden lähdekoodipuun, jonka parissa työskentelee pieni ryhmä ohjelmoijia, SVN on vaihtoehtosi. Se on luotettava ja suunniteltu juuri tällaisiin tapauksiin.

Jos käynnistät avoimen lähdekoodin projektin, jossa useat ohjelmoijat työskentelevät eri aikoina tai jos aiot päivittää koodia jatkuvasti, valitse Git. Nopeus- ja lähdepuun hallinta on täällä paljon parempi kuin SVN:ssä.

Jos olet tienhaarassa tai et vain pidä tavasta, jolla SVN tai Git toimivat, Mercurial on sinua varten.

Kaikki nämä järjestelmät ovat täysin toimivia. Ja myös ilmainen. Niitä käytetään ohjelmistojen, verkkosivustojen ja jopa käyttämiesi ja tuntemiesi käyttöjärjestelmien luomiseen.

Ensinnäkin päätä, sopiiko jompikumpiohjausjärjestelmäversioita yrityksellesi, ja sitten - aivan yhtä tärkeää - varmista, että tämä valinta ei raivoa ohjelmoijia.

SVN:n käytön aloittaminen

Jos et ole koskaan työskennellyt SVN:n tai Gitin kanssa etkä tiedä, miten pääset alkuunhosting-ratkaisu yhdistettynä graafiseen käyttöliittymäänauttaa sinua tottumaan siihen nopeasti.

Kuten useimmissa tapauksissa, tärkeintä on aloittaa työ, ja sitten tulee ymmärrystä. Versionhallintajärjestelmän käyttäminen on hyvin samanlaista kuin tiedostojen käsittely palvelimella FTP-asiakasohjelmalla.

HUOMAUTUS:Isännöintiratkaisuja on moniaversionhallintajärjestelmät, mukaan lukien ilmainen koeaika. Voit luoda ensimmäisen arkiston (paikan, jossa voit tehdä yhteistyötä kooditiedostojen kanssa) niiden perusteella ilmaiseksi. Tässä on joitain näistä palveluista:

SVN & GIT hosting

Ensimmäisen arkiston luominen

Kun olet luonut tilin, sinun on luotava arkisto - jokaiselle alustalle erikseen. Se näyttää yleensä tältä:

• Kirjaudu tilillesi, napsauta projektejasi.
• Projektin luominen:

• Kirjoita "Luo uusi projekti" -riville projektisi nimi
• Napsauta "Luo projekti" -painiketta

• SVN-yhteys:

• Kun olet luonut projektin, valitse "Source Control" -välilehti (lähdekoodiversiot)
• Napsauta linkkiä "Ota lähdehallinta käyttöön"
• Anna arkistolle nimi
• Napsauta "Tallenna"

Graafiset asiakkaat SVN ja GIT

Joten arkisto on luotu. Nyt tarvitsemme kaiken näkyvän siinä yksinkertaisesti ja selkeästi. Tätä varten tarvitset graafisen käyttöliittymän.

— kätevä ohjelma työskennellä jonkun kanssaversionhallintajärjestelmätMicrosoft Windowsissa ja ehkä parhaassa saatavilla olevassa Apache Subversion -asiakasohjelmassa. TortoiseSVN on toteutettu Windowsin kuorilaajennuksena, joten se on helppo integroida selain. Se on myös avoimen lähdekoodin ohjelma, jossa on saatavilla 34 kielipakettia

SmartGit

- Git graafinen asiakas ( Avoin lähdekoodi hajautettuversionhallintajärjestelmä). Toimii Windowsissa, Mac OS X:ssä ja Linuxissa.Lisenssin hinta - 39 dollaria

"Tarkistaa" arkiston ("Tarkista")

Asiakas on siis valittu. Nyt sinun on luotava arkisto ohjausjärjestelmälle. Pitää päästä sisäänArkiston URL-osoite, käyttäjätunnus ja salasana.

URL-osoite näyttää yleensä tältä:https://svn .hostname.com/svn/ > (voit käyttää https:// (SSL), jos sinulla on maksullinen tili)

1. Mene juurikansioon, napsauta Check Out -painiketta ja luo työkansio asiakkaalle. Nyt voit lisätä siihen tiedostoja.
2. Kun projektitiedostot on purettu, voit muokata niitä tietokoneesi paikallisessa hakemistossa.

Kun olet tehnyt muutoksia tiedostoihin, napsauta työkalupalkin Check-in-painiketta tallentaaksesi ne. Voit tarkastella muutoksia ja lisätä niihin kommentteja - tämä on hyvä idea, sillä tiedät jatkossa tarkalleen, mitä olet työstänyt, mitä muutoksia on tehty ja pidät muut projektiin osallistujat ajan tasalla.

Asiakkaasi tulee myös tarjota mahdollisuus aloittaa versioiden käsittely milloin tahansa avaamalla versiolokin tai muutoshistorian - sitten voit tarvittaessa "palata" kunkin tiedoston edelliseen versioon erikseen. Nyt kun olet perehtynyt peruskäsitteisiin, dokumentaatioon

VCS:n perusteet

Johdanto

Ennen kuin puhutaan mistään erityinen järjestelmä versionhallinta, sinun on ymmärrettävä, mitä ne ovat, mitä ne ovat ja miksi ne alun perin ilmestyivät. Tämän luennon tarkoituksena on antaa alustava johdatus versionhallintaan ja versionhallintajärjestelmiin, ja ensin kerron versionhallintatyökalujen alkuperästä, mitkä versionhallintajärjestelmät ovat tällä hetkellä suosittuja ja mitkä ovat niiden tärkeimmät erot.

Tietoja versionhallinnasta

Mikä on versionhallinta ja miksi tarvitset sitä?

Varmaan kannattaa aloittaa versionhallintajärjestelmän (VCS) määrittelystä – tämä on järjestelmä, joka tallentaa muutokset yhteen tai useampaan tiedostoon, jotta tulevaisuudessa on mahdollista palata tiettyihin vanhoihin versioihin näistä tiedostoista.

Viime aikoina tiedostot ovat lopputulos monille ammateille (esimerkiksi kirjoittaminen, tieteellinen työ ja tietysti ohjelmistokehitys). Näiden tiedostojen kehittämiseen ja ylläpitoon kuluu paljon aikaa ja vaivaa, eikä kukaan halua käyttää vielä enemmän aikaa ja vaivaa muutosten seurauksena kadonneiden tietojen palauttamiseen.

Kuvitellaan, että ohjelmoija kehittää projektia, joka koostuu yhdestä pienestä tiedostosta (muuten, esimerkki on aivan todellinen, ei synteettinen ja on tavattu tosielämässä). Projektin ensimmäisen version julkaisun jälkeen hän on vaikean valinnan edessä: on tarpeen korjata ensimmäisen version käyttäjien ilmoittamat ongelmat ja samalla kehittää jotain uutta toiselle. Vaikka sinun pitäisi vain korjata ilmenevät ongelmat, on suuri todennäköisyys, että jonkin muutoksen jälkeen projekti lakkaa toimimasta, ja sinun on määritettävä, mitä muutettiin, jotta ongelman paikallistaminen olisi helpompaa. Myös tehdyistä muutoksista ja korjauksista kannattaa pitää jonkinlaista lokikirjaa, jotta samaa työtä ei tehdä useita kertoja.

Yksinkertaisimmassa tapauksessa yllä oleva ongelma voidaan ratkaista tallentamalla tiedostoista useita kopioita, esimerkiksi yksi projektin ensimmäisen version virheiden korjaamista varten ja toinen uusia muutoksia varten. Koska muutokset eivät yleensä ole kovin suuria tiedostokokoon verrattuna, on mahdollista tallentaa vain muuttuneet rivit diff-apuohjelmalla ja yhdistää ne myöhemmin Patch-apuohjelmalla. Mutta entä jos projekti koostuu useista tuhansista tiedostoista ja sata ihmistä työskentelee sen parissa? Jos tässä tapauksessa käytät tiedostojen erillisten kopioiden (tai jopa vain muutosten) tallentamista, projekti pysähtyy hyvin nopeasti. Seuraavilla luennoilla käytän esimerkkeinä ohjelmien lähdekoodeja, mutta itse asiassa lähes minkä tahansa tyyppiset tiedostot voidaan asettaa versionhallintaan.

Jos olet graafinen tai web-suunnittelija ja haluat tallentaa jokaisen version kuvasta tai asettelusta - ja luultavasti tekisit niin - versionhallintajärjestelmän käyttö on erittäin viisas päätös. Valuuttavaluutta mahdollistaa palautuksen erilliset tiedostot aiempaan muotoonsa, palauttaa koko projektin aiempaan tilaan, tarkastella ajan kuluessa tapahtuneita muutoksia, määrittää, kuka teki viimeisenä muutoksia moduuliin, joka yhtäkkiä lakkasi toimimasta, kuka ja milloin aiheutti jonkinlaisen virheen koodiin ja paljon muuta. lisää. Yleensä jos pilaat kaiken tai menetät tiedostoja VCS:n käytön aikana, kaikki voidaan palauttaa helposti. Lisäksi kaiken saamasi yleiskustannukset ovat hyvin pienet.

Paikalliset versionhallintajärjestelmät

Kuten aiemmin mainittiin, yksi esimerkki paikallisesta VCS:stä on erittäin yksinkertainen: monet ihmiset haluavat hallita versioita yksinkertaisesti kopioimalla tiedostoja toiseen hakemistoon (yleensä lisäämällä nykyisen päivämäärän hakemiston nimeen). Tämä lähestymistapa on hyvin yleinen, koska se on yksinkertainen, mutta se myös epäonnistuu useammin. On erittäin helppoa unohtaa, että olet väärässä hakemistossa ja muuttaa vahingossa väärää tiedostoa tai kopioida tiedostoja väärään paikkaan ja korvata tarvitsemasi tiedostot. Tämän ongelman ratkaisemiseksi ohjelmoijat ovat pitkään kehittäneet paikallista VCS:ää yksinkertaisella tietokannalla, joka tallentaa kaikki tarvittaviin tiedostoihin tehdyt muutokset

Yksi tämän tyyppisistä suosituimmista VCS:istä on RCS (Revision Control System), joka on edelleen asennettuna moniin tietokoneisiin. Jopa modernissa leikkaussalissa Mac-järjestelmä OS X rcs -apuohjelma asennetaan yhdessä Developer Toolsin kanssa. RCS:n kehitti 1980-luvun alussa Walter F. Tichy. Järjestelmän avulla voit tallentaa vain yhden tiedoston versioita, joten sinun on hallittava useita tiedostoja manuaalisesti. Jokaisen järjestelmän hallinnassa olevan tiedoston versiotiedot tallennetaan erityinen tiedosto Nimen kanssa alkuperäinen tiedosto jonka loppuun lisätään merkit ",v". Esimerkiksi tiedoston file.txt versiot tallennetaan tiedostoon file.txt,v. Tämä apuohjelma perustuu versioparien välisten korjaustiedostosarjojen käsittelyyn (korjaustiedosto on tiedosto, joka kuvaa tiedostojen välistä eroa). Tämän avulla voit luoda uudelleen minkä tahansa tiedoston milloin tahansa ja asentaa korjaustiedostoja peräkkäin. Järjestelmä käyttää diff-apuohjelmaa versioiden tallentamiseen. Vaikka RCS noudattaa vähimmäisvaatimukset versionhallintajärjestelmään nähden siinä on seuraavat päähaitat, jotka myös toimivat kannustimena seuraavan harkittavana olevan järjestelmän luomiseen:

• Työskentele vain yhden tiedoston kanssa, jokaista tiedostoa on ohjattava erikseen;
• Epämukava mekanismi useiden käyttäjien työskentelyyn samanaikaisesti järjestelmän kanssa, tallennustila yksinkertaisesti estetään, kunnes sen estänyt käyttäjä avaa sen;
• Kukaan ei vapauta sinua varmuuskopioista, olet vaarassa menettää kaiken.

Keskitetyt versionhallintajärjestelmät

Seuraava suuri haaste oli tarve tehdä yhteistyötä muiden tietokoneiden kehittäjien kanssa. Tämän ratkaisemiseksi luotiin keskitetyt versionhallintajärjestelmät (CVCS). Tällaisissa järjestelmissä, kuten CVS, Subversion ja Perforce, on keskuspalvelin, joka tallentaa kaikki tiedostot versionhallinnan alaisena, ja joukko asiakkaita, jotka vastaanottavat tiedostoista kopioita. Tämä on ollut versionhallintajärjestelmien standardi useiden vuosien ajan.

Tällä lähestymistavalla on monia etuja, erityisesti verrattuna paikalliseen SLE:hen. Jokainen esimerkiksi tietää, kuka tekee mitäkin projektissa. Ylläpitäjät hallitsevat selkeästi kuka voi tehdä mitäkin, ja tietysti CSKB:ta on paljon helpompi hallita kuin kunkin asiakkaan paikallisia tietokantoja. Tällä lähestymistavalla on kuitenkin useita vakavia haittoja. Ilmeisin on, että keskitetty palvelin on koko järjestelmän heikko kohta. Jos palvelin sammuu tunniksi, kehittäjät eivät voi olla vuorovaikutuksessa tunnin ajan, eikä kukaan voi tallentaa uutta versiota työstään. Jos keskustietokannan sisältävä levy on vaurioitunut eikä varmuuskopiota ole, menetät ehdottomasti kaiken - koko projektin historian, lukuun ottamatta mahdollisesti useita käyttäjien työkoneille tallennettuja työversioita.

CVS

CVS (Concurrent Versions System) on edelleen yleisimmin käytetty järjestelmä, mutta se menettää nopeasti suosiotaan puutteiden vuoksi, joita käsittelen alla. Dick Grune kehitti CVS:n 1980-luvun puolivälissä. Yksittäisten tiedostojen tallentamiseen CVS (sekä RCS) käyttää RCS-muotoisia tiedostoja, mutta voit hallita hakemistoissa olevia tiedostoryhmiä. CVS käyttää myös asiakas-palvelin-arkkitehtuuria, jossa kaikki versiotiedot tallennetaan palvelimelle. Asiakas-palvelin-arkkitehtuurin käyttö mahdollistaa CVS:n käytön myös maantieteellisesti hajautetuissa käyttäjäryhmissä, joissa jokaisella käyttäjällä on oma työhakemistonsa, jossa on kopio projektista. Kuten nimestä voi päätellä, käyttäjät voivat jakaa järjestelmän.

Mahdolliset ristiriidat saman tiedoston muuttamisessa ratkaistaan ​​sillä, että järjestelmä sallii muutokset vain tiedoston uusimpaan versioon. Siksi on aina suositeltavaa päivittää tiedostojen työkopiot ennen muutosten lähettämistä mahdollisten ristiriitaisten muutosten varalta. Päivitettäessä järjestelmä tekee muutoksia työkopioon automaattisesti ja vain jos jossakin tiedostosijainnissa on ristiriitaisia ​​muutoksia, ristiriitapaikan manuaalinen korjaus vaaditaan.

CVS mahdollistaa myös useiden kehityslinjojen ylläpitämisen projektissa kehityshaarojen avulla. Siten, kuten edellä mainittiin, voit korjata virheet projektin ensimmäisessä versiossa ja samalla kehittää uusia toimintoja.

CVS:ää käytti suuri joukko projekteja, mutta se ei tietenkään ollut vailla puutteita, jotka myöhemmin johtivat seuraavan harkittavana olevan järjestelmän ilmestymiseen. Katsotaanpa tärkeimpiä haittoja:

• Koska versiot on tallennettu RCS-tiedostoihin, hakemistoversioiden tallentaminen ei ole mahdollista. Tavallinen tapa kiertää tämä on tallentaa tiedosto (esim. README.txt) hakemistoon;
• Tiedostojen siirtäminen tai uudelleennimeäminen ei ole versionhallinnan alaista. Tavallinen tapa tehdä tämä on kopioida ensin tiedosto, poistaa vanha cvs remove -komennolla ja sitten lisätä se uudella nimellä cvs add -komennolla;

Subversion

Subversion (SVN) kehitettiin vuonna 2000 CollabNetin aloitteesta. SVN kehitettiin alun perin "paremmaksi CVS:ksi" ja kehittäjien päätavoitteena oli korjata CVS-suunnittelussa tehdyt virheet samalla kun säilytetään samanlainen käyttöliittymä. SVN, kuten CVS, käyttää asiakas-palvelin-arkkitehtuuria. Merkittävimmät muutokset verrattuna CVS:ään ovat:

• Atomimuutokset (sitoutuminen). Jos toimitusten käsittely keskeytyy, muutoksia ei tehdä.
• Tiedostojen uudelleennimeäminen, kopioiminen ja siirtäminen säilyttää koko muutoshistorian.
• Hakemistot, symboliset linkit ja metatiedot ovat versionhallinnan alaisia.
• Tehokas muutosmuisti binääritiedostoille.

Hajautetut versionhallintajärjestelmät

Ja tässä tilanteessa hajautetut versionhallintajärjestelmät (DVCS) tulevat peliin. Järjestelmissä, kuten Git, Mercurial, Bazaar tai Darcs, asiakkaat eivät vain tarkista tiedostojen uusimpia versioita, vaan kopioivat koko arkiston. Siksi siinä tapauksessa, että palvelin, jonka kautta työ eteni, "kuolee", mikä tahansa asiakastietovarasto voidaan kopioida takaisin palvelimelle tietokannan palauttamiseksi. Joka kerta kun asiakas tarkistaa tiedostoista uuden version, hän luo itselleen täydellisen kopion kaikista tiedoista.

Lisäksi useimmat näistä järjestelmistä antavat sinun työskennellä useiden etätietovarastojen kanssa, joten voit työskennellä samanaikaisesti eri tavoin eri ryhmiä ihmisiä yhden projektin sisällä. Siten yhdessä projektissa voit suorittaa samanaikaisesti useita erityyppisiä työprosesseja, mikä on mahdotonta keskitetyissä järjestelmissä.

Miksi hajautettuja järjestelmiä tarvitaan?

Kuten nimestä voi päätellä, yksi hajautettujen järjestelmien pääideoista on selkeästi määritellyn keskitetyn versiovaraston - arkiston - puuttuminen. Hajautettujen järjestelmien tapauksessa joukko versioita voidaan jakaa kokonaan tai osittain eri arkistoihin, mukaan lukien etävarastot. Tämä malli sopii täydellisesti hajautettujen ryhmien työhön, esimerkiksi ympäri maailmaa hajautettuun kehittäjäryhmään, joka työskentelee saman avoimen lähdekoodin projektin parissa. Tällaisen tiimin kehittäjä voi ladata kaikki versiotiedot ja sitten työskennellä vain paikallisella koneella. Heti kun jonkin työvaiheen tulos on saavutettu, muutokset voidaan ladata johonkin keskustietovarastoon tai julkaista katseltavaksi kehittäjän verkkosivustolla tai postitus lista. Muut projektiin osallistujat puolestaan ​​voivat päivittää versiotietovaraston kopionsa uusilla muutoksilla tai kokeilla julkaistuja muutoksia erillisellä testikehityshaaralla. Valitettavasti ilman hyvää projektiorganisaatiota yhden keskustietovaraston puute voi olla hajautettujen järjestelmien haitta. Jos keskitetyissä järjestelmissä on aina yksi yhteinen arkisto, josta saat projektin uusimman version, niin hajautettujen järjestelmien tapauksessa sinun on organisatorisesti päätettävä, mikä projektihaaroista on tärkein. Miksi hajautettu versionhallintajärjestelmä kiinnostaisi jotakuta, joka jo käyttää keskitettyä järjestelmää - kuten Subversionia? Kaikki työt edellyttävät päätösten tekemistä, ja useimmissa tapauksissa on tarpeen kokeilla erilaisia ​​vaihtoehtoja: harkita versionhallintajärjestelmien kanssa työskennellessäsi erilaisia ​​vaihtoehtoja ja työskennellä suuria muutoksia kehityshaarat palvelevat. Vaikka tämä on melko luonnollinen käsite, sitä ei ole helppo käyttää Subversionissa. Lisäksi kaikki muuttuu monimutkaisemmaksi, jos yhdestä haarasta toiseen yhdistetään useita peräkkäisiä - tässä tapauksessa sinun on ilmoitettava tarkasti kunkin muutoksen alkuperäinen ja lopullinen versio ristiriitojen ja virheiden välttämiseksi. Hajautetuissa versionhallintajärjestelmissä kehityshaarat ovat yksi peruskäsitteistä - useimmissa tapauksissa jokainen versiovaraston kopio on kehityshaara. Siten mekanismi muutosten yhdistämiseksi haarasta toiseen hajautetuissa järjestelmissä on yksi tärkeimmistä, minkä ansiosta käyttäjät voivat panostaa vähemmän järjestelmää käyttäessään.

Lyhyt kuvaus suosituista katumaastureista

• Git on Linus Torvaldsin kehittämä hajautettu versionhallintajärjestelmä. Aluksi Git oli tarkoitettu käytettäväksi Linux-ytimen kehitysprosessissa, mutta myöhemmin sitä alettiin käyttää monissa muissa projekteissa, kuten esimerkiksi X.org ja Ruby on Rails, Drupal. Git on tällä hetkellä nopein hajautettu järjestelmä, joka käyttää pienintä versiokauppaa. Mutta samaan aikaan käyttäjille, jotka siirtyvät esimerkiksi Subversionista, Git-käyttöliittymä voi tuntua monimutkaiselta;
• Mercurial on Pythonilla kirjoitettu hajautettu järjestelmä, jossa on useita C-laajennuksia. Mercurialia käyttävät projektit ovat Mozilla ja MoinMoin.
• Bazaar on Canonicalin kehittämä järjestelmä, joka tunnetaan Ubuntu-jakelustaan ​​ja verkkosivustostaan ​​https://launchpad.net/. Järjestelmä on pääasiassa kirjoitettu Pythonilla ja sitä käyttävät projektit, kuten MySQL.
• Codeville on Pythonilla kirjoitettu hajautettu järjestelmä, joka käyttää innovatiivista algoritmia muutosten yhdistämiseen (yhdistämiseen). Järjestelmää käytetään mm. kehitystyössä alkuperäinen asiakas BitTorrent.
• Darcs on Haskellilla kirjoitettu hajautettu versionhallintajärjestelmä, jota käyttää esimerkiksi Buildbot-projekti.
• Monotone on C++-kielellä kirjoitettu järjestelmä, joka käyttää SQLitea versiomuistina.

Hei, Habr. Päätin käsitellä aihetta, jota on käytetty useissa artikkeleissa, tarkemmin sanottuna kuvaillakseni versionhallintajärjestelmien (jäljempänä VCS) suurelta osin epästandardista (sanoisin, lajittelematonta) käyttöä. Hyvät ohjelmoijat, piilotetaan mätä tomaatit ja siirrytään eteenpäin, koska tämä artikkeli ei ole sinua varten. Kyllä, olette kaikki jo oppineet Gitin, SVN:n ja CVS:n hienoudet ja tiedätte monia muita muotisanoja. Tutustukaamme pelkät kuolevaiset kaikkiin kovan valuutan käytön etuihin.
Kutsun kaikki, jotka haluavat tutustua kovan valuutan järjestelmään, sekä kaikki, jotka tavalla tai toisella käsittelevät nopeasti muuttuvaa dataa.

Miksi tämä on välttämätöntä?

Olen itse opiskelija teknillisessä korkeakoulussa ja työskentelen lähes jatkuvasti dokumenttien (tekstien, piirustusten, piirustusten) parissa, vaihtaen niitä kolme (kymmentä, sata) kertaa päivässä. Joskus käy ilmi, että viimeisen viikon aikana tehdyt muokkaukset on peruttava ja dokumentit palautettava sellaiseen tilaan kuin ne olivat viikko sitten. On hyvä, jos vain muutama muokkaus tehtiin, tässä tapauksessa viisikymmentä Ctrl+Z:n osumaa voi auttaa. Jos dokumentin kanssa on kuitenkin työskennelty tämän viikon aikana enemmän tai vähemmän aktiivisesti, tilaa "ennen viikko sitten tehtyä tärkeää muokkausta" ei voida palauttaa. Tätä varten tarvitset kopion asiakirjasta "ennen tärkeätä muokkausta" sekä tusinaa muuta kopiota "ennen toista tärkeää muokkausta", "ennen kyseenalaista muokkausta" ja "ennen muokkausta, joka se on todennäköisesti peruttava." Periaatteessa tämä lähestymistapa on mahdollista ja monet käyttävät sitä. Viime aikoihin asti pidin itse tärkeitä versioita tiedostot, tallentamalla ne "date_time"-etuliitteillä, ja näytti siltä, ​​että olin onnellinen. Tämän menetelmän etuna on sen yksinkertaisuus, haittana on, että työkansiot "turpoavat" ja ovat epämukavia käyttää. Ja jos voit jotenkin taistella niistä ensimmäistä vastaan ​​(iso Kovalevyt ja 7zip), niin haitalle oli tehtävä jotain.

Mitä tälle voidaan tehdä tai mikä on SLE

Otetaan Wikipediasta kappale: "Versionhallintajärjestelmä (englanninkielisestä Version Control System, VCS tai Revision Control System) on ohjelmisto, joka helpottaa muuttuvien tietojen käsittelyä. Versionhallintajärjestelmän avulla voit tallentaa useita versioita samasta asiakirjasta, palata tarvittaessa aikaisempiin versioihin, määrittää, kuka teki tietyn muutoksen ja milloin, ja paljon muuta." Se on samanlainen kuin Wikipedia itse – kaikki versiot artikkeleista kaikilla muokkauksilla ovat käytettävissä tutkittavaksi.
Siksi VCS:n käyttö tilanteessa, jossa sinun on tallennettava useita tiedostoversioita, on mitä tarvitset. Tämän lähestymistavan etuja ovat helppokäyttöisyys ja vapaan levytilan säästäminen ns. delta-pakkauksen ansiosta (kun itse tiedostoja ei tallenneta eri versioihin, vaan ne muuttuvat versiosta toiseen, mikä vähentää tallennetun tiedon määrää) . Kokeillaan.

Millaisia ​​kovan valuutan valuuttoja on olemassa?

Sama Wikipedia ehdottaa, että kovaa valuuttaa voidaan keskittää ja jakaa, suuria ja pieniä, kellojen ja pillien kanssa tai ilman. Emme ole erityisen kiinnostuneita tästä, koska käytämme (by vähintään, ensin) vain osa valuutanvaihtojärjestelmän toiminnoista. Tarkastellaanpa tätä toiminnallisuutta.
Lähes kaikki VCS:t ovat jonkinlaisia ​​tallennusvälineitä, joihin on tallennettu kaikki versiot tiedostoista, joiden kanssa työskentelemme. Tässä on tarpeen selventää, että tallennettujen tiedostojen versiot päättävät useimmiten käyttäjä. Teimme vaikkapa kymmenkunta pientä muutosta ja päätimme, että on aika tallentaa toimintamme tulokset arkistoon. Analogia tulee mieleen Ctrl+S:n ajoittain painamisesta, sillä ainoa ero on, että tätä tiedoston versiota voi käyttää tulevaisuudessa. Luonnollisesti "yhdellä iskulla" voit siis lisätä arkistoon niin monta versiota kuin haluat. Suuri määrä tiedostot. Tätä toimintoa kutsutaan "sitomiseksi" tai "muutosten tekemiseksi" yksinkertaisella tavalla.
Voit milloin tahansa lisätä uuden tiedoston tai poistaa olemassa olevan tiedoston arkistoon (niin arkistoa näppärästi kutsutaan), ja VCS "muistaa" milloin ja mitä lisäsimme/poistimme. Ja committien aikaisten kommenttien ansiosta voit myös kuvailla, miksi juuri tämä toimitus tehdään ("lisättiin koru sinne"/"poistettiin sieltä mahdollisesti tarpeellinen pala").
Kun vihdoin tajuamme, että meidän on aika palata viikon takaiseen versioon, meillä on koko muutoshistoria. Ja täällä voimme valita mitä tehdä. Jos haluat kopioida vaaditun osan vanhasta tiedostosta ja liittää sen nykyiseen versioon, poista vanha tiedosto tallennustilasta ja kopioi tarvitsemasi siitä. Jos sinun täytyy peruuttaa kokonaan ja jatkaa työskentelyä vanha versio SKV tulee jälleen apuumme - voimme palata aikaisempaan versioon ja luoda ns uusi haara("haara"), säilyttäen samalla kaiken, mistä "luopuimme" palauttamalla versiot viikko sitten. Siten projektiversioiden historia voidaan esittää graafisesti puuna - "juurista" (projektin alku) "haaroihin" (onnistuneet ja epäonnistuneet muokkaukset). Lisäksi "haara" voidaan luoda myös keinotekoisesti, esimerkiksi siinä tapauksessa, että päätämme kehittää kaksi eri versiota samoista lähdetiedostoista - ensimmäisessä työskentelemme joidenkin korujen kanssa, toisessa työskentelemme muiden kanssa. Lisäksi, jos työtiedostot ovat tekstiasiakirjoja(ja joissakin muissa) on mahdollista yhdistää eri haarat yhdeksi - niin sanottu yhdistäminen. Kuvitellaan nyt, että projektin parissa työskentelee useita ihmisiä ja jokainen työskentelee oman "korunsa" parissa. Yhteisen arkiston käyttö tässä tapauksessa yksinkertaistaa huomattavasti kehitystä.

Teoriasta käytäntöön tai SLE:n käytön aloittaminen

Joten toivon, että olen vakuuttanut sinut siitä, että SLE:n käyttö on hyvä asia. Jäljelle jää vain opetella käyttämään VCS:ää. Näin teemme.
On olemassa erilaisia ​​versionhallintajärjestelmiä, jotka eroavat toisistaan ​​eri käyttönäkökohtien osalta. Koska emme ole kiinnostuneita (ainakaan aluksi) työn hienouksista erilaisia ​​järjestelmiä, keskitytään niistä yksinkertaisimpiin ja ystävällisimpiin. Nöyrä mielestäni tällainen järjestelmä on kummallista kyllä ​​Mercurial - "alustojen välinen hajautettu versionhallintajärjestelmä, joka on suunniteltu tehokasta työtä erittäin suurilla koodivarastoilla" kanssa graafinen kuori KilpikonnaHg. Järjestelmää voidaan käyttää Windows-, Linux- ja Mac OS X -käyttöjärjestelmissä.
Sallikaa minun tehdä varaus heti, että kuvailen työskentelyä järjestelmän kanssa Windowsissa. Niille, jotka ovat hallinneet Linuxin, ei ole vaikeaa oppia kaikkea analogisesti.
Lisäksi samaan aikaan opimme työskentelemään Mercurial-varastojen ilmaisen isännöinnin - bitbucket.org - kanssa, mikä on välttämätöntä, jos et työskentele projektin parissa yksin tai, mikä on erittäin kätevää, haluat pääsyn kaikkiin projektin versioihin Internetin kautta. Pohjimmiltaan se on kätevä dropbox-korvaus, jos olet käyttänyt sitä aiemmin.
Asenna ensin Mercurial + TortoiseHg täältä: tortoisehg.bitbucket.org.
Tämä järjestelmä toimii konsolissa, joten käytön helpottamiseksi myöhemmin kirjoitamme useita *.bat-tiedostoja tyypillisiä toimintoja varten.
Kaikki toiminnot suoritetaan komennolla hg. Kutsutaan ilman parametreja, ja se näyttää luettelon peruskomennoista.
Arkisto on mikä tahansa valitsemamme hakemisto (käytän "C:\project\"-kansiota), johon kaikki tulevan projektimme tiedostot tulisi tallentaa. Kukaan ei tietenkään kiellä useiden arkiston käyttöä yhdellä tietokoneella.
Jotta järjestelmä "ymmärtää", että haluamme luoda arkiston, suoritamme komennon:
hg init c:\projekti
jonka jälkeen luodaan "c:\project\"-kansio, jos sitä ei ole luotu aiemmin, ja "c:\project\.hg\"-kansio, johon Mercurial tallentaa kaikki palvelutiedot.
Muistamme heti, että haluamme saada paitsi paikallisen tietovaraston tietokoneellemme myös etätietovaraston, johon lähetämme kaikki muutokset (tai, kuten fiksut kaverit sanovat, "työntää" muutokset etävarastoon, Englanninkielinen "push"). Voit tehdä tämän siirtymällä osoitteeseen bitbucket.org, rekisteröitymällä ja luomalla ensimmäinen arkistosi (Arkistot - Luo uusi arkisto). Anna arkistolle nimi (niin kutsun sitä remote_projectiksi) ja napsauta Luo arkisto.
Nyt meillä on kaksi arkistoa - paikallinen, joka sijaitsee "c:\project\"-kansiossa, ja etävarasto, joka sijaitsee osoitteessa "bitbucket.org/your_account_name/remote_project/", jossa tilisi_nimi on nimi, joka määritetään rekisteröityessäsi bitbucketiin, remote_project on arkiston nimi, joka valittiin sen luomisen yhteydessä.
Jotta voimme jatkaa tutkimista, meidän on työnnettävä jotain paikalliseen arkistoon. Luo vain siihen (minun tapauksessani "c:\project\"-kansioon) mikä tahansa tiedosto tulevasta projektistasi tai kopioi nykyinen projektisi sinne.
Nyt tarkalleen ottaen meidän on kerrottava Mercurialille: "lisäsimme sellaisia ​​​​ja sellaisia ​​​​tiedostoja ja pari uutta kansiota projektikansioon", "hg add" -komento on tarkoitettu tähän. Toinen lähestymistapa on kuitenkin kätevämpi - seuraavassa vahvistuksessa käskemme Mercurialia poimia kaikki äskettäin luodut tiedostot projektikansiosta ja unohtaa poistetut, tämä on paljon helpompaa kuin tehdä "hg add c:\project\new_document". .doc" aina kun luot uuden asiakirjan "
Joten siirrytään ensimmäiseen sitoumuksemme. Se suoritetaan seuraavalla komennolla:
hg commit –A –m "kommentti sitoutumaan"
Katsotaan kaikki järjestyksessä. Komento on annettava, kun olemme arkistossa (eli meidän on ensin suoritettava "cd c:\project"). Vaihtoehto "-A" on välttämätön, jotta Mercurial "poimii" äskettäin luotuja tiedostoja (katso yllä), vaihtoehto "-m" sallii sinun lisätä kommentin sitoumukseen. Nämä kommentit näkyvät katseltaessa versioita (tai muutosjoukkoja - muutosluetteloita) TortoiseHg:ssä ja projektisivulla bitbucket.orgissa. On erittäin tärkeää antaa merkityksellisiä kommentteja, jotta et kärsisi myöhemmin muistaen milloin tämä tai tuo muokkaus on tehty.
Nyt arkistossamme on projektimme alkuperäinen versio. Kaikki muut sitoumukset suoritetaan samalla tavalla, kun olemme päättäneet, että on aika tallentaa nykyinen versio.
Valmis toimitus voidaan "työntää" etävarastoon komennolla:
hg push https://bitbucket.org/your_account_name/remote_project
Tässä tapauksessa sinun on myös oltava arkistoa vastaavassa kansiossa. Kun olet antanut komennon, sinulta kysytään bitbucket.org-tilimme nimeä ja salasanaa, jotta et syöttäisi niitä jokaisella painalluksella, komento voidaan korvata seuraavalla:
hg push hg push https://your_account_name:[email protected]/your_account_name/remote_project
Koska kirjoitamme kaikki komennot *.bat-tiedostoon, salasana tallennetaan tässä tapauksessa selkeänä tekstinä, mikä aiheuttaa jonkinlaisen tietoturvariskin, mutta minulle se on hyväksyttävää.
Mukavuuden vuoksi luomme commit.bat-, push.bat- ja commit&push.bat-tiedostoja suoran tavoittavuuden alueelle, jossa on seuraava sisältö:
[commit.bat-tiedoston sisältö]
JOS !%1==! poistu 1
cd C:\projekti
hg commit -A -m "%*"
poistu 0
:exit1
echo "EI KOMENTORIVIÄ ARG!"
:exit0
Tämä tiedosto, jota kutsutaan argumenteilla, sitoo projektin kommenteissa olevilla argumenteilla. Esimerkki: suorita "commit.bat ensimmäinen sitoumukseni" ja hanki commit kommentilla "minu ensimmäinen sitoumus". FAR:ssa tähän on kätevää käyttää Ctrl+Enter-yhdistelmää.
[push.bat-tiedoston sisältö]
cd C:\projekti
hg push https://your_account_name:[email protected]/your_account_name/remote_project
Tämä tiedosto työntyy etävarastoon.
[tiedoston commit&push.bat sisältö]
JOS !%1==! poistu 1
cd C:\projekti
hg commit -A -m "%*"
poistu 0
:exit1
echo "EI KOMENTORIVIÄ ARG!"
:exit0
soita ./push.bat
Tämä tiedosto, jota kutsutaan argumenteilla, suorittaa peräkkäisen toimituksen ja projektin push-toiminnon vahvistuksen kommentteihin syötetyillä argumenteilla.
Lisäksi pienille välitoimituksille suosittelen commit_date_time.bat-tiedoston luomista:
[tiedoston commit_date_time.bat sisältö]
cd C:\projekti
hg commit -A -m "%DATE% %TIME%"
Tämä tiedosto sitoo nykyisen päivämäärän ja kellonajan kommentiksi, mikä on usein kätevää.
Jokainen päättää sitoutumistiheyden ja työntöjen tiheyden yksilöllisesti riippuen tehtävien muokkausten intensiteetistä ja monimutkaisuudesta. Vaikka on suositeltavaa noudattaa sääntöä "useammin on parempi".
Napsauta hiiren kakkospainikkeella arkistotiedostoa/kansiota, voit käynnistää Repository Explorerin (TortoiseHg - Repository Explorer), joka esittelee kaikki sitoumukset kommenteineen. Tämä ikkuna näyttää arkistomme puurakenteen, josta voit suorittaa sitoumuksia, työntöjä, palautuksia aikaisempiin versioihin (backout) ja muita toimintoja.
Osoitteessa bitbucket.org/your_account_name/remote_project on samanlainen joukko muutosjoukkoja, ja voit ladata minkä tahansa version projektista yhteen arkistoon, mikä on joskus myös erittäin kätevää.
Yleisesti ottaen katson, että tämä on ensimmäinen tutustumiseni Mercurialiin. Lisätietoja on osoitteessa translated.by/you/mercurial-the-definitive-guide/into-ru/trans/

Kenelle tämä artikkeli on tarkoitettu?

Lopetan luultavasti siihen, mistä minun olisi pitänyt aloittaa – kenelle tämä artikkeli on tarkoitettu? Vastaus on yksinkertainen - niille, jotka haluavat oppia käyttämään kovaa valuuttaa. Onnistuin saamaan useita suunnittelijoita, insinöörejä ja jopa kirjailijan koukkuun VCS:ään. Kokeile myös - tämä todennäköisesti helpottaa työtäsi paljon.

P.S. Siirretty Version Control Systems -blogiin.

Tunnisteet:

• versionhallintajärjestelmät
• oikukas
• bitbucket

Lisää tageja

Koska ohjelmoijatiimimme kehittää useita projekteja kerralla, syntyi nopeasti tarve versionhallintajärjestelmälle.

Luonnollisesti etsintä alkoi Habrin tutkimuksella - ja johti odottamattomaan tulokseen. Huolimatta siitä, että versionhallintajärjestelmät ilmestyivät vuonna 1986, useimmat opetusohjelmat työskentelystä moderni Versionhallintajärjestelmät osoittautuivat epätäydellisiksi ja voimakkaasti sidoksissa komentorivin kanssa toimimiseen.

Meillä ei ole mitään vastaan komentorivi yleensä, mutta pienessä kehittäjätiimissämme (4 henkilöä) ei ole komentorivillä työskentelyn faneja :).

Miksi uskomme, että komentorivin käyttäminen on tehotonta?

1. Ajan hukkaaminen tietojen syöttämiseen. Komentojen kirjoittaminen kestää paljon kauemmin kuin hiiren napsauttaminen.
2. Ajan hukkaa opiskeluun. Uuden syntaksin oppiminen selkeiden käyttöliittymien aikakaudella kestää varmasti kauemmin kuin graafisen käyttöliittymän oppiminen.
3. Virheen todennäköisyys. On helpompi tehdä virhe syötettäessä tietoja komentorivin kautta (inhimillistä tekijää ei ole poistettu).
4. Rikkominen automaation periaatteet. Ehkä tämä on tärkein kohta. Tietokone on luotu nopeuttamaan työtä ja korvaamaan henkilöä suorituksen aikana rutiinitoiminnot. Komentorivin tapauksessa toimimme aina käsin itse asiassa se on välttämätöntä joka kerta kirjoittaa sama ohjelmakoodi(tosin primitiivistä).

Valitettavasti emme löytäneet täysimittaista venäjänkielistä käsikirjaa työskentelemään nykyaikaisten versionhallintajärjestelmien kanssa. Kerättyämme tietoa erilaisista artikkeleista ja englanninkielisistä YouTube-videoista päätimme tehdä oman oppaamme, joka:

1. Siellä on vaiheittaiset ohjeet (ohjelmoijamme toimivat niiden mukaan).
2. Se toimii alusta loppuun (eli siitä saat pienen mutta täydellisen tuloksen - toimivan hajautetun versionhallintajärjestelmän).
3. Toimii vain GUI:illa (katso syyt yllä).

Johdanto

Vastoin kokeneiden järjestelmänvalvojien ja muiden komentorivin käytön ystävien ja fanien odotuksia tämä artikkeli ei sisällä komentorivillä suoritettuja komentoja. Koko artikkeli on kirjoitettu kielellä, jota ymmärtävät myös ne, jotka ovat vasta äskettäin aloittaneet ohjelmoinnin, mutta harkitsevat jo VCS:n (versionhallintajärjestelmän) käyttöönottoa. Jokainen VCS:n asennuksen vaihe pureskellaan pienimpään yksityiskohtaan, ja mukana on kuvakaappauksia ja lisäselityksiä.

Jos et ole "For Dummies" -oppaiden fani, voit ohittaa tämän artikkelin lukemisen ja ratkaista VCS:n nostamisen ongelman omalla tavallasi.

Käytetyt ohjelmat ja palvelut

Käytämme VCS:n (Version Control System) käyttöönottoa seuraavat ohjelmat ja palvelut:

• Mercurial on monialustainen hajautettu versionhallintajärjestelmä, joka on suunniteltu toimimaan tehokkaasti erittäin suurten koodivarastojen kanssa.
• TortoiseHg on graafinen käyttöliittymä Mercurial-versionhallintajärjestelmään.
• Bitbucket on Mercurial- ja Git-versionhallintajärjestelmiin perustuva verkkopalvelu projekteihin ja niiden yhteiseen kehittämiseen.

Versionhallintajärjestelmän käyttöönotto - vaiheittaiset ohjeet

1. Lataa ja asenna TortoiseHg tietokoneellesi viralliselta verkkosivustolta: http://tortoisehg.bitbucket.org/

Tämä asiakas on asennettava kaikkiin tietokoneisiin, joista projekteja kehitetään yhteisesti.

Tässä oppaassa kaikki versionhallintajärjestelmän käyttöönotto- ja työvaiheet suoritetaan käyttämällä TortoiseHg versio: 2.10.1 Windowsille 64-bittinen Mercurial 2.8.1:n kanssa.

2. Rekisteröidy Bitbucket-verkkopalveluun: https://bitbucket.org/
Koko rekisteröintiprosessi koostuu yhteystietojen (käyttäjätunnus, sähköpostiosoite jne.) täyttämisestä ja rekisteröinnin yhteydessä määritetyn sähköpostiosoitteen vahvistamisesta napsauttamalla "Vahvista tämä sähköpostiosoite" -painiketta rekisteröinnin jälkeen saapuneesta kirjeestä.

Kaikkien kehitystiimisi jäsenten on myös rekisteröidyttävä Bitbucketiin. Startup-yritysten suureksi onneksi tällä palvelulla on ilmainen tili, jonka avulla voit luoda yksityisiä tietovarastoja 5 käyttäjälle. Ilmaispaketin kehittämiseen osallistuvien tiimien jäsenten enimmäismäärä on myös mahdollista nostaa 8 henkilöön.

KANSSA täydellinen lista Tariffit löydät linkin takaa: https://bitbucket.org/plans

3. Kirjautumalla tilillesi Bitbucket-palvelussa, voit välittömästi vaihtaa tilisi käyttöliittymän kielen venäjäksi.

Voit tehdä tämän valitsemalla päävalikon oikeasta yläkulmasta avattavasta luettelosta "Hallinnoi tiliä" ja valitsemalla avautuvalla sivulla tarvitsemasi käyttöliittymän kieli avattavasta "Kieli" -luettelosta.

4. Luodaksesi arkiston projektillesi, sinun on mentävä tilisi pääsivulle (https://bitbucket.org/dashboard/overview) ja napsautettava "Luo ensimmäinen tietovarasto" -painiketta.

5. Määritä uuden arkiston luontisivulla seuraavat asetukset:

Nimi – Anna nimi uudelle arkistollesi. Etunimi käytetään pääsylinkin rakentamiseen arkistoon.
Tärkeä! On parempi ilmoittaa nimi latinalaisilla kirjaimilla, muuten linkki arkistoon päättyy yhdysmerkkeihin ja näyttää vaikeasti ymmärrettävältä: https://[email protected]/yourlogin/--------

Kuvaus – täsmennä Lyhyt kuvaus arkistosi (kenttä on valinnainen)
- Käyttöoikeustaso – Valitse valintaruutu, jos haluat, että vain kehitystiimisi jäsenillä on pääsy tietovarastoon (yksityinen tietovarasto).
- Haarukoiden luominen – Aseta "Salli vain yksityiset haarukat"
- Arkiston tyyppi - Valitse "Mercurial"
- Projektinhallinta – Valitse "Task Tracker"- ja "Wiki"-valintaruudut
- Kieli – Valitse kehityskieli, jolla projektisi on kirjoitettu. Minun tapauksessani se on PHP.

Kun kaikki asetukset on määritetty, sivu näyttää suunnilleen tältä:

Tarkista syötetyt tiedot uudelleen ja jos kaikki on syötetty oikein, napsauta "Luo arkisto" -painiketta.

6. Kun olet luonut uuden arkiston, sinut ohjataan Aloitussivulle:

7. Luo tietokoneellesi tyhjä kansio, johon Mercurial-versionhallintajärjestelmään liitetyt projektitiedostot tallennetaan tulevaisuudessa.

Tärkeä! Kansion on oltava tyhjä. Esimerkiksi yhdistääkseni kansion jo olemassa olevaan projektiin (joukko ohjelmakoodia), minun piti väliaikaisesti siirtää kaikki tiedostot toiseen hakemistoon (tehdä varmuuskopio). Myöhemmin palautamme kaikki tiedostot paikoilleen, mutta toistaiseksi meidän on tyhjennettävä yhteyskansio kokonaan.

8. Avautuvassa ikkunassa sinun on määritettävä ”Lähde”-kenttään linkki, jolla voit muodostaa yhteyden vaiheessa 6 luomaasi tietovarastoon.

Ja napsauta "Kloonaa" -painiketta.

9. Järjestelmä kysyy salasanaa tilillesi Bitbucket-palvelussa, syötä se.

10. Jos kaikki tehtiin poikkeamatta näistä ohjeista, kansio tulee näkyviin uusi katalogi".hg" luodun arkiston palvelutiedostoilla.

11. Nyt voit turvallisesti palauttaa projektisi tiedostot (ohjelmakoodit) Mercurial-versionhallintajärjestelmään kytkettyjen projektitiedostojen tallentamiseen tarkoitettuun kansioon

Tärkeä!Älä koske palveluhakemistoon ".hg". Sitä tarvitaan, jotta VCS toimii.

12. Paina uudelleen oikealla painikkeella hiirellä projektikansiomme päälle ja valitse avattavasta valikosta "Hg Commit..."

13. Näet valintaikkunan, joka on suunniteltu tallentamaan kaikki projektiisi tehdyt muutokset (in tässä tapauksessa lisäsimme ohjelmakoodimme alun perin tyhjään projektikansioon).

Sinun tulee valita kaikki muutetut (lisätyt) tiedostot, merkitä muutokselle kommentti (esimerkiksi versio 1.00) ja klikata "Sitoudu"-painiketta.

Järjestelmä pyytää sinua vahvistamaan lisäyksen, napsauta "Lisää".

14. Jos kaikki tehtiin oikein, järjestelmä tallentaa tehdyt muutokset ja näet jotain tällaista:

Itse asiassa tulevaisuudessa, kun olet kehittämässä, suoritat pienen koodinpätkän suorittamisen jälkeen vaiheen 12 toiminnon (napsauta “Hg Commit...”) vahvistaaksesi versionhallintajärjestelmään tehdyn muutoksen. Tämä antaa sinulle mahdollisuuden palauttaa järjestelmän edelliseen sitoumukseen milloin tahansa.

Ylläoleva huomioon ottaen käytännössä kannattaa kirjoittaa jokaiselle sitoumukselle tarkempi kommentti kuin "Versio 1.00".

16. Avautuvassa ikkunassa näet koko koodin tallennettujen (sitoutuneiden) muutosten historian, voit palata haluttuun vahvistukseen ja myös lähettää muutokset aiemmin luomaasi arkistoon.

Voit tehdä tämän valitsemalla ohjauspaneelista Työnnä saapuvat muutokset -painike.

Tämän jälkeen sinut näytetään valintaikkunat pyytää sinua vahvistamaan "push" ja pyytää sinua antamaan salasanan Bitbucket-tilillesi. Hyväksy ja anna salasana.

Järjestelmä alkaa kopioida tiedostoja arkistoon Bitbucket-palvelimella. Ota aikaa ja odota prosessin valmistumista.

17. Nyt kopio projektitiedostoistasi on tallennettu arkistoon Bitbucket-palvelimilla. Bitbucket-tililläsi näet koko projektisi historian.

Välitulokset versionhallintajärjestelmän (VCS) yhdistämisestä

Tässä vaiheessa olemme luoneet arkiston ja sijoittaneet kaikki projektimme tiedostot siihen. Eli nyt voit muodostaa yhteyden arkistoon miltä tahansa tietokoneelta ja saada vakaa versio siihen tallennetut tiedostot.

Toisen tietokoneen yhdistäminen edellyttää tiedostojen kopioimista arkistosta toiseen tietokoneeseen. Sinun on suoritettava vaiheet 1 – TortoiseHg:n asentaminen ja 7 – arkistotiedostojen tuonti kopioidaksesi tiedostot toiseen, kolmanteen ja seuraavaan toimivaan tietokoneeseesi.

Työntekijöiden yhdistäminen arkistoon.

Versionhallintajärjestelmän (VCS) liittämisen päätarkoitus projektiisi on yhteistyön järjestäminen. Nuo. Kun kehität järjestelmää yksin, useimmissa tapauksissa voit pärjätä ilman VCS:ää, mutta jos kehittäjiä on useita, todennäköisyys ohjelmakoodien säännölliseen katoamiseen (ylikirjoitukseen) ja järjestelmäversioiden välisiin ristiriitoihin on erittäin korkea.

Siksi liitetään nyt toinen ohjelmoija projektiimme (kutsu osallistuja) ja perustetaan hänen työpaikkansa.

Työntekijän yhdistäminen arkistoon

18. Kaikkien työntekijöiden, joilla on pääsy arkistoosi, on oltava rekisteröityinä Bitbucket-palveluun. Heillä pitäisi myös olla TortoiseHg asennettuna tietokoneisiinsa.

Kerroin sinulle kuinka rekisteröityä palveluun ja asentaa TortoiseHg hieman aiemmin tässä oppaassa. Siksi tämän prosessin ei pitäisi aiheuttaa vaikeuksia sinulle ja kollegoillesi.

19. Kirjaudu sisään Bitbucket-tilillesi:

Napsauta "Kutsu jäsen tähän tietovarastoon" -osiossa "Lähetä kutsu" -painiketta.

20. Järjestelmä näyttää valintaikkunan, jossa sinua pyydetään määrittämään sähköpostiosoite käyttäjä, jolle haluat antaa pääsyn tietovarastoon. Lisäksi sinun on määritettävä käyttöoikeudet (luku tai kirjoitus). Koska Näissä ohjeissa näytämme kuinka yhdistää toinen kehittäjä arkistoon ja määrittää sitten "merkintä".

Kun olet syöttänyt työntekijän sähköpostiosoitteen ja määrittänyt käyttöoikeudet, napsauta "Jaa" -painiketta.

21. Kutsuttu osallistuja saa sähköpostin, jossa on linkki kutsuun. Hänen on seurattava tätä linkkiä ja hyväksyttävä kutsu päästäkseen arkistoon.

Jälleen kerran, kaikkien arkistosi osallistujien on rekisteröidyttävä Bitbucket-palveluun.

22. Kun kutsu on hyväksytty, uusi osallistuja näkee tilillään tämä arkisto ja linkkisi käyttääksesi sitä TortoiseHg:n avulla.

Kaikki sinun ja avustajien tekemät muutokset tallennetaan arkistoon. Näet, mitä ja milloin on muutettu, ja voit halutessasi palauttaa projektisi haluamaasi versioon milloin tahansa.

Luulen, että johdantoartikkeli versionhallintajärjestelmän käyttöönotosta ilman komentoriviä voi päättyä tähän. Yllä kuvattujen vaiheiden läpikäyminen mahdollistaa täysimittaisen VCS:n toteuttamisen projektissasi, ts. Kun olet käynyt läpi kaikki vaiheet, saat täydellisen tuloksen, vaikkakaan ei hienoa.

Käytimme tätä lähestymistapaa projektin kehittämiseen.