Weergawe beheer: waarom jy nie daarsonder kan leef nie
As u ‘n rekenaar gebruik, sal u waarskynlik verskillende weergawes van lêers in die gesig staar. Of dit nou ‘n kwessie is van tekslêers, datalêers of programkode wat u geskryf het, u sal altyd gekonfronteer word met die besluit of u die vorige weergawe moet stoor en vervang of stoor bykomend tot die vorige weergawe..
Vir enkelontwikkelaars is dit al ‘n uitdaging om die verskillende weergawes van ‘n program dop te hou, om nie te praat van al die verskillende rugsteune wat u moontlik maak nie.
Stel jou voor dat jy as deel van ‘n span werk aan ‘n projek wat teks, multimedia en kodering behels – kortom, ‘n groot verskeidenheid inligting in die werke.
Dink verder aan: sê dat daar aan verskillende data of programlêers gewerk word deur verskillende mense (“gelyktydigheid”) – elke persoon voeg weer by, stoor, redigeer en stoor. Hoe op aarde sal u weet wie gedoen het wat, wanneer en waarom, en in staat wees om al hierdie veranderinge op te spoor?
U het weergawebeheer (VC) nodig.
In hierdie artikel gaan ons kyk na wat weergawebeheer is en hoe dit ontwikkel het oor die jare heen tot die jongste geslag.
Ons sal veral kyk na Git, die toenemend gewilde weergawe-beheertoepassing van die mense wat Linux gemaak het, en ‘n paar voorbeelde sien van hoe u Git sou gebruik om beheer oor al die verskillende hersienings van u lêers te herwin..
1 ‘N Beginner vir VC Jargon
2.1 Eerste generasie
2.2 Tweede generasie
2.3 Derde geslag
3 ‘N Regte voorbeeld deur Git te gebruik
‘N Beginner vir VC Jargon
Weergawe beheer het sy eie taal. Nadat u gespesifiseer het watter kaarte of groep lêers hul veranderinge moet opspoor, is dit bekend, staan ​​die kaarte of lêers bekend as ‘n bewaarplek, of repo.
Veranderings word outomaties opgespoor, maar dit word slegs opgeteken as ‘n enkele versameling van aksies, genaamd ‘commit’, en opgeneem as ‘n veranderingsset met ‘n unieke hersieningsnommer. Dit verseker dat u die nuutste weergawe van ‘n lêer kan oproep.
As u twee hersienings wil vergelyk (byvoorbeeld as ‘n fout op een of ander tydstip in u kode ingesluip het), moet die weergawebeheerhulpmiddel u twee lêers laat verskil, wat beteken dat u die verskille tussen die twee sien.
Om met ‘n repo te eksperimenteer sonder om probleme of skade te waag, kan u ‘n tak skep, wat ‘n kopie van die repo beteken, en dan parallel kan verander. As die veranderinge in die tak bevredigend is, kan u die tak dan saamvoeg met die hoofrepo (meester), of selfs met ‘n ander tak.
By die samesmelting is moderne weergawe-beheerstelsels meestal slim genoeg om uit te vind watter veranderings ingesluit moet word uit watter tak of repo, volgens die veranderingsgeskiedenis wat vir elkeen onderhou word. As ‘n weergawe-beheerstelsel nie kan besluit nie, moet u moontlik ‘n konflik met die hand oplos.
Weergawebeheerinstrumente het tot dusver in drie generasies verskyn, en elke generasie het buigsaamheid en moontlikhede vir gelyktydigheid gevoeg.
Met oorspronklike weergawe-beheerstelsels, hoewel meerdere mense aan dieselfde lêer kon werk, kon hulle dit nie gelyktydig doen nie. Die lêer is gesluit om te keer dat ander toegang daartoe verkry.
‘N Voorbeeld van so ‘n instrument is SCCS (Source Code Control System) vir die ontwikkeling van sagteware vanaf 1972. RCS (Revision Control System) is as die gratis alternatief vir SCCS geskep en bied vinniger bediening, takke en samesmelting (wat nog steeds net een ontwikkelaar toelaat om op ‘n gegewe tydstip aan ‘n lêer te werk).
Baie weergawe kontroles wat tans in werking is, is in hierdie kategorie. Gelyktydige wysigings aan lêers is moontlik, hoewel gebruikers huidige hersienings in hul werk moet saamvoeg voordat hulle dit kan doen.
CVS (Concurrent Versions System) is een geval en laat interaksie tussen klante en bedieners toe met die gebruik van ‘n bewaarplek. SVN (of Apache Subversion volledig) is moontlik die gewildste van alle weergawe-beheerstelsels wat tans gebruik word.
SVN kan beskou word as ‘n herontwerp van CVN met ‘n moderne basis en oplossings vir voormalige CVS-beperkings.
Een van die bekendste voorbeelde is ook bekend as DVCS (Distribution Version Control Systems), met die moontlikheid om samesmeltings en bedrywighede te skei..
Daar is nie meer ‘n gesentraliseerde basis vir lêers nie; verskillende takke bevat verskillende dele, wat ook die deur oopmaak om ook op die regte pad aan hersienings te werk.
‘N Regte voorbeeld deur Git te gebruik
Hoe lyk die bewerkings hierbo beskryf as u ‘n werklike weergawe-beheerstelsel gebruik?
Ons neem Git hier as voorbeeld deur die Linux-opdragreël te gebruik. Eerstens skep ons ‘n Git-bewaarplek vir die gids waarin ons tans is. Ons gebruik die pwd-opdrag om te sien waar ons is:
/ Gebruikers / HJ / Desktop / repos / programme
Dan gebruik ons ​​die git init-opdrag om die bewaarplek (die “meester” -bewaarplek) te skep en terug te kry van Git:
Leë Git-bewaarplek is geïnisialiseer in /Users/HJ/Desktop/repos/apps/.git
Gestel ons voeg ‘n nuwe lêer, main.c, by ons werkgids. Die gebruik van die git-statusopdrag gee ons die volgende inligting:
# Op takmeester
# Aanvanklike begaan
# Onopgemerkte lêers:
# (gebruik "git voeg …" in te sluit in wat gepleeg sal word)
Ons gebruik git add om die lêer main.c op te spoor
1 $ git voeg hoof.c
Ons gebruik git commit met ‘n boodskap (-m-opsie) oor wat ons doen om veranderinge in die main.c-lêer aan te bring.
1 $ git commit -m "voeg main.c by die bewaarplek"
Nou kan ons ‘n tak (bv. “Toets”) met die git-takopdrag skep:
1 $ git tak toets
As u die Git-tak weer op sy eie gebruik, kan u slegs die bewaarplekke lys:
$ git tak
Ten slotte, om die kopie van main.c nou in die tak te begin werk, gebruik ons ​​die git checkout-opdrag om te bevestig dat ons nou in die “test” -tak werk..
Oorskakel na tak "toets"
Gebruik die git checkout-opdrag om weer terug te keer na die “master” -tak:
$ git checkout meester
Oorskakel na tak "meester"
Hoe om npm-pakkette op te dateer na hul nuutste weergawe
WinZip 21: Waarom miljoene gebruikers die sagteware vir lêerkompressie kies met verbeterde sekuriteit, deling en bestuursfunksionaliteit