0b10

GitHub lanseerattiin vuonna 2008. Jos ohjelmistosuunnittelijan urasi, kuten minun urani, ei ole GitHubia vanhempi, niin Git saattaa olla ainoa koskaan käyttämäsi versionhallintaohjelmisto. Vaikka ihmiset joskus raivostuvat sen jyrkästä oppimiskäyrästä taiunintuitiivinen käyttöliittymä, Git on tullut kaikkien go-to versionhallintaan. InStack Overflow ’ n vuoden 2015 kehittäjäkyselyssä 69,3% vastaajista käytti Git: tä, almostwiceä yhtä moni kuin toiseksi suosituinta versionhallintajärjestelmää Subversionia.1 vuoden 2015 jälkeen Stack Overflow lakkasi kyselemästä kehittäjiltä heidän käyttämistään versionhallintajärjestelmistä, ehkä siksi, että gitistä oli tullut niin suosittu, että kysymys oli mielenkiinnoton.

git itse ei ole paljon vanhempi kuin github. Linus Torvalds julkaisi Gitin ensimmäisen version vuonna 2005. Vaikka nykyään nuoremmilla kehittäjillä saattaa olla vaikeatajuistaminen maailmasta, jossa termi ”versionhallintaohjelmisto” ei enemmän tai vähemmän tarkoittanut vain Git: tä, tällainen maailma oli olemassa ei niin kauan sitten. Oli paljon vaihtoehtoja, joista valita. Avoimen lähdekoodin kehittäjät suosivat Subversionia, yritykset ja videopeliyritykset käyttivät Perforcea (jotkut käyttävät edelleen), kun taas theLinux kernel project tunnetusti tukeutui versionhallintajärjestelmään nimeltä BitKeeper.

jotkut näistä järjestelmistä, erityisesti BitKeeper, saattavat tuntua tutuilta ajassa taaksepäin kuljetetulle nuorelle Gitin käyttäjälle. Useimmat eivät. BitKeeper sikseen, gitiä edeltäneet versionohjausjärjestelmät toimivat fundamentally different paradigman mukaisesti. Versioncontrolin esimerkin kirjoittajan Eric sinkin tarjoamassa taksonomiassa Git on kolmannen sukupolven versionhallintajärjestelmä, kun taas Gitin edeltäjistä 1990-luvulla ja 2000-luvun alussa Suositut järjestelmät ovat toisen sukupolven versionhallintajärjestelmiä.2 Jos kolmannen sukupolven versionhallintajärjestelmät jaetaan, toisen sukupolven versionhallintajärjestelmät keskitetään. Olet lähes varmasti kuullut Gitin kuvailevan ”hajautetuksi” versionhallintajärjestelmäksi aiemminkin. En ole koskaan täysin ymmärtänyt thedistributed / keskitetty ero, ainakaan ennen kuin olen asentanut ja kokenut keskitetyn toisen sukupolven versionhallintajärjestelmän itse.

asentamani järjestelmä oli CVS. CVS, lyhyt samanaikaisten versioiden järjestelmä, oli ensimmäinen toisen sukupolven versionhallintajärjestelmä. Se oli myös suosituin versionhallintajärjestelmä noin vuosikymmenen ajan, kunnes Subversion korvasi sen vuonna 2000. Jo silloin Subversionin piti olla” CVS but better”, mikä vain alleviivaa sitä, kuinka hallitsevaksi CVS oli tullut koko 1990-luvun ajan.

CVS: n kehitti ensimmäisenä vuonna 1986 Hollantilainen tietojenkäsittelytieteilijä Dick Grune,joka etsi keinoa tehdä yhteistyötä oppilaidensa kanssa Compiler-projektissa.3 CVS oli aluksi vain kokoelma shell scriptswrapping RCS (Revision Control System), ensimmäisen sukupolven versionhallintajärjestelmä, jota Grune halusi parantaa. RCS toimii pessimistisen lukitus malli, mikä tarkoittaa, että ei kaksi ohjelmoijat voi työskennellä yhden tiedoston kerralla. Muokataksesi tiedostoa, sinun täytyy ensin pyytää RCS: ltä eksklusiivista lukkoa tiedostoon, jota pidät, kunnes olet valmis muokkaamaan. Jos joku muu onjo muokkaamassa tiedostoa, jota sinun täytyy muokata,sinun täytyy odottaa. CVS parani RC: llä ja toi markkinoille toisen sukupolven versionhallintajärjestelmät vaihtamalla pessimistisen lukitusmallin optimistiseen. Ohjelmoijat voivat nyt muokata samaa tiedostoa samanaikaisesti, yhdistäen muokkauksensa ja ratkaisemalla mahdolliset ristiriitatilanteet. (Brian Berliner, insinööri, joka myöhemmin otti CVs-projektin vastuulleen, kirjoitti hyvin luettavan paperin CVS: n innovaatioista vuonna 1990.)

siinä mielessä CVS ei juuri eronnut git: stä, joka myös toimii optimistisen mallin mukaisesti. Mutta siihen yhtäläisyydet loppuvat. Itse asiassa, kun Linus Torvalds oli kehittämässä Git: tä, yksi hänen ohjaavista periaatteistaan oli wwcvsnd eli ”mitä CVs ei tekisi.”Aina kun hän oli epävarma päätöksestä, hän pyrki valitsemaan vaihtoehdon, jota ei ollut valittu autojen suunnittelussa.4 joten vaikka CVS edeltää Git yli vuosikymmenen, se vaikutti Git asa eräänlainen negatiivinen malli.

olen todella nauttinut pelaamisesta CVS: n kanssa. En usko, että on parempaa tapaa ymmärtää, miksi Gitin hajautettu luonne on niin paljon parempi kuin mitä se oli aiemmin. Joten kutsun sinut mukaani jännittävälle matkalle ja viettämään seuraavat kymmenen minuuttia elämästäsi oppimalla pala softwarenobody on käytetty viime vuosikymmenellä. (KS. korjaus.)

CVS: n aloittaminen

ohjeet CVS: n asentamiseen löytyvät projektin kotisivulta. MacOS, voit asentaa CVs usingHomebrew.

koska CVS on keskitetty, se erottaa asiakaspuolen universumin ja palvelinpuolen universumin siten, että jotain Gitin kaltaista ei. Thedistinction ei ole niin voimakas, että on olemassa erilaisia suoritettavia. Jotta voit aloittaa CVS: n käytön jopa omalla koneellasi, sinun on kuitenkin määritettävä theCVS-taustajärjestelmä.

CVS-taustajärjestelmää, kaikkien koodiesi keskussäilöä, kutsutaan arkistoksi.Siinä missä Git: ssä sinulla on tyypillisesti arkisto jokaiselle projektille, CV: ssä arkisto sisältää kaikki projektisi. On olemassa yksi keskusvarasto kaikkea varten, vaikka on olemassa tapoja työskennellä vain projekti kerrallaan.

paikallisen arkiston luomiseksi suoritetaan komento init. Tekisit tämän jossain globaalissa paikassa, kuten kotihakemistossasi.

$ cvs -d ~/sandbox init

CVS: llä voi siirtää vaihtoehtoja joko cvs itse komentoon taiinit alikomentoon. cvs komennon jälkeen esiintyvät valinnat ovat yleisluontoisia, kun taas alikomennon jälkeen esiintyvät valinnat ovat erityisiä alikomennolle. Tällöin -d lippu on maailmanlaajuinen. Tässä se sattuu kertomaan CV: t, minne haluamme luoda arkiston, mutta yleensä -d lippu osoittaa sen arkiston sijainnin, jota haluamme käyttää mihin tahansa toimintaan. -d lippu voidaan toimittaa koko ajan, joten CVSROOT environmentvariable voidaan asettaa sen sijaan.

koska toimimme paikallisesti, olemme juuri ohittaneet polun -d argumentille,mutta olisimme voineet liittää mukaan myös isäntänimen.

komento luo kotihakemistoon hakemiston nimeltä sandbox. Jos luettelet sandbox sisällön, huomaat, että se sisältää toisen direktoraatin CVSROOT. Tämä kansio, jota ei pidä sekoittaa environmentvariable-kansioon, sisältää arkiston hallinnolliset tiedostot.

Onneksi olkoon! Olet juuri luonut ensimmäisen CVs-arkiston.

Checking in Code

sanotaan, että olet päättänyt pitää listaa suosikkiväreistäsi. Olet taiteellisesti taipuvainen, mutta erittäin huonomuistinen ihminen. Kirjoitat väriluettelosi ylös ja tallennat sen tiedostona nimeltä favorites.txt:

blueorangegreendefinitely not yellow

oletetaan myös, että olet tallentanut tiedostosi uuteen hakemistoon nimeltäcolors. Nyt haluat laittaa suosikkivärilistasi versiohallintaan, koska viidenkymmenen vuoden päästä on mielenkiintoista katsoa taaksepäin ja nähdä, miten makusi ovat muuttuneet ajan myötä.

tehdäksesi tämän, sinun on tuotava hakemistosi uutena CVSproject-projektina. Voit tehdä sen import komennolla:

$ cvs -d ~/sandbox import -m "" colors colors initialN colors/favorites.txtNo conflicts created by this import

tässä yksilöidään arkistomme sijainti -d flagagain. Loput argumentit siirtyvät import alikomentoon. Meidän on annettava viesti, mutta emme tarvitse sitä, joten jätimme sen tyhjäksi. Seuraava argumentti, colors, määrittää uuden hakemistomme nimen arkistossa; tässä olemme juuri käyttäneet samaa nimeä kuin hakemisto, jossa olemme.Kaksi viimeistä argumenttia määrittävät toimittajan tunnisteen ja julkaisutunnisteen vastaavasti.Puhutaan lisää tägeistä hetken päästä.

olet juuri vetänyt ”värit” – projektisi CVs-arkistoon. CVS: ään voidaan tuoda useita eri tapoja, mutta tämä on menetelmä, jota suosittelee Pragmatic Version Control UsingCVS, the Pragmatic Programmer book about CVs. Menetelmästä tekee hieman kiusallisen se, että nuorukainen joutuu tsekkaamaan teoksensa tuoreeltaan, vaikka on jo olemassa colors Hakemisto. Sen sijaan, että käyttäisit kyseistä hakemistoa, aiot poistaa sen ja tarkistaa sitten version, josta CVS jo tietää:

$ cvs -d ~/sandbox co colorscvs checkout: Updating colorsU colors/favorites.txt

Tämä luo uuden hakemiston, jota kutsutaan myös nimelläcolors. Tästä hakemistosta löytyy alkuperäinenfavorites.txttiedosto sekä kansioCVSCVShakemisto on periaatteessa CVS: n vastine.gitDirectoryn jokaisessa Git-arkistossa.

muutosten tekeminen

valmistaudu matkaan.

Gitin tavoin CVS: llä on status alikomentaja:

tässä asiat alkavat näyttää vierailta. CVS: ssä ei ole commit-objekteja. Yllä, on jotain kutsutaan ”Commit Identifier”, mutta tämä saattaa olla vain suhteellisen äskettäin painos—ei mainintaa” Commit Identifier ” näkyy inPragmatic Version Control käyttäen CVS, joka julkaistiin vuonna 2003. (Viimeinen päivitys CVS: ään julkaistiin vuonna 2008.5)

siinä missä git: llä puhuttiin toimitukseen liittyvän tiedoston versiosta45de392, CVS: ssä tiedostot versioidaan erikseen. Ensimmäinen versio yourfile on Versio 1.1, seuraava versio on 1.2, ja niin edelleen. Kun haarat ovat mukana, niihin liitetään lisänumeroita, joten saatat päätyä johonkin 1.1.1.1 edellä, mikä näyttää olevan oletuksena meidän tapauksessamme, vaikka emme ole luoneet haaroja.

Jos ajaisit cvs log (vastaa git log) projektissa, jossa on paljon tiedostoja ja toimituksia, näkisit jokaiselle tiedostolle yksittäisen historian. Voit tallentaa tiedoston versiossa 1.2 ja tiedoston versiossa 1.14 samaan projektiin.

mennään eteenpäin ja tehdään muutos favorites.txt file:

 blue orange green+cyan definitely not yellow

kun olemme tehneet muutoksen, voimme ajaa cvs diffnähdäksemme, mitä CVS luulee meidän ”tehneen:

CVS tunnustaa, että lisäsimme uuden rivin, joka sisältää värin” Syaani”. (Itse asiassa siinä sanotaan, että olemme tehneet muutoksia” RCS ” – tiedostoon; näet, että CVS ei koskaan täysin välttynyt alkuperäiseltä yhteydeltään RCS: ään.) Esitetty ero on ero favorites.txt työhakemistossamme olevan kopion ja arkistoon tallennetun 1.1.1.1-version välillä.

päivittääksemme arkistoon tallennetun version meidän on toimitettava muutos. Gitissä tämä olisi monivaiheinen prosessi. Meidän pitäisi lavastaa muutos niin, että se näkyy hakemistossamme. Sitten tekisimme muutoksen. Jotta muutos saataisiin näkyväksi kaikille muille, meidän on vietävä toimitus origin-arkistoon.

CVS: ssä kaikki nämä asiat tapahtuvat, kun ajetaan cvs commit. CVS vain tuo kaikki löytämänsä muutokset arkistoon:

olen niin tottunut Gitiin, että tämä tuntuu minusta pelottavalta. Jos näyttämömuutoksiin ei ole mahdollisuutta, kaikki vanhat asiat, joihin on kajottu, päätyvät julkiseen arkistoon. Kirjoititko passiivis-agressiivisesti työkaverin huonosti toteutetun toiminnon puhdistavasta tarpeesta, – etkä koskaan halunnut hänen tietävän? Harmi, hän pitää sinua mulkkuna. Et myöskään voi muokata toimituksiasi ennen niiden työntämistä, koska toimitus on push. Nautitko siitä, että käytät 40 minuuttia toistuvasti git rebase -i, kunnes localcommit-historiasi virtaa kuin matemaattisen todisteen derivointi? Valitan, et voi tehdä sitä täällä, ja kaikki saavat tietää, ettet oikeasti Kirjoita testejäsi ensin.

mutta ymmärrän nyt myös, miksi niin monet pitävät Gitiä tarpeettomasti monimutkaisena.Jos cvs commit on se, mihin oli tottunut, niin lavastus ja tyrkyttäminen tuntuisivat varmasti turhalta urakalta.

kun ihmiset puhuvat Gitin olevan ”hajautettu” järjestelmä, tämä on ensisijaisesti se ero, mitä he tarkoittavat. CVS: ssä ei voi tehdä toimituksia paikallisesti. Toimitus on koodin siirto keskusvarastoon, joten sitä ei voi jättää pois yhteydestä. Sinulla on vain työhakemistosi. Git: ssä käytössäsi on täysimittainen paikallinen arkisto, joten voit tehdä toimituksia koko päivän longeven ollessa suljettuna. Ja voit muokata näitä toimituksia, perua, haarautua ja Cherry valita niin paljon kuin haluat, kenenkään muun ei tarvitse tietää.

koska toimitukset olivat isompi juttu, CVS-käyttäjät tekivät niitä usein harvoin.Toimitukset sisältäisivät niin paljon muutoksia kuin tänään saatamme odottaa aten-commit pull-pyynnössä. Tämä piti erityisesti paikkansa, jos toimitukset käynnistivät CIbuild-ohjelman ja automatisoidun testisarjan.

Jos nyt ajetaan cvs status, tiedostostamme löytyy uusi versio:

yhdistäminen

kuten edellä mainittiin, CVS: ssä voi muokata tiedostoa, jota joku muu on jo muokkaamassa. Se oli CVS: n iso parannus RCS: ään. Mitä tapahtuu, kun haluat koota muutoksesi?

sanotaan, että olet kutsunut joitakin ystäviä lisäämään suosikkivärejään listaan. Kun he lisäävät värejään, sinä päätät, ettet pidäkään vihreästä väristä, ja poistat sen luettelosta.

kun siirryt toimittamaan muutoksesi, saatat huomata, että CVS huomaa ongelman:

näyttää siltä, että ystäväsi tekivät muutokset ensin. favorites.txt ei siis ole ajan tasalla arkistossa olevan version kanssa. Jos cvs status, näet että favorites.txt paikallinen kopiosi on version1. 2, jossa on joitakin paikallisia muutoksia, mutta arkiston versio on 1.3:

voit juosta cvs diff nähdäksesi tarkalleen, mitkä erot 1.2: n ja 1.3: n välillä ovat:

näyttää siltä, että ystävämme todella pitävät vaaleanpunaisesta. Joka tapauksessa he ovat muokanneet eri osaa tiedostosta kuin me, joten muutokset on helppo yhdistää. Cvsc voi tehdä sen meille juostessa cvs update, joka on samanlainen kuin git pull:

$ cvs updatecvs update: Updating .RCS file: /Users/sinclairtarget/sandbox/colors/favorites.txt,vretrieving revision 1.2retrieving revision 1.3Merging differences between 1.2 and 1.3 into favorites.txtM favorites.txt

Jos nyt katsoo favorites.txt, huomaat, että sitä on muokattu sisältämään muutokset, joita ystäväsi tekivät tiedostoon. Sinunkin muutoksesi ovat yhä siellä. Nyt olet vapaa toimittamaan tiedoston:

lopputulos on se, mitä saisit Gitissä ajamalla git pull --rebase. Sinun muutoksesi on lisätty ystäviesi muutosten päälle. Mergecommittia ei ole.”

joskus samaan tiedostoon tehdyt muutokset saattavat olla yhteensopimattomia. Jos ystäväsi olisivat vaihtaneet sanan ”vihreä” esimerkiksi ”oliiviksi”, se olisi ollut ristiriidassa sen kanssa, että vaihdoit sanan ”vihreä” kokonaan. CVS: n alkuaikoina tämä oli juuri sellainen tapaus, joka sai ihmiset huolestumaan, että CVS ei ollut turvallinen.; RCS: n pessimistinen lukitus varmisti, ettei tällaista tapausta voisi koskaan syntyä. CV takaa kuitenkin turvallisuuden varmistamalla, että kenenkään muutokset eivät ylikirjoitu automaattisesti. Sinun täytyy kertoa CVS: lle, mitä muutosta haluat jatkaa eteenpäin, joten kun suoritat cvs update, CVs merkitsee tiedoston molemmilla muutoksilla samalla tavalla kuin Git tekee, kun git havaitsee yhdistämisriidan. Tämän jälkeen sinun on muokattava tiedostoa manuaalisesti ja valittava haluamasi muutos.

mielenkiintoista tässä on huomata, että yhdistämisriidat on korjattava ennen kuin voit toimittaa ne. Tämä on toinen seuraus CVS: n keskittämisestä nature.In git, sinun ei tarvitse huolehtia fuusioiden ratkaisemisesta, ennen kuin painat paikallisia komiteoita.

tagit ja haarat

koska CVS: llä ei ole helposti osoitettavissa olevia toimituskohteita, ainoa tapa groupa-muutosten keräämiseen on merkitä tietty työhakemiston tila atag: llä.

tunnisteen luominen on helppoa:

$ cvs tag VERSION_1_0cvs tag: Tagging .T favorites.txt

voit myöhemmin palauttaa tiedostot tähän tilaan ajamallacvs updateja liittämällä tunnisteen -r lippu:

$ cvs update -r VERSION_1_0cvs update: Updating .U favorites.txt

koska tarvitset tunnisteen kelataksesi aikaisempaan työhakemistotilaan, CVs kannustaa paljon ennaltaehkäisevään tunnistamiseen. Ennen suuria refaktoreita, esimerkiksi, voit luoda BEFORE_REFACTOR_01 tagin, jota voit myöhemmin käyttää, jos therfactor meni pieleen. Ihmiset käyttivät myös tunnisteita, jos he halusivat luoda projektinlaajuisia diffejä. Periaatteessa kaikki asiat, joita me rutiininomaisesti teemme tänään commithashes on ennakoitava ja suunniteltava CVS, koska sinun piti olla tunnisteet jo saatavilla.

haaroja voidaan luoda CVS: ssä, tavallaan. Haarat ovat vain erityinen tunniste:

$ cvs rtag -b TRY_EXPERIMENTAL_THING colorscvs rtag: Tagging colors

, joka luo vain haaran (kaikkien nähden muuten), joten sinun on vielä vaihdettava siihen käyttämälläcvs update:

$ cvs update -r TRY_EXPERIMENTAL_THING

yllä olevat komennot siirtyvät uuteen haaraan nykyisessä työhakemistossa, mutta CVS: ää käyttävä pragmaattinen versionhallinta itse asiassa neuvoo luomaan uuden hakemiston uuden haaran pitämiseksi. Oletettavasti sen kirjoittajat löytivätkytkentä hakemistoja helpompaa kuin vaihtaa haaroja CVS.

pragmaattinen versionhallinta CVS: llä neuvoo myös olemaan luomatta haaroja olemassa olevasta haarasta. He suosittelevat vain haarojen luomista pois themainline-haarasta, joka git: ssä tunnetaan nimellä master. Yleensä haarautumista pidettiin ”edistyneenä” CVS-taitona. Git: ssä saatat aloittaa uuden haaran lähes mistä tahansa vähäpätöisestä syystä, mutta CVS: ssä haarautumista käytettiin yleensä vain silloin, kun se oli todella tarpeen, kuten julkaisuissa.

haara voitiin myöhemmin yhdistää takaisin päälinjaan käyttämällä cvs update ja -j lippua:

$ cvs update -j TRY_EXPERIMENTAL_THING

Kiitos Toimitushistoriasta

vuonna 2007 Linus Torvalds kertoi gitistä Googlella. Git oli hyvin Uusi silloin, joten puhe oli pohjimmiltaan yritys suostutella huoneellinen skeptisiä ohjelmoijia, että heidän pitäisi käyttää Git: tä, vaikka Git oli niin erilainen kuin mikään silloin saatavilla oleva. Jos et ole jo nähnyt puhetta, kehota sinua katsomaan sitä. Linus on viihdyttävä puhuja, vaikka henever epäonnistuukin röyhkeydessään. Hän tekee erinomaista työtä selittää, miksi hajautettu malli versionhallinta on parempi kuin keskitetty. Suuri osa hänen kritiikistään kohdistuu erityisesti ansioluetteloihin.

Git on monimutkainen työkalu. Sen oppiminen voi olla raastava kokemus. Mutta olen myös jatkuvasti hämmästynyt siitä, mitä gitcan tekee. Siihen verrattuna CVS on yksinkertainen ja suoraviivainen, joskaan se ei useinkaan pysty tekemään monia nykyisin itsestäänselvyyksinä pitämiämme operaatioita. Paluu takaisin ja CV: n käyttö hetkeksi on erinomainen tapa löytää itsensä uuden arvostuksen forGit ’ s voimaa ja joustavuutta. Se havainnollistaa hyvin, miksi ymmärtäminen historianohjelmistokehitys voi olla niin hyödyllistä-poimien ja uudelleen tutkiminenobsolete työkalut opettaa sinulle määriä siitä, miksi takana työkaluja käytämme tänään.

Jos tykkäsit tästä postauksesta, enemmän kuin se tulee ulos neljän viikon välein! Seuraa @TwoBitHistory Twitterissä tai Tilaa RSS-syöte varmista, että tiedät, kun uusi viesti on pois.

korjaus

minulle on kerrottu, että on olemassa monia organisaatioita, erityisesti riskialttiita organisaatioita, jotka tekevät asioita, kuten tekevät lääkinnällisten laitteiden ohjelmistoja, jotka käyttävät yhä ecvs: ää. Näiden organisaatioiden ohjelmoijat ovat kehittäneet pieniä temppuja CVS: n rajoitusten kiertämiseen, kuten uuden haaran tekeminen lähes jokaiselle vaihdolle, jotta he eivät sitoutuisi suoraan HEAD. (Kiitos Michael Kohne forpointing this out.)