Mitä on historia versionhallintajärjestelmissä. Gitiä käyttävä vakiotyönkulku näyttää suunnilleen tältä

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 ovat olleet käytössä vuodesta 1986, useimmat opetusohjelmat työskentelystä moderni versionhallintajärjestelmät osoittautuivat epätäydellisiksi ja voimakkaasti sidoksissa työskentelyyn komentorivin kanssa.

Meillä ei ole mitään komentoriviä vastaan ​​yleisesti, mutta pienessä kehitystiimissämme (4 henkilöä) ei ole komentorivin kanssa työskentelyn faneja :).

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

1. Ajanhukkaa tietojen syöttämiseen. Komentojen kirjoittaminen kestää paljon kauemmin kuin hiiren napsauttaminen.
2. Ajan hukkaa oppimiseen. Uuden syntaksin oppiminen puhtaiden 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 (kukaan ei ole kumonnut inhimillistä tekijää).
4. Rikkominen automaation periaatteet. Ehkä tämä on tärkein kohta. Tietokone on suunniteltu nopeuttamaan työtä ja korvaamaan henkilöä rutiininomaisissa toimissa. Komentorivin tapauksessa toimimme aina käsin itse asiassa täytyy joka kerta kirjoittaa sama ohjelmakoodi (vaikkakin primitiivinen).

1. Siellä on vaiheittaiset ohjeet (ohjelmoijamme työskentelevät sen parissa).
2. Se toimii alusta loppuun (eli sillä saat pienen mutta täydellisen tuloksen - toimivan hajautetun versionhallintajärjestelmän).
3. Toimii vain GUI:illa (katso syyt yllä).

Johdanto

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

Käytetyt 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ä Mercurialin versionhallintajärjestelmään.
• Bitbucket on Mercurial- ja Git-versionhallintaan perustuva projektien isännöinti- ja yhteistyöverkkopalvelu.

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

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 64-bittiselle Windowsille ja Mercurial 2.8.1.

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. Kehitykseen osallistuvien tiimien maksimimäärää on myös mahdollista kasvattaa maksuttomalla hinnalla 8 henkilöön asti.

Näet täydellisen luettelon suunnitelmista napsauttamalla linkkiä: https://bitbucket.org/plans

3. Kirjautumalla tilillesi Bitbucket-palvelussa, voit heti 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 – Määritä nimi uudelle tietovarastollesi. Tätä nimeä käytetään pääsylinkin luomiseen arkistoon.
Tärkeä! On parempi määrittää nimi latinalaisin kirjaimin, muuten linkki arkistoon päättyy yhdysmerkkeihin ja näyttää vaikealta ymmärtää: http://[email protected]/yourlogin/--------

Kuvaus – Anna lyhyt kuvaus arkistostasi (kenttä on valinnainen)
- Käyttöoikeustaso - Valitse valintaruutu, jos haluat, että vain kehitystiimisi jäsenillä on pääsy arkistoosi (yksityinen tietovarasto).
- Haarukoiden luominen - Valitse "Salli vain yksityiset haarukat"
- Arkiston tyyppi - Valitse "Mercurial"
- Projektinhallinta - Tarkista "Issue Tracker" ja "Wiki"
- 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 vielä kerran 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 siirtää kaikki tiedostot väliaikaisesti toiseen hakemistoon (tehdä varmuuskopio). Myöhemmin palautamme kaikki tiedostot paikoilleen, mutta toistaiseksi sinun 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 tililtäsi Bitbucket-palvelussa, syötä se.

10. Jos kaikki tehtiin tästä ohjeesta poikkeamatta, kansioon ilmestyy uusi ".hg"-hakemisto luodun arkiston palvelutiedostoineen.

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

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

12. Napsauta jälleen hiiren kakkospainikkeella projektikansioamme ja valitse avattavasta valikosta kohta "Hg Commit ..."

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

Sinun on valittava kaikki muutetut (lisätyt) tiedostot, määritettävä muutokseen kommentti (esimerkiksi versio 1.00) ja klikattava "Korjaa"-painiketta.

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

14. Jos kaikki tehtiin oikein, järjestelmä korjaa tehdyt muutokset ja näet seuraavanlaisen ikkunan:

Itse asiassa tulevaisuudessa, kun olet kehittämässä, suoritat pienen koodinpalan suorittamisen jälkeen toiminnon kappaleesta 12 (paina "Hg Commit ...") tehdäksesi muutoksen versionhallintajärjestelmään. Tämä antaa sinulle mahdollisuuden palauttaa järjestelmän edelliseen sitoumukseen milloin tahansa.

Yllä olevan perusteella käytännössä jokaiseen kiinnitykseen tulisi kirjoittaa tarkempi kommentti kuin "Versio 1.00".

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

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

Sen jälkeen sinulle näytetään valintaikkunat, joissa sinua pyydetään vahvistamaan "push" ja sinua pyydetään antamaan salasana 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-palvelimille. Bitbucket-tililläsi näet koko projektisi historian.

Versionhallintajärjestelmän (VCS) yhdistämisen välitulokset

Toisen tietokoneen yhdistämisprosessi on kopioida tiedostot arkistosta toiseen tietokoneeseen. Sinun on suoritettava vaiheet 1 - TortoiseHg:n asentaminen ja 7 - Tuo arkistotiedostot, jotta voit kopioida tiedostot toiseen, kolmanteen ja seuraavaan toimivaan tietokoneeseesi.

Työntekijöiden yhdistäminen arkistoon.

Yhdistetään nyt siis toinen ohjelmoija projektiimme (kutsumme osallistujan) ja perustetaan hänelle työpaikka.

Työntekijän yhdistäminen arkistoon

Kuinka rekisteröityä palveluun ja asentaa TortoiseHg, kerroin 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 antamaan sen käyttäjän sähköpostiosoite, jolle haluat antaa pääsyn tietovarastoon. Lisäksi sinun on määritettävä käyttöoikeudet ("luku" tai "kirjoitus"). Koska tässä oppaassa näytämme kuinka yhdistää toinen kehittäjä arkistoon ja määritä sitten "tietue".

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 jäsenten on rekisteröidyttävä Bitbucket-palveluun.

22. Kun kutsu on hyväksytty, uusi jäsen näkee tämän tietovaraston tilillään ja linkin päästäkseen siihen 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.

Mielestäni tämän johdantoartikkelin versionhallinnan käyttöönotosta ilman komentoriviä pitäisi päättyä tähän. Suorittamalla yllä kuvatut vaiheet voit toteuttaa projektissasi täysimittaisen VCS:n, ts. Kun olet käynyt läpi kaikki vaiheet, saat, vaikkakaan ei loistavan, mutta täydellisen tuloksen.

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

Misha Radionov

Mitä ovat versionhallintajärjestelmät ja miksi niitä tarvitaan

Kuvittele tilanne: palkkasit kehittäjän lisäämään esimerkiksi pikatilausominaisuuden verkkokauppaasi. Koska sivuston täytyy toimia ja tuottaa tuloja koko ajan, kehittäjä päättää työskennellä paikallisella palvelimellaan.

Sen toimiessa suunnittelija lähetti uuden logon, jonka vaihdoit välittömästi sivuston pääversion malliin. Samalla pienensit fonttia tuotteiden nimissä niin, että kaikki mahtuu jonkun asiakkaasi netbookin näytölle. Sitten päivitit pari tuotekuvaa. Tällä hetkellä kehittäjä päätti tehdä sinulle palveluksen – puhdistaa rehellisesti sanottuna tarpeettomat toiminnot sivustosi versiosta, jonka edellinen kehittäjä on kirjoittanut. Kuten usein tapahtuu, luulette molemmat, ettet ole tehnyt mitään vakavaa. Mutta olet väärässä.

Kun kehittäjän versio ladataan sivustolle, kaikki kehitystyön osallistujat pitävät päätään kiinni. Työtuloksesi pyyhitään, virheet putoavat. Mikä on ongelma, on epäselvää. Toivon, että tällä hetkellä sinulla on ainakin toimiva varmuuskopio käsillä ja pahimmassa tapauksessa vietät useita päiviä manuaalisesti ongelmien selvittämiseen. Miten tällaiseen tilanteeseen ei jouduta? Kerromme.

Mikä on VCS?

Versionhallintajärjestelmä (englannista. Version Control System, VCS tai Revision Control System) - ohjelmisto helpottaa muuttuvien tietojen kanssa työskentelyä. Wikipedia

Ja nyt yksinkertaisella tavalla

Versionhallintajärjestelmän avulla voit tallentaa useita versioita samasta asiakirjasta, palata tarvittaessa aikaisempiin versioihin, määrittää muutoksen tehnyt henkilö ja milloin ja paljon muuta.

Toisin sanoen VCS:n avulla useat kehittäjät voivat muokata samoja tiedostoja samanaikaisesti luomatta paikallisia kopioita tietokoneilleen. Tässä tapauksessa kaikki muutosversiot tallennetaan erikseen, ja voit tehdä samasta tiedostosta eri versioita, ottaen huomioon eri henkilöiden tekemät erilaiset muokkaukset. Jos useat muutokset vaikuttavat samaan asiakirjan osaan, järjestelmä kehottaa valitsemaan haluamasi vaihtoehdon.

Yleensä versionhallintajärjestelmän kanssa työskentelee erillistä tietokonetta (palvelinta) tai Internet-palvelua, joka tarjoaa mahdollisuuden vuokrata tällainen palvelin.

Yksinkertainen esimerkki

Jos useita ihmisiä työskentelee yhden Excel-dokumentin parissa, vain yksi henkilö voi muokata tiedostoa, loput saavat "vain luku"-oikeudet. VCS:n avulla saat mahdollisuuden muokata tiedostoa kerralla ja kaikkien toimesta. Ainoa ehto on, että muutosten tekemisen jälkeen tiedosto on tallennettava palvelimelle, ei paikalliselle tietokoneelle. Mutta kuten edellä mainittiin, työkalujen avulla voit suorittaa tällaiset toimet helposti ja yksinkertaisesti.

Versionhallintajärjestelmä Flag studiossa

Käytämme työssämme Git-versionhallintajärjestelmää. Tämä järjestelmä on yksi yleisimmistä VCS:istä. Tämä johtaa paljon tukea Gitiä käyttävältä yhteisöltä. Plussaa on myös järjestelmän yksinkertainen kehitys, koska. On olemassa laaja valikoima ohjelmistotuotteita, jotka on kehitetty erityisesti tätä järjestelmää varten.

Käytämme koodinkehitysohjelmaa nimeltä IntelliJ IDEA. Se tarjoaa IDE:n, eli suuren toiminnallisen perustan kehittäjille, mukaan lukien kätevän käyttöliittymän versionhallinnan kanssa työskentelemiseen. Joten poistumatta ohjelmasta voimme nähdä, mitä muutoksia yksi tai toinen kehittäjä on tehnyt tarvitsemallamme sivustolla. Tai ilman pelkoa muutosten menettämisestä, hanki muutokset toiselta kehittäjältä. IDEA-käyttöliittymä näyttää suunnilleen tältä:

Käytämme Bitbucket-pilvipalvelua versioiden tallentamiseen. Tässä palvelussa on kätevä käyttöliittymä ja versioidesi tallennuspalveluiden lisäksi voit hallita tuotteidesi käyttöoikeussääntöjä eri käyttäjille. Pilvitallennuskäytön etuna on se, että palvelimen asennuksen ja hallinnan tuntemukselle ei ole asetettu vaatimuksia. Saat kaiken laatikosta ja voit aloittaa sen käytön heti. Kaikki bitbucketiin lataamasi on yksityistä, ts. ilman lupaasi kukaan muu ei voi edes nähdä mitä tallennat. Bitbucket-käyttöliittymä:

Mikä antaa meille VCS:n käytön

• Täysi luottamus siihen, että järjestelmästä saamamme tiedostot ovat aina ajan tasalla ja milloin tahansa.
• Mahdollisuus saada vaadittu versio mistä tahansa tietokoneesta, jonka avulla voit muodostaa yhteyden palvelimeen.
• Kun tallennat tiedoston VCS:ään, sinun ei tarvitse ajatella, että joku saman tiedoston parissa työskentelevä tallentaa ja korvaa muutokset.
• Ohjelmistojen kehittäjille järjestelmän käyttö mahdollistaa myös jonkun kehittäjän tekemien muutosten hyväksymisen/hylkäämisen.

Mitä se antaa asiakkaillemme

Palataanpa alussa käsiteltyyn tilanteeseen. Kuten VCS:n kanssa. Kehittäjä lataa koodinsa erilliseen haaraan. Tarkistat muutokset ja otat ne käyttöön vain, jos näet, että kaikki on kunnossa. Kaikki säilytetään yhdessä paikassa turvallisesti, nopeasti ja kätevästi. Ja kun kehittäjiä on useita, et tule toimeen ilman VCS:ää ollenkaan.

Yleiskatsaus versionhallintajärjestelmiin

Versionhallintajärjestelmistä on tullut olennainen osa elämää paitsi ohjelmistokehittäjille, myös kaikille ihmisille, jotka kohtaavat intensiivisesti muuttuvan tiedon hallinnan ongelman ja jotka haluavat helpottaa elämäänsä. Tämän seurauksena on syntynyt suuri määrä erilaisia ​​tuotteita, jotka tarjoavat laajan valikoiman ominaisuuksia ja kattavat työkalut versionhallintaan. Tässä artikkelissa tarkastellaan lyhyesti niistä suosituimpia, niiden etuja ja haittoja.

Vertailun vuoksi valittiin yleisimmät versionhallintajärjestelmät: RCS, CVS, Subversion, Aegis, Monoton, Git, Bazaar, Arch, Perforce, Mercurial, TFS.

RCS on versioiden valvontajärjestelmä.
(www.gnu.org/software/rcs/rcs.html)

Aloitetaan katsaus yhdestä ensimmäisistä versionhallintajärjestelmistä - RCS:stä (Revision Control System - versionhallintajärjestelmä), joka kehitettiin vuonna 1985. Se korvasi tuolloin suositun versionhallintajärjestelmän SCCS (Source Code Control System).

RCS on nyt aktiivisesti korvattu tehokkaammalla versionhallintajärjestelmällä CVS, mutta se on edelleen melko suosittu ja on osa GNU-projektia.

RCS:n avulla voit työskennellä vain yksittäisten tiedostojen kanssa ja luoda jokaiselle muutoshistorian. Tekstitiedostoille ei tallenneta kaikkia tiedoston versioita, vaan vain uusin versio ja siihen tehdyt muutokset. RCS voi myös seurata muutoksia binääritiedostoihin, mutta jokainen muutos tallennetaan erillisenä versiona tiedostosta.

Kun yksi käyttäjä tekee muutoksia tiedostoon, tiedosto pysyy lukittuna kaikille muille. He eivät voi pyytää sitä arkistosta muokattavaksi ennen kuin ensimmäinen käyttäjä on tehnyt muutokset ja tehnyt ne.

Harkitse RCS-versionhallintajärjestelmän tärkeimpiä etuja ja haittoja.

Edut:

1. RCS - helppokäyttöinen ja hyvä versionhallintajärjestelmien periaatteisiin tutustumiseen.

2. Sopii yksittäisten tiedostojen varmuuskopiointiin, jotka eivät vaadi usein muutoksia käyttäjäryhmältä.

3. Laajalle levinnyt ja esiasennettu useimmissa ilmaisissa käyttöjärjestelmissä.

Virheet:

1. Jäljittää muutoksia vain yksittäisiin tiedostoihin, mikä ei salli sitä käyttää suurten projektien versionhallintaan.

2. Ei salli useiden käyttäjien tehdä muutoksia samaan tiedostoon samanaikaisesti.

3. Alhainen toiminnallisuus verrattuna nykyaikaisiin versionhallintajärjestelmiin.

Johtopäätökset:

RCS-versionhallintajärjestelmä tarjoaa liian heikot työkalut kehitysprojektien hallintaan ja soveltuu vain versionhallintatekniikkaan tutustumiseen tai yksittäisten tiedostojen pienen palautushistorian ylläpitämiseen.

CVS on samanaikainen versionhallintajärjestelmä.
(www.nongnu.org/cvs)

Concurrent Versions System on looginen kehitystyö Revision Control Systemistä (RCS), joka käyttää sen standardeja ja versionhallintaalgoritmeja, mutta on paljon toimivampi ja mahdollistaa yksittäisten tiedostojen lisäksi työskentelyn kokonaisten projektien kanssa.

CVS perustuu asiakas-palvelin-teknologiaan, joka on vuorovaikutuksessa verkon yli. Asiakas ja palvelin voivat sijaita myös samalla koneella, jos vain yksi henkilö työskentelee projektin parissa tai tarvitaan paikallista versionhallintaa.

CVS:n työ on järjestetty seuraavasti. Uusin versio ja kaikki tehdyt muutokset tallennetaan palvelimen arkistoon. Palvelimeen yhdistävät asiakkaat tarkistavat eroja paikallisen version ja viimeisimmän arkistoon tallennetun version välillä ja lataavat ne paikalliseen projektiinsa, jos niissä on eroja. Ratkaise tarvittaessa ristiriidat ja tee tarvittavat muutokset kehitettävään tuotteeseen. Tämän jälkeen kaikki muutokset ladataan palvelimen arkistoon. CVS:n avulla voit tarvittaessa palata haluttuun kehitettävän projektin versioon ja hallita useita projekteja samanaikaisesti.

Tässä ovat rinnakkaisen versionhallintajärjestelmän tärkeimmät edut ja haitat.

Edut:

1. Useat asiakkaat voivat työskennellä saman projektin parissa samanaikaisesti.

2. Voit hallita yhden tiedoston lisäksi kokonaisia ​​projekteja.

3. Siinä on valtava määrä käyttäjäystävällisiä graafisia käyttöliittymiä, jotka voivat tyydyttää melkein minkä tahansa, jopa vaativimmankin maun.

4. Laajassa käytössä ja toimitetaan oletuksena useimpien Linux-käyttöjärjestelmien kanssa.

5. Kun testitiedostoja ladataan arkistosta, vain muutokset siirretään, ei koko tiedostoa.

Virheet:

1. Kun tiedostoa tai hakemistoa siirretään tai nimetään uudelleen, kaikki tähän tiedostoon tai hakemistoon liittyvät muutokset menetetään.

2. Vaikeudet ylläpitää useita saman projektin rinnakkaisia ​​haaroja.

3. Rajoitettu tuki fonteille.

4. Jokaisen binaaritiedoston muutoksen yhteydessä tallennetaan koko tiedoston versio, ei vain tehtyä muutosta.

5. Asiakkaalta palvelimelle muutettu tiedosto siirretään aina kokonaan.

6. Resurssiintensiiviset toiminnot, koska ne vaativat jatkuvaa pääsyä arkistoon ja tallennetuissa kopioissa on jonkin verran redundanssia.

Johtopäätökset:

Huolimatta siitä, että CVS on vanhentunut ja siinä on vakavia puutteita, se on edelleen yksi suosituimmista versionhallintajärjestelmistä ja sopii erinomaisesti pienten projektien hallintaan, jotka eivät vaadi useiden rinnakkaisten versioiden yhdistämistä ajoittain. CVS:ää voidaan suositella välivaiheeksi versionhallintajärjestelmien hallinnassa, mikä johtaa tehokkaampiin ja nykyaikaisempiin tällaisten ohjelmien tyyppeihin.

Subversion versionhallintajärjestelmä.
(www.subversion.tigris.org)

Subversion on vuonna 2000 luotu keskitetty versionhallintajärjestelmä, joka perustuu asiakas-palvelin-tekniikkaan. Siinä on kaikki CVS:n edut ja se ratkaisee sen tärkeimmät ongelmat (tiedostojen ja hakemistojen uudelleennimeäminen ja siirtäminen, työskentely binääritiedostojen kanssa jne.). Sitä kutsutaan usein asiakaspuolen nimellä - SVN.

Työskentely Subversionin kanssa on hyvin samanlaista kuin työskentely CVS:n kanssa. Asiakkaat kopioivat muutokset arkistosta ja yhdistävät ne käyttäjän paikalliseen projektiin. Jos paikallisten muutosten ja arkistoon tallennettujen muutosten välillä on ristiriitoja, tällaiset tilanteet ratkaistaan ​​manuaalisesti. Tämän jälkeen paikalliseen projektiin tehdään muutoksia ja tulos tallennetaan arkistoon.

Kun työskentelet tiedostojen kanssa, jotka eivät salli muutosten yhdistämistä, voidaan käyttää seuraavaa periaatetta:

1. Tiedosto ladataan arkistosta ja estetään (lataus arkistosta on kielletty).

2. Tarvittavat muutokset tehdään.

3. Tiedosto ladataan arkistoon ja avataan (se on sallittua ladata arkistosta muille asiakkaille).

Pääosin yksinkertaisuuden ja CVS:n hallinnan samankaltaisuuden vuoksi, mutta pääasiassa laajan toiminnallisuutensa ansiosta, Subversion kilpailee menestyksekkäästi CVS:n kanssa ja jopa korvaa sen menestyksekkäästi.

Subversionilla on kuitenkin myös haittapuolensa. Tarkastellaan sen vahvuuksia ja heikkouksia muihin versionhallintajärjestelmiin verrattuna.

Edut:

1. CVS:n kaltainen komentojärjestelmä.

2. Useimmat CVS-ominaisuudet ovat tuettuja.

3. Erilaisia ​​graafisia käyttöliittymiä ja kätevä käyttö konsolista.

4. Tiedostojen ja hakemistojen muutoshistoriaa seurataan myös sen jälkeen, kun ne on nimetty uudelleen ja siirretty.

5. Tehokas työskentely sekä teksti- että binääritiedostojen kanssa.

6. Sisäänrakennettu tuki monille integroiduille kehitystyökaluille, kuten KDevelop, Zend Studio ja monet muut.

7. Kyky luoda arkistosta peilikopioita.

8. Kahden tyyppisiä arkistoja - tietokanta tai joukko tavallisia tiedostoja.

9. Mahdollisuus käyttää arkistoa Apachen kautta WebDAV-protokollan avulla.

10. Kätevän mekanismin läsnäolo tarrojen ja projektihaarojen luomiseen.

11. Voit liittää jokaiseen tiedostoon ja hakemistoon tietyn joukon ominaisuuksia, mikä helpottaa vuorovaikutusta versionhallintajärjestelmän kanssa.

12. Laajan levityksen avulla voit ratkaista nopeasti useimmat esiin tulevat ongelmat viittaamalla Internet-yhteisön keräämiin tietoihin.

Virheet:

1. Täysi kopio arkistosta on tallennettu paikalliselle tietokoneelle piilotiedostoina, mikä vaatii melko paljon muistia.

2. Tiedostojen uudelleennimeämisessä on ongelmia, jos toisen asiakkaan paikallisesti uudelleennimeämää tiedostoa on samaan aikaan muokattu ja ladattu arkistoon.

3. Huonosti tuettu hanketoimialojen yhdistäminen.

4. Vaikeudet arkistoon tulleiden tiedostojen tietojen täydellisessä poistamisessa, koska se sisältää aina tietoa tiedostoon tehdyistä aikaisemmista muutoksista, eikä ole olemassa säännöllisiä keinoja tiedostoa koskevien tietojen poistamiseksi kokonaan arkistosta.

Johtopäätökset:

Subversion on moderni versionhallintajärjestelmä, jossa on laaja valikoima työkaluja, jotka täyttävät kaikki projektiversioiden hallinnan tarpeet keskitetyn ohjausjärjestelmän avulla. Internetissä on monia Subversionin ominaisuuksille omistettuja resursseja, joiden avulla voit ratkaista nopeasti ja tehokkaasti kaikki työn aikana ilmenevät ongelmat.

Asennuksen helppous, työhön valmistautuminen ja laajat mahdollisuudet tekevät Subversionista yhden johtavista paikoista versionhallintajärjestelmien kilpailussa.

Aegis versionhallintajärjestelmä.

Peter Millerin vuonna 1991 luoma Aegis on ensimmäinen vaihtoehto keskitetyille versionhallintajärjestelmille. Kaikki sen toiminnot suoritetaan Unix-tiedostojärjestelmän kautta. Valitettavasti Aegiksessa ei ole sisäänrakennettua verkkotukea, mutta vuorovaikutuksia voidaan suorittaa käyttämällä protokollia, kuten NFS, HTTP, FTP.

Aegisin pääominaisuus on tapa hallita arkistoon tehtyjä muutoksia.

Ensinnäkin ennen muutosten tekemistä heidän on läpäistävä sarja testejä. Ja jos ohjelman lähdekoodin innovaatiot eivät läpäise testejä, on joko lisättävä uusia testejä tai korjattava mahdolliset virheet lähdekoodissa.

Toiseksi, ennen muutosten tekemistä kehitettävän hankkeen päähaaraan, ne on hyväksyttävä arvioijan toimesta.

Kolmanneksi arkistoon pääsyssä on hierarkia, joka perustuu Unix-tyyppisten käyttöjärjestelmien tiedostojen käyttöoikeusjärjestelmään.

Kaikki tämä tekee Aegis-versionhallintajärjestelmän käytöstä luotettavaa, mutta erittäin vaikeaa, eikä edes hyvin tutkittu dokumentaatio tee siitä paljon helpompaa.

Korostetaan Aegis-versionhallintajärjestelmän tärkeimmät edut ja haitat.

Edut:

1. Ladattujen muutosten oikeellisuuden luotettava valvonta.

2. Mahdollisuus tarjota eritasoisia pääsyoikeuksia arkistotiedostoihin, mikä antaa kunnollisen suojaustason.

3. Laatudokumentaatio.

4. Mahdollisuus nimetä uudelleen arkistoon tallennettuja tiedostoja menettämättä muutoshistoriaa.

5. Kyky työskennellä paikallisen arkiston kanssa, jos päätietovarastoon ei ole verkkoyhteyttä.

Virheet:

1. Sisäänrakennetun tuen puute verkottumista varten.

2. Arkiston asennuksen ja työskentelyn monimutkaisuus.

3. Heikko graafinen käyttöliittymä.

Johtopäätökset:

Aegisin monimutkaisuus voi estää käyttäjiä käyttämästä versionhallintajärjestelmiä, joten sitä ei voida suositella oppimiseen tai pienten ohjelmistoprojektien suorittamiseen. Sillä on kuitenkin useita etuja, joista voi olla hyötyä joissakin erityistilanteissa, varsinkin kun kehitettävän ohjelmiston laadun tiukkaa valvontaa vaaditaan.

Versionhallintajärjestelmä Monotone.
(monotone.ca)

Monotone on toinen Graydon Hoemin kehittämä hajautettu versionhallintajärjestelmä. Siinä jokainen asiakas on vastuussa kehitettävän tuotteen versioiden synkronoinnista muiden asiakkaiden kanssa.

Työskentely tämän versionhallintajärjestelmän kanssa on melko yksinkertaista, ja monet komennot ovat samanlaisia ​​kuin Subversionissa ja CVS:ssä. Erot ovat pääasiassa eri kehittäjien projektihaarojen yhdistämisen organisoinnissa.

Työskentely Monotonen kanssa on rakennettu seuraavasti. Ensin luodaan SQLite-projektitietokanta ja avaimet luodaan käyttämällä SHA1 (Secure Hash Algorithm 1) hajautusalgoritmia.

Sitten kun käyttäjä päivittää projektia, kaikki muutokset tallennetaan tähän tietokantaan, samoin kuin tallennettaessa muutoksia muiden versionhallintajärjestelmien arkistoon.

Jos haluat synkronoida projektin muiden käyttäjien kanssa, sinun on:

Vie avain (hash - projektin uusimman version koodi) ja hanki samanlaiset avaimet muilta asiakkailta.

Nyt jokainen tällä tavalla rekisteröitynyt käyttäjä voi synkronoida kehitystyön kollegoidensa kanssa käyttämällä yksinkertaista komentosarjaa.

Tehdään yhteenveto Monotone-versionhallintajärjestelmän eduista ja haitoista.

Edut:

1. Yksinkertainen ja selkeä komentosarja, joka muistuttaa Subversion- ja CVS-komentoja.

2. Tukee tiedostojen ja hakemistojen uudelleennimeämistä ja siirtämistä.

3. Laadukas dokumentaatio, joka helpottaa huomattavasti versionhallintajärjestelmän käyttöä.

Virheet:

1. Alhainen nopeus.

2. Tehokkaiden graafisten kuorien puute.

3. Mahdolliset (mutta erittäin alhaiset) sisällöltään erilaisten versioiden hash-koodin vastaavuudet.

Johtopäätökset:

Monotone on tehokas ja kätevä työkalu kehitettävän projektin versioiden hallintaan. Komentosarja on hyvin harkittu ja intuitiivinen, erityisesti käyttäjille, jotka ovat tottuneet työskentelemään Subversionin ja CVS:n kanssa. Hyvin suunniteltu ja täydellinen dokumentaatio auttaa sinua viihtymään nopeasti ja hyödyntämään Subversionin kaikkia ominaisuuksia täysillä.

Suhteellisen alhainen työnopeus ja tehokkaiden graafisten kuorien puute voivat kuitenkin tehdä suurten projektien kanssa työskentelyn jonkin verran vaikeaksi. Siksi, jos tarvitset versionhallintajärjestelmän tukemaan monimutkaisia ​​ja suuria tuotteita, sinun tulee kiinnittää huomiota Gitiin tai Mercurialiin.

Git versionhallintajärjestelmä.
(www.git-scm.com)

Helmikuusta 2002 lähtien useimmat ohjelmoijat ovat käyttäneet BitKeeper-versionhallintajärjestelmää Linux-ytimen kehittämiseen. Sen kanssa ei ollut pitkään aikaan ongelmia, mutta vuonna 2005 Larry McVoyem (BitKeeperin kehittäjä) veti pois ohjelman ilmaisen version.

On mahdotonta kehittää Linux-kokoista projektia ilman tehokasta ja luotettavaa versionhallintajärjestelmää. Yksi ehdokkaista ja sopivin projekti oli Monotine-versionhallintajärjestelmä, mutta Torvalds Linus ei ollut tyytyväinen sen nopeuteen. Koska Monatonen organisaation ominaisuudet eivät sallineet tietojenkäsittelyn nopeutta merkittävästi, Linus alkoi 3. huhtikuuta 2005 kehittää omaa versionhallintajärjestelmää - Git.

Melkein samanaikaisesti Linuksen kanssa (kolme päivää myöhemmin) Matt Makal aloitti myös uuden versionhallintajärjestelmän kehittämisen. Matt kutsui projektiaan Mercurialiksi, mutta siitä lisää myöhemmin, mutta nyt palataan Gitin hajautettuun versionhallintajärjestelmään.

Git on joustava, hajautettu (ilman yhtä palvelinta) versionhallintajärjestelmä, joka antaa paljon mahdollisuuksia paitsi ohjelmistokehittäjille, myös kirjoittajille muuttaa, täydentää ja seurata muutoksia "käsikirjoituksissa" ja tarinassa sekä opettajille korjata sekä kehittää luentojen kurssia ja ylläpitäjiä dokumentaatioon ja moniin muihin muutoshistorian hallintaa vaativiin alueisiin.

Jokaisella Gitiä käyttävällä kehittäjällä on oma paikallinen arkisto, joka mahdollistaa paikallisen versioinnin. Tämän jälkeen paikalliseen tietovarastoon tallennettuja tietoja voidaan vaihtaa muiden käyttäjien kanssa.

Usein Gitin kanssa työskennellessään he luovat keskustietovaraston, jonka kanssa muut kehittäjät synkronoivat. Esimerkki järjestelmän järjestämisestä keskustietovaraston kanssa on Linux-ytimen kehitysprojekti (http://www.kernel.org).

Tässä tapauksessa kaikki hankkeen osallistujat tekevät paikallista kehitystä ja lataavat päivitykset vapaasti keskusvarastosta. Kun yksittäiset projektin osallistujat ovat suorittaneet tarvittavat työt ja tehneet virheenkorjauksen, he, tarkistettuaan keskustietovaraston omistajan tekemän työn oikeellisuuden ja merkityksellisyyden, lataavat muutokset keskustietovarastoon.

Paikallisten arkiston läsnäolo lisää myös merkittävästi tietojen tallennuksen luotettavuutta, koska jos jokin arkistoista epäonnistuu, tiedot voidaan helposti palauttaa muista arkistoista.

Projektin versioiden käsittely Gitissä voidaan tehdä useissa haaroissa, jotka voidaan sitten helposti yhdistää kokonaan tai osittain, tuhota, rullata takaisin ja kasvaa yhä uusiksi projektin haaroiksi.

Voit keskustella Gitin mahdollisuuksista pitkään, mutta lyhyyden ja helpomman käsityksen vuoksi annamme tämän versionhallintajärjestelmän tärkeimmät edut ja haitat.

Edut:

1. Luotettava versioiden vertailu ja tietojen validointijärjestelmä, joka perustuu SHA1 (Secure Hash Algorithm 1) hajautusalgoritmiin.

2. Joustava järjestelmä projektien haaroittamisesta ja haarojen yhdistämisestä keskenään.

3. Paikallisen arkiston läsnäolo, joka sisältää täydelliset tiedot kaikista muutoksista, mahdollistaa täysimittaisen paikallisen versionhallinnan ja vain täysin varmennettujen muutosten lataamisen pääarkistoon.

4. Korkea suorituskyky ja nopeus.

5. Kätevä ja intuitiivinen komentosarja.

6. Paljon graafisia kuoria, joiden avulla voit nopeasti ja tehokkaasti työskennellä Gitin kanssa.

7. Mahdollisuus tehdä tarkistuspisteitä, joissa tiedot tallennetaan ilman deltapakkausta, mutta kokonaisuudessaan. Tämän avulla voit hidastaa tietojen palautuksen nopeutta, koska lähin tarkistuspiste otetaan perustana ja palautus etenee siitä. Jos tarkastuspisteitä ei olisi, suurten projektien toipuminen voi kestää tunteja.

8. Laaja, helppo saatavuus ja hyvä dokumentaatio.

9. Järjestelmän joustavuus mahdollistaa sen konfiguroinnin kätevästi ja jopa erikoistuneiden järjestelmäohjaimien tai käyttöliittymien luomisen gitiin perustuen.

10. Yleinen verkkoyhteys http-, ftp-, rsync-, ssh- jne. protokollien avulla.

Virheet:

1. Unix - suunta. Tällä hetkellä Gitillä ei ole kypsää toteutusta, joka olisi yhteensopiva muiden käyttöjärjestelmien kanssa.

2. Mahdolliset (mutta erittäin alhaiset) sisällöltään erilaisten versioiden hash-koodin vastaavuudet.

3. Yksittäisiin tiedostoihin tehtyjä muutoksia ei seurata, vaan vain koko projektin muutoksia, mikä voi olla hankalaa työskennellessään suurissa projekteissa, jotka sisältävät monia irrotettuja tiedostoja.

4. Arkiston alkuperäisen (ensimmäisen) luomisen ja sen synkronoinnin muiden kehittäjien kanssa tietojen lataaminen kestää melko kauan, varsinkin jos projekti on suuri, koska koko arkisto on kopioitava paikalliselle tietokoneelle .

Johtopäätökset:

Git on joustava, kätevä ja tehokas versionhallintajärjestelmä, joka voi tyydyttää suurimman osan käyttäjistä. Olemassa olevat puutteet poistetaan asteittain, eivätkä ne aiheuta vakavia ongelmia käyttäjille. Jos sinulla on käynnissä suuri, maantieteellisesti etäinen projekti, ja varsinkin jos kehität usein ohjelmistoja ilman, että sinulla on pääsy muihin kehittäjiin (esimerkiksi et halua tuhlata aikaa lentäessäsi maasta toiseen tai matkustaessasi töihin), voit tehdä mitä tahansa muutoksia ja tallentaa ne paikalliseen arkistoon, palauttaa, vaihtaa haarojen välillä jne.). Git on yksi johtajista versionhallintajärjestelmissä.

Mercurial versionhallintajärjestelmä.
(mercurial.selenic.com)

Mercurial-hajautetun versionhallintajärjestelmän kehitti Matt Makal rinnakkain Torvalds Linuksen luoman Git-versionhallintajärjestelmän kanssa.

Alun perin se luotiin suurten projektien tehokkaaseen hallintaan Linuxissa, ja siksi se keskittyi nopeaan ja luotettavaan työhön suurten arkiston kanssa. Tällä hetkellä mercurial on mukautettu toimimaan Windowsissa, Mac OS X:ssä ja useimmissa Unix-järjestelmissä.

Suurin osa versionhallintajärjestelmästä on kirjoitettu Pythonilla, ja vain tietyt ohjelman osat, jotka vaativat eniten suorituskykyä, on kirjoitettu C-kielellä.

Versiot tunnistetaan SHA1 (Secure Hash Algorithm 1) hajautusalgoritmin perusteella, mutta versioille on mahdollista antaa myös yksittäisiä numeroita.

Aivan kuten gitissä, kykyä luoda projektihaaroja ja sitten yhdistää ne tuetaan.

Asiakkaat kommunikoivat HTTP-, HTTPS- tai SSH-protokollien avulla.

Komentosarja on yksinkertainen ja intuitiivinen, aivan kuten subversion-komennot. Siellä on myös useita graafisia kuoria ja pääsy arkistoon verkkokäyttöliittymän kautta. Tärkeää on myös sellaisten apuohjelmien saatavuus, joiden avulla voit tuoda monien muiden versionhallintajärjestelmien arkistot.

Harkitse Mercurialin tärkeimpiä etuja ja haittoja.

Edut:

1. Nopea tietojenkäsittely.

2. Platform-tuki.

3. Kyky työskennellä projektin useiden osa-alueiden kanssa.

4. Helppo käsitellä.

5. Mahdollisuus muuntaa muiden versiointijärjestelmien arkistot, kuten CVS, Subversion, Git, Darcs, GNU Arch, Bazaar jne.

Virheet:

1. Mahdolliset (mutta erittäin alhaiset) sisällöltään erilaisten versioiden hash-koodin vastaavuudet.

2. Suuntautunut työskentelemään konsolissa.

Johtopäätökset:

Yksinkertainen ja hiottu käyttöliittymä ja joukko komentoja, mahdollisuus tuoda tietovarastoja muista versionhallintajärjestelmistä - tekevät siirtymisestä Mercurialiin ja pääominaisuuksien oppimisen kivuttomasti ja nopeasti. Se ei todennäköisesti kestä muutamaa päivää kauempaa.

Luotettavuus ja työn nopeus mahdollistavat sen käytön suurten projektien versionhallintaan. Kaikki tämä tekee mercurialista gitin arvoisen kilpailijan.

Bazaar-versionhallintajärjestelmä.
(bazaar.canonical.com)

Bazaar on hajautettu, avoimen lähdekoodin versionhallintajärjestelmä, joka on kehitetty Canonical Ltd:n tuella. Kirjoitettu Pythonilla ja toimii Linux-, Mac OS X- ja Windows-käyttöjärjestelmissä.

Toisin kuin Git ja Mercurial, jotka luotiin hallitsemaan Linux-käyttöjärjestelmän ytimen versioita ja jotka siksi keskittyivät maksimaaliseen suorituskykyyn työskennellessään valtavan määrän tiedostoja, Bazaar keskittyi kätevään ja ystävälliseen käyttöliittymään. Työn nopeuden optimointi tehtiin jo toisessa vaiheessa, kun ohjelman ensimmäiset versiot olivat jo ilmestyneet.

Kuten monissa muissakin versionhallintajärjestelmissä, Bazaarin komentojärjestelmä on hyvin samanlainen kuin CVS- tai Subversion-komento, mikä ei kuitenkaan ole yllättävää, sillä se tarjoaa kätevän, yksinkertaisen ja intuitiivisen käyttöliittymän vuorovaikutukseen ohjelman kanssa.

Hienoa, että projektihaarojen kanssa työskentelyyn (haarojen luomiseen, yhdistämiseen jne.) kiinnitetään suurta huomiota, mikä on erittäin tärkeää vakavia projekteja kehitettäessä ja mahdollistaa parannuksia ja kokeiluja ilman ohjelmiston pääversion menettämisen uhkaa.

Tämän versionhallintajärjestelmän suuri etu on kyky työskennellä muiden versionhallintajärjestelmien, kuten Subversionin tai Gitin, arkiston kanssa.

Tehdään lyhyesti yhteenveto tämän versionhallintajärjestelmän merkittävimmistä eduista ja haitoista.

Edut:

1. Platform-tuki.

2. Kätevä ja intuitiivinen käyttöliittymä.

3. Yksinkertainen työskentely projektihaarojen kanssa.

4. Kyky työskennellä muiden versionhallintajärjestelmien arkistojen kanssa.

5. Erinomainen dokumentaatio.

6. Kätevä graafinen käyttöliittymä.

7. Äärimmäinen joustavuus tietyn käyttäjän tarpeiden mukaan.

Virheet:

1. Pienempi nopeus verrattuna gitiin ja mercurialiin, mutta tätä tilannetta korjataan vähitellen.

2. Täydellistä toimintaa varten on asennettava riittävän suuri määrä laajennuksia, joiden avulla voit paljastaa täydellisesti kaikki versionhallintajärjestelmän ominaisuudet.

Johtopäätökset:

Bazaar on kätevä versionhallintajärjestelmä mukavalla käyttöliittymällä. Sopii käyttäjille, jotka ovat tyrmistyneet mahdollisuudesta työskennellä komentorivin kanssa. Monien lisävaihtoehtojen ja laajennusten avulla voit mukauttaa ohjelmaa tarpeidesi mukaan. Komentojärjestelmän samankaltaisuus Gitin ja Subversionin kanssa ja kyky työskennellä suoraan niiden arkiston kanssa tekevät siirtymisestä Bazaariin nopean ja kivuttoman. Basaaren menestyksestä kertoo myös se, että Ubuntu Linux -kehittäjät käyttävät sitä.

Arch versionhallintajärjestelmä.

Arch on Tom Lordin luoma hajautettu versionhallintajärjestelmä. Se luotiin alun perin ratkaisemaan ongelmia CVS:n kanssa, mikä onnistui melko hyvin.

Arch suorittaa atomioperaatioita arkiston muutosten tallentamiseksi, ts. eliminoi arkiston lataustilanteen, kun osa muutoksista on ladattu ja osa ei ole vielä latautunut.

Se tukee mahdollisuutta haaroittaa projektiversioita ja yhdistää yksittäisiä haaroja, nimetä uudelleen ja siirtää tiedostoja ja hakemistoja säilyttäen samalla muutoshistorian ja monia muita mukavia ominaisuuksia.

Se ei vaadi erikoispalvelua verkkovarastolle ja voi käyttää protokollia, kuten FTP, SFTP tai WebDAV ja niin edelleen.

Mutta valitettavasti vain UNIX-järjestelmiä tuetaan, mutta Archin siirtämisen muihin käyttöjärjestelmiin ei pitäisi olla vaikeaa.

On vaikea osoittaa mitään olennaisesti parempia ominaisuuksia verrattuna muihin hajautettuihin versionhallintajärjestelmiin, kuten git, mercurial, basaari, joten jos sinulla on valinnanvaraa, on parempi käyttää jotain tehokkaampaa ja laajempaa.

Suorita versionhallintajärjestelmä.
(www.perforce.com)

Jatketaan versionhallintajärjestelmien tarkastelua ja siirrytään kaupallisiin ohjelmiin. Aloitetaan keskitetystä versionhallintajärjestelmästä - Perforce, jonka on kehittänyt Perforce Software.

Perforce-järjestelmässä on asiakas-palvelin-organisaatio, ja sen avulla voit hallita useita projekteja samanaikaisesti luomalla jokaiselle projektille oman arkiston.

Perforce on monialustainen järjestelmä. On versioita, jotka voivat toimia käyttöjärjestelmissä Unix, Mac OS X, Microsoft Windows.

Työskennelläksesi versionhallintajärjestelmän kanssa voit käyttää sekä konsolia että erityisesti suunniteltua graafista käyttöliittymää.

Perforcen suuri etu on sen kyky integroida moniin ohjelmistokehitystyökaluihin ja -sovelluksiin, kuten Autodesk 3D Studio Max, Maya, Adobe Photoshop, Microsoft Office, Eclipse, emacs ja monet muut.

Tuki mahdollisuudelle luoda projektiversioiden haaroja, hallita niitä joustavasti, yhdistää, palauttaa aikaisempiin versioihin - tekee Perforcesta täysin kilpailukykyisen järjestelmän ja edistää sen laajaa jakelua. Tämä tuote on kuitenkin kaupallinen, mikä kaventaa jonkin verran sen käyttöaluetta ja vaikeuttaa jakelua. Pohjimmiltaan sitä käytetään suurissa kaupallisissa yrityksissä, joille ei ole tärkeää vain toimivuus, vaan myös oikea-aikainen tekninen tuki.

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

Tarkkaan ottaen Team Foundation Serveriä (TFC) ei voi kutsua vain versionhallintajärjestelmäksi - se on eräänlainen monimutkainen ratkaisu, joka sisältää versionhallintajärjestelmän, tiedonkeruujärjestelmän, raportoinnin ja muita hyödyllisiä toimintoja.

TFC:n kanssa työskenneltäessä hallittu projekti koostuu projektin lähdekoodihaaroista, raporttijoukoista ja mukautetuista elementeistä. Projektia luotaessa sen parametrit on esivalittu, jotka voit valita joko itse tai käyttää malleja. Mallien avulla voit määrittää projektin kehityspolun, tehdä siitä joustavan tai tiukasti muotoillun, laatia kehittämisstrategian, ottaa huomioon tarvittavat asiakirjojen ja raporttien valmistelut.

TFC integroituu saumattomasti Microsoft Excelin ja Microsoft Projectin kanssa, mikä tekee ohjattujen projektien luomisesta ja seuraamisesta paljon helpompaa.

Versionhallintajärjestelmänä TFC mahdollistaa:

Tee yhteistyötä projektitiedostojen kanssa;

Ratkaise ristiriidat;

Luo projektihaaroja ja yhdistä ne sitten;

Hallinnoi pääsyä tietovarastoon;

Palaa edellisiin versioihin;

Luo odottavia muutoksia - muutokset, joita ei lisätä suoraan arkistoon, mutta muut käyttäjät näkevät ne, ja voit ladata nämä muutokset vasta saatuasi erityisluvan muutosten omistajalta;

Merkitse tiedostojen yksittäiset versiot arkistossa ja ryhmittele ne;

SQL Server 2005 -tietokantoja käytetään tietojen ja arkiston tallentamiseen kehitteillä olevista projekteista.

TFC on tehokas ja kätevä työkalu, jonka avulla voit paitsi hallita lähdekoodiversioita, myös järjestää koko projektin kehityssyklin kokonaan ohjelmien kirjoittamisesta niiden dokumentointiin. Tämä tehokas ja monimutkainen järjestelmä soveltuu kuitenkin paremmin suuriin projekteihin, jotka vaativat monimutkaista ja perusteellista kehityshallintaa. Jos sinulla on pieni kehitystyö, on järkevää käyttää vähemmän tehokasta työkalua ja vielä paremmin vapaasti jaettua työkalua, koska tämä säästää aikaa, rahaa ja hermoja.

Yleistys.

Laaja valikoima versionhallintajärjestelmiä antaa sinun täyttää kaikki vaatimukset ja järjestää työn haluamallasi tavalla. Kaiken järjestelmän joukossa on kuitenkin selkeitä johtajia. Joten jos sinun täytyy hallita valtavaa projektia, joka koostuu kymmenistä tuhansista tiedostoista ja jonka parissa tuhannet ihmiset työskentelevät, paras valinta on pysähtyä Gitiin tai Mercurialiin. Jos sinulle tärkeintä on käyttäjäystävällinen käyttöliittymä, eikä kehitettävä projekti ole kovin suuri, niin Bazaar-järjestelmä on sinulle parempi.

Yksinohjelmoijille tai pienille projekteille, jotka eivät vaadi haarautumista ja useita versioita, Subversion on paras valinta.

Mutta loppujen lopuksi valinta on makuasia, koska nyt on monia versionhallintajärjestelmiä, jotka tarjoavat sinulle kaiken tarvitsemasi. Joten valitse, etkä tule katumaan sitä. Versionhallintajärjestelmät ovat ehdottoman välttämättömiä ohjelmistoja jokaiselle kehittäjälle eikä vain.

Ivan Nemytsenko, GitLab
Helpota elämääsi ohjelmistotuotteiden yhteiskehityksellä.

Aleksanteri Makarchuk, qb
Ryhmän kehittämisen optimointi.

Petr Urvaev SimbirSoft
Kehityksen aikana projektin koodi muuttuu aktiivisesti. Samalla on tarpeen pitää kirjaa siitä, mitä on jo tehty, ja koordinoida yksittäisten osallistujien toimia koodin muuttamiseksi samanaikaisesti niin, että projektiin osallistujien parannuksissa otetaan huomioon kaikki muiden osallistujien aiemmin tekemät muutokset. . Versionhallintajärjestelmän avulla voit automatisoida tämän prosessin.

2. Mitkä tekijät vaikuttavat versionhallintajärjestelmän valintaan?

Nikolai Fetyukhin.MST
Versionhallintajärjestelmän ytimen tuki ja sen spesifinen toteutus, tiimin perehdyttäminen siihen. Useimmiten kaikissa projekteissa käytetään yhtä järjestelmää. Poikkeuksia voivat olla esimerkiksi asiakkaiden vaatimukset.

Ivan Nemytsenko, GitLab
Tietyn järjestelmän suosio, josta kaikki muu seuraa: tuki sovelluksissa ja palveluissa, dokumentaation määrä ja laatu, asiantuntijan läsnäolo "käsillä" jne.

Aleksanteri Makarchuk, qb
Meidän tapauksessamme valinta perustuu versionhallintajärjestelmän suosioon ja sen kehittäjien omistusasteeseen.

Petr Urvaev SimbirSoft
Ensinnäkin - versionhallintajärjestelmän ominaisuuksien yhteensopivuus tiimissä hyväksytyn kehitysprosessin kanssa. Toiseksi, mikä versionhallintajärjestelmä on tutumpi projektin osallistujille.

3. Miten versionhallintajärjestelmän käyttö toteutetaan tiimissä?

Nikolai Fetyukhin.MST
Nyt jopa nykyaikaiset opiskelijat ovat jo valmistumassa yleisellä ymmärryksellä siitä, mihin versionhallintajärjestelmiä tarvitaan, joten toteutuskysymys ei ole täysin oikea. Yleensä kaikki projektit alkavat oletusarvoisesti arkiston luomisella. Jos yleisessä tapauksessa, sinun tulee keskustella tiimin kanssa, selvittää, miksi projektissa ei ole versionhallintajärjestelmää (joskus on useita hyvin erityisiä tapauksia), ja jos ongelmat voidaan voittaa, pidä pari seminaaria tiimin sisällä tietyssä versionhallintajärjestelmässä (tarvittaessa) ja suorita.

Ivan Nemytsenko, GitLab
Anna heille mahdollisuus työskennellä ilman versionhallintajärjestelmää, jotta he tuntevat kaiken tuskan. Sitten "liistaa" heille Git-cheatsheet, ja he itse oppivat ja toteuttavat kaiken. Mutta näin voit työskennellä koululaisten ja opiskelijoiden kanssa. Aikuisilla kehittäjillä ei yleensä ole tätä kysymystä.

Aleksanteri Makarchuk, qb
Hitaasti mutta varmasti jokainen on tulossa tähän omaan tahtiin.

Petr Urvaev SimbirSoft
Useimmissa nykyaikaisissa projekteissa versionhallintajärjestelmän käyttötarve ei herätä kysymyksiä. Kun opettelet työskentelemään sen kanssa, riittää sen konfigurointi kätevää työtä varten ja lukea lyhyt luento käytetyn versionhallintajärjestelmän pääominaisuuksista käyttöesimerkeineen.

4. Mikä teki Gitistä standardin versionhallintamaailmassa? Pystyykö joku poistamaan hänet johtoasemasta?

Nikolai Fetyukhin.MST
Git sisälsi alun perin muutamia hyödyllisiä asioita, kuten paikallisia sitoumuksia, ja ratkaisi myös monia haaran yhdistämisongelmia, joita edellisessä suunnannäyttäjässä Subversionissa (SVN) oli runsaasti. Alusta alkaen hän taisteli suosiosta Mercurialin (Hg) kanssa, joka on joissain asioissa yksinkertaisempi, mutta lopulta otti johtoaseman.

Ivan Nemytsenko, GitLab
Kiitos siitä, että Linus Torvalds hyökkäsi hajautetun kehityksen ongelmaan oikealta puolelta ottaen huomioon edeltäjien järjestelmien puutteet. Syrjäyttää? Mitä varten?

Aleksanteri Makarchuk, qb
Kiitos siitä, että Git - hyvin tehty. Pitkään aikaan kukaan ei poista häntä.

Petr Urvaev SimbirSoft
Gitin tärkein etu on työkalujen kehittäminen sen kanssa työskentelyyn ja kyky tallentaa siihen useiden rinnakkaisten avoimien tehtävien työn tulokset siten, että välitulokset eivät vaikuta toisiinsa, ja samalla lopputulokset voivat voidaan helposti yhdistää yhdeksi lopulliseksi sovelluksen versioksi. GitHubilla on myös ollut tärkeä rooli Gitin yleisessä suosiossa CVS-maailmassa, sillä se on isännöinyt tuhansia tietovarastoja eri kielillä.

5. Mistä kehittäjät eivät pidä Gitissä? Miksi jotkut valitsevat muita vähemmän suosittuja ratkaisuja?

Nikolai Fetyukhin.MST
Ainoa Gitin haittapuoli, josta olemme huolissamme, on joitakin muutosten seurantaan liittyviä ongelmia: haarat voidaan poistaa ja jäljelle jää vain yhdistämissitoumus. Tämä johtuu suurelta osin siitä, että Git-haarat on sidottu sitoumuksiin. Gitillä on myös jyrkempi oppimiskäyrä kuin edellä mainitulla Mercurialilla tai Subversionilla.

Aleksanteri Makarchuk, qb
Tehtävämme puitteissa kaikki ovat tyytyväisiä.

Petr Urvaev SimbirSoft
Git on riittävän kätevä, mutta vaatii oppimista (niille, jotka eivät vielä tiedä) ja aktiivisen siirtymisen siihen, joten jotkut tiimit haluavat pysyä käyttämiensä versionhallintajärjestelmien parissa. Myös versionhallintajärjestelmän valinta voidaan määrätä käytettävien kehitystyökalujen mukaan.

6. Kuinka yleistä on versionhallintajärjestelmien käyttö muiden tiedostojen kuin pelkän koodin hallintaan?

Nikolai Fetyukhin.MST
Tällä hetkellä kaikkialla. Samat pilvijärjestelmät, kuten One Drive, Yandex.Disk, Dropbox ja Google Drive, sisältävät periaatteessa ideologian, joka toistaa versionhallintajärjestelmiä.

Käytännössä perinteisten versionhallintajärjestelmien käyttö asiakirjojen tallentamiseen on yleistä, mutta ei kovin yleistä, muutosten laskennassa syntyy hienouksia, koska suurin osa nykypäivän yleisistä dokumenttiformaateista on binäärimuotoisia, eivätkä niiden muutosjoukot ole ihmisen luettavissa.

Aleksanteri Makarchuk, qb
Jatkuvasti käytössä.

Petr Urvaev SimbirSoft
Versionhallintajärjestelmät on ensisijaisesti tarkoitettu työskentelemään suuren määrän pieniä tiedostoja, joita käytetään pääasiassa kehitystyössä. Tällaisten järjestelmien käyttö ei-tekstimuotoisille tiedostoille (binääri) on pääsääntöisesti tehotonta ja joissakin tapauksissa jopa mahdotonta. Siksi muiden tiedostojen tallentamiseen käytetään yleensä erikoisjärjestelmiä, jotka on mukautettu toimimaan tiettyjen tietomuotojen kanssa.