0b10

Github ble lansert i 2008. Hvis din programvarekarriere, som min, ikke er eldre Enn Github, Kan Git være Den eneste versjonskontrollprogramvaren du noensinne har brukt. Mens folk noen ganger grouse om sin bratte læringskurve orunintuitive grensesnitt, Har Git blitt alles go-to for versjonskontroll. InStack Overflow ‘ s 2015 developer survey, 69,3% av respondentene brukte Git, nesten to ganger så mange som brukte det nest mest populære versjonskontrollsystemet, Subversion.1 Etter 2015 sluttet Stack Overflow å spørre utviklere omversjonskontrollsystemene de bruker, kanskje fordi Git hadde blitt så populært at spørsmålet var uinteressant.

Git selv er ikke mye eldre Enn Github. Linus Torvalds lanserte den førsteversjon Av Git i 2005. Selv om i dag yngre utviklere kan ha en hard tidoppfatning av en verden der begrepet «versjonskontrollprogramvare» ikke mer orless bare betyr Git, eksisterte en slik verden ikke så lenge siden. Det var mange alternativer å velge mellom. Open source utviklere foretrukket Subversion, bedrifter og videospill selskaper brukte Perforce (noen fortsatt gjør), mens theLinux kernel project berømt stolt på et versjonskontrollsystem kalt bitkeeper.Noen av disse systemene, spesielt BitKeeper, kan føle seg kjent for en youngGit-bruker som transporteres tilbake i tid. De fleste ville ikke. BitKeeper til side, versjonenkontrollsystemer som kom Før Git jobbet i henhold til et fundamentaltannerledes paradigme. I En taksonomi som Tilbys Av Eric Sink, forfatter Av VersionControl by Example, Er Git et tredje generasjons versjonskontrollsystem, mens De fleste Av Gits forgjengere, systemene som var populære på 1990-tallet og tidlig på 2000-tallet,er andre generasjons versjonskontrollsystemer.2 Der tredje generasjons versjonskontrollsystemer distribueres, er andre generasjons versjonskontrollsystemer sentralisert. Du har nesten sikkert hørt Git beskrevet som et» distribuert » versjonskontrollsystem før. Jeg forstod aldri helt distribuert / sentralisert forskjell, i hvert fall ikke før jeg installerte andexperimented med et sentralisert andre generasjons versjonskontrollsystemmyself.

systemet jeg installerte var CVS. CVS, kort For Samtidige Versjoner System, vardet aller første andre generasjons versjonskontrollsystemet. Det var også det mestpopulære versjonskontrollsystemet i omtrent et tiår til Det ble erstattet i 2000 ved Subversion. Selv da Skulle Subversion være «CVS but better», som bare understreker hvor dominerende CVS hadde blitt gjennom 1990-tallet.CVS ble først utviklet i 1986 av En nederlandsk datavitenskapsmann Ved navn Dick Grune,som lette etter en måte å samarbeide med elevene på et kompilerprosjekt.3 CVS var i utgangspunktet lite mer enn en samling av shell scriptswrapping RCS (Revision Control System), et første generasjons versjonskontrollsystem Som Grune ønsket å forbedre. RCS fungerer i henhold til en pessimistisklåsemodell, noe som betyr at ingen to programmerere kan jobbe på en enkelt fil på en gang. For å redigere en fil må DU først spørre RCS om en eksklusiv låspå filen, som du beholder til du er ferdig med å redigere. Hvis noen andre erallerede redigere en fil du må redigere, må du vente. CVS forbedret På RCSand innledet andre generasjon av versjonskontrollsystemer ved å handle thepessimistic låsing modell for en optimistisk en. Programmerere kan nå redigere thesame fil på samme tid, sammenslåing sine endringer og løse eventuelle konfliktslater. (Brian Berliner, en ingeniør som senere overtok CVS-prosjektet, skrevet meget lesbart papirom CVS’ innovasjoner i 1990.)

I den forstand VAR CVS ikke så forskjellig Fra Git, som også fungereri henhold til en optimistisk modell. Men det er der likhetene slutter. Infact, Da Linus Torvalds utviklet Git, var en av hans veiledende prinsipper wwwcvsnd, eller » Hva VILLE CVS Ikke Gjøre.»Når han var i tvil om en beslutning, forsøkte han å velge alternativet som ikke var valgt i utformingen avcvs.4 Så selv OM CVS forut For Git med over et tiår, påvirket Det Git som et slags negativt mal.

jeg har virkelig hatt glede av Å leke med CVS. Jeg tror det er ingen bedre måte å forstå hvorfor Git ‘ s distribuerte natur er en slik forbedring på hva som kom før. Så jeg inviterer deg til å bli med meg på en spennende reise ogtilbringe de neste ti minuttene av livet ditt å lære om et stykke programvareingen har brukt i det siste tiåret. (Se rettelse.)

Komme I Gang med CVS

Instruksjoner for installering AV CVS finner du på prosjektets hjemside. På MacOS kan du installere CVS ved hjelp avhomebrew.

SIDEN CVS er sentralisert, skiller den mellom klient-side universet og server-side universet på en måte som Noe Som Git ikke gjør. Dendistinksjon er ikke så uttalt at det er forskjellige kjørbare filer. Men inorder å begynne å bruke CVS, selv på din egen maskin, du må sette opp theCVS backend.

CVS-backend, det sentrale lageret for all koden din, kalles depotet.Mens I Git vil du vanligvis ha et lager for hvert prosjekt, i CVSthe depotet inneholder alle dine prosjekter. Det er ett sentralt lager foralt, selv om det finnes måter å jobbe med bare et prosjekt om gangen.

for å opprette et lokalt repository, kjører du kommandoen init. Du ville gjøre detteet sted globalt som hjemmekatalogen din.

$ cvs -d ~/sandbox init

CVS lar deg sende alternativer til entencvskommandoen selv eller tilinitunderkommandoen. Alternativer som vises etter kommandoencvser global innature, mens alternativer som vises etter underkommandoen, er spesifikke for underkommandoen. I dette tilfellet er-dflagget globalt. Her skjer det å fortelle Cvshvor vi vil lage vårt depot, men generelt peker-dflaggplasseringen til depotet vi vil bruke for en gitt handling. Det kan betedious å levere-dflagget hele tiden, såCVSROOTenvironmentvariable kan settes i stedet.

siden vi jobber lokalt, har vi nettopp passert en sti for vårt-d argument,men vi kunne også ha tatt med et vertsnavn.

kommandoen oppretter en katalog som heter sandbox i hjemmekatalogen din. Hvis youlist innholdet i sandbox, vil du finne at den inneholder en annen directorycalled CVSROOT. Denne katalogen, ikke forveksles med miljøetvariabel, inneholder administrative filer for depotet.

Gratulerer! Du har nettopp opprettet ditt første CVS-depot.

Sjekker Inn Kode

La oss si at du har bestemt deg for å beholde en liste over favorittfargene dine. Du eren kunstnerisk tilbøyelig, men ekstremt glemsom person. Du skriver inn listof colors og lagrer den som en fil som heter favorites.txt:

blueorangegreendefinitely not yellow

La oss også anta at du har lagret filen i en ny katalog som hetercolors. Nå vil du sette favorittfargelisten din under versjonskontroll,fordi femti år fra nå vil det være interessant å se tilbake og se hvordandin smak endret seg gjennom tiden.

for å gjøre det, må du importere katalogen som en ny CVSproject. Du kan gjøre det ved å bruke kommandoen import :

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

her spesifiserer vi plasseringen av depotet vårt med-d flaggetigjen. De resterende argumentene sendes tilimport underkommandoen. Vi har å gi en melding, men her trenger vi egentlig ikke en, så vi har forlatt itblank. Det neste argumentet, colors, angir navnet på vår nye katalog i depotet; her har vi nettopp brukt samme navn som katalogen vi er i.De to siste argumentene angir henholdsvis leverandørkoden og utgivelseskoden.Vi snakker mer om tagger om et minutt.

Du har nettopp trukket ditt» farger » – prosjekt inn I CVS-depotet. Det er acouple forskjellige måter å gå om å bringe kode INN CVS, men dette er themethod anbefalt Av Pragmatic Version Control UsingCVS, PragmaticProgrammer bok om CVS. Hva gjør denne metoden litt vanskelig er at youthen må sjekke ut arbeidet ditt friskt, selv om du allerede har anexistingcolors katalog. I stedet for å bruke den katalogen, skal duslette den og sjekk ut den versjonen SOM CVS allerede vet om:

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

dette vil opprette en ny katalog, også kalt colors. I denne katalogen finner du din opprinnelige favorites.txt fil sammen med en katalog kalt CVSCVS katalogen er I utgangspunktet CVS ‘ ekvivalent av.git katalogi hvert git-depot.

Gjør Endringer

Gjør deg klar for en tur.

AKKURAT Som Git, HAR CVS en status underkommando:

dette er hvor ting begynner å se fremmed. CVS har ikke forplikte objekter. I ovennevnte er det noe som kalles En «Commit Identifier», men dette kan være bare en relativt nylig utgave-ingen omtale av en» Commit Identifier » vises ipragmatisk Versjonskontroll Ved HJELP AV CVS, som ble publisert i 2003. (Lastupdate TIL CVS ble utgitt i 2008.5)

Mens Med Git vil du snakke om versjonen av en fil knyttet til commit 45de392, i CVS-filer versjoneres separat. Den første versjonen av yourfile er versjon 1.1, den neste versjonen er 1.2, og så videre. Når grener er involvert, legges ekstra tall til, så du kan ende opp med noe som 1.1.1.1 ovenfor, som ser ut til å være standard i vårt tilfelle, selv om vi ikke har opprettet noen grener.

hvis du skulle kjøre cvs log (tilsvarende git log) i et prosjekt med lotsof filer og inger, vil du se en individuell historie for hver fil. Du mighthave en fil på versjon 1.2 og en fil på versjon 1.14 i samme prosjekt.

La oss gå videre og gjøre en endring i versjon 1.1 av vår favorites.txt fil:

 blue orange green+cyan definitely not yellow

Når vi har gjort endringen, kan vi kjørecvs difffor å se hva CVS mener we ‘vedone:

CVS gjenkjenner at vi har lagt til en ny linje som inneholder fargen «cyan» tilfilen. (Faktisk står det at vi har gjort endringer i» RCS » – filen; du kan se at cvs aldri helt rømte sin opprinnelige tilknytning TIL RCS.) Forskjellen vi blir vist er forskjellen mellom kopien av favorites.txt i vår workingdirectory og 1.1.1.1-versjonen lagret i depotet.

for å oppdatere versjonen som er lagret i depotet, må vi forplikte segendre. I Git ville dette være en multi-trinns prosess. Vi må iscenesette endringen slik at den vises i indeksen vår. Da ville vi forplikte endringen. Til slutt, for å gjøre endringen synlig for noen andre, må vi presse forpliktelsen opp til origin-depotet.

I CVS skjer alle disse tingene når du kjører cvs commit. CVS legger bare opp alle endringene den kan finne og legger dem i depotet:

jeg er så vant Til Å Git at dette slår meg så skremmende. Uten en opportunityto scenen endringer, noen gamle ting som du har rørt i din arbeider directorymight ende opp som en del av det offentlige depotet. Har du passiv-aggressivtskriv en kollegas dårlig implementerte funksjon ut av katartisk nødvendighet,aldri tenkt for ham å vite? Synd, han tror nå at du er en pikk. Du kan ikke redigere dine forpliktelser før du skyver dem, siden en forpliktelse er et trykk. Do youenjoy tilbringe 40 minutter gjentatte ganger kjører git rebase -i til localcommit historie flyter som avledning av et matematisk bevis? Beklager, du kan ikke gjøre det her, og alle kommer til å finne ut at du ikke egentlig skriver testene dine først.

men jeg forstår nå også hvorfor Så mange mennesker finner Git unødvendig komplisert.Hviscvs commit er det du var vant til, så er jeg sikker på at staging og pushingchanges ville slå deg som en meningsløs oppgave.

når folk snakker Om Git som et» distribuert » system, er dette først og fremst forskjellen de mener. I CVS kan du ikke gjøre forpliktelser lokalt. En forpliktelse er å sende inn kode til det sentrale depotet, så det er ikke noe du kan gjøre uten tilkobling. Alt du har lokalt er arbeidskatalogen din. I Git har du et fullverdig lokalt lager, slik at du kan gjøre forpliktelser hele dagen lengeselv mens du er frakoblet. Og du kan redigere disse forplikter, gå tilbake, gren, andcherry plukke så mye du vil, uten at noen andre trenger å vite.

SIDEN forpliktelser var en større avtale, GJORDE CVS-brukere ofte dem sjelden.Inger vil inneholde så mange endringer som i dag vi kan forvente å se i aten-commit pull request. Dette var spesielt sant hvis inger utløste En CIbuild og en automatisert test suite.

hvis vi nå kjører cvs status, kan vi se at vi har en ny versjon av filen vår:

Sammenslåing

SOM nevnt ovenfor, I CVS kan du redigere en fil som noen andre allerede errediting. DET var CVS ‘ store forbedring på RCS. Hva skjer når du trenger å bringe endringene sammen igjen?

La oss si at du har invitert noen venner til å legge til sine favorittfarger tillisten din. Mens de legger til sine farger, bestemmer du at du ikke lengersom fargen grønn og fjern den fra listen.

når du går for å begå endringene dine, kan DU oppdage AT CVS merker aproblem:

det ser ut til at vennene dine har begått sine endringer først. Så din versjon avfavorites.txt er ikke oppdatert med versjonen i depotet. Hvis yourun cvs status, vil du se at din lokale kopi av favorites.txt er versjon1.2 med noen lokale endringer, men depotversjonen er 1.3:

du kan kjøre cvs diff for å se nøyaktig hva forskjellene mellom 1.2 og1. 3 er:

Det ser ut til at våre venner virkelig liker rosa. I alle fall har de redigert en annen del av filen enn vi har, så endringene er enkle å slå sammen. CVScan gjøre det for oss når vi kjører cvs update, som ligner på 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

Hvis du nå tar en titt påfavorites.txt, vil du finne at det har beenmodified å inkludere endringene som vennene dine har gjort til filen. Yourchanges er fortsatt der også. Nå er du fri til å begå filen:

sluttresultatet er hva Du vil få I Git ved å kjøre git pull --rebase. Yourchanges har blitt lagt på toppen av dine venners endringer. Det er ingen » mergecommit.»

noen ganger kan endringer i den samme filen være inkompatible. Hvis vennene dine hadchanged «grønn» til «oliven», for eksempel, ville det ha konflikt med yourchange fjerne «grønn» helt. I DE tidlige dagene AV CVS, dette var akkurat den type sak som fikk folk til å bekymre SEG FOR AT CVS var ikke trygt; RCS ‘ essimistiske låsing sørget for at et slikt tilfelle aldri kunne oppstå. Men Cvsgaranterer sikkerhet ved å sørge for at ingen endringer blir overskrivetautomatisk. Du må fortelle CVS hvilken endring du vil fortsette, så når du kjører cvs update, MARKERER CVS filen med begge endringerpå samme måte Som Git gjør når Git oppdager en fusjonskonflikt. Du deretter haveto manuelt redigere filen og velge endringen du vil beholde.

det interessante å merke seg her er at flettekonflikter må løses før du kan begå. Dette er en annen konsekvens AV CVS ‘ sentraliserte nature.In Git, du trenger ikke å bekymre deg for å løse fusjoner til du trykker på commits du har lokalt.

Koder og Grener

SIDEN CVS ikke har lett adresserbare commit-objekter, er den eneste måten å gruppere en samling av endringer på å markere en bestemt arbeidskatalogstatus med atag.

Å Lage en tag er enkelt:

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

du vil senere kunne returnere filer til denne tilstanden ved å kjørecvs updateog passere taggen til-rflagg:

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

Fordi Du trenger en kode for å spole tilbake til en tidligere arbeidskatalog tilstand, CVSencourages Mye preemptive tagging. Før store refactors,for eksempel, kan du opprette en BEFORE_REFACTOR_01 tag som du senere kan bruke hvis therefactor gikk galt. Folk brukte også tagger hvis de ønsket å generereprosjektbrede differ. I utgangspunktet må alle de tingene vi rutinemessig gjør i dag med commithashes forventes og planlegges for MED CVS, siden du trengte å ha kodene tilgjengelig allerede.

Grener kan opprettes I CVS, slags. Grener er bare en spesiell typetag:

$ cvs rtag -b TRY_EXPERIMENTAL_THING colorscvs rtag: Tagging colors

$ cvs update -r TRY_EXPERIMENTAL_THING

kommandoene ovenfor bytter til den nye grenen i din nåværende workingdirectory, men pragmatisk versjonskontroll ved hjelp av cvs anbefaler faktisk at Du Oppretter en ny katalog for å holde den nye grenen. Formentlig fant forfatterne sinebytte kataloger enklere enn å bytte grener i CVS.

Pragmatisk Versjonskontroll Ved HJELP AV CVS fraråder også å opprette branchesoff av en eksisterende gren. De anbefaler bare å lage grener av avmainline gren, som I Git er kjent som master. Generelt var forgreningbetraktet som en «avansert» CVS ferdighet. I Git kan du starte en ny gren fornesten hvilken som helst triviell grunn, men i CVS ble forgrening vanligvis bare brukt når det var nødvendig, for eksempel for utgivelser.

en gren kan senere slås sammen tilbake til hovedlinjen ved hjelp av cvs update andthe -j flagg:

$ cvs update -j TRY_EXPERIMENTAL_THING

Takk for Forplikte Historier

I 2007, Linus Torvalds ga atalk Om Git På Google. Git var veldig nytt da, så snakket var i utgangspunktet et forsøk på å overtale en rommelig skeptiske programmerere at De skulle bruke Git, selv Om Git var soliger fra alt som var tilgjengelig. Hvis du ikke allerede har sett snakk, Ihighly oppfordrer deg til å se den. Linus er en underholdende høyttaler, selv om han aldri unnlater å være hans brash selv. Han gjør en utmerket jobb med å forklare hvorforden distribuerte modellen for versjonskontroll er bedre enn den sentraliserte. Mye av hans kritikk er reservert FOR CVS spesielt.

Git Er et komplekst verktøy. Å lære det kan være enfrustrerende opplevelse. Men jeg er også stadig overrasket over de tingene Som Gitcan gjør. TIL sammenligning ER CVS enkel og grei, men ofte unableto gjøre mange av operasjonene vi nå tar for gitt. Å gå tilbake og bruke CVSfor en stund er en utmerket måte å finne deg selv med en ny forståelse forgits kraft og fleksibilitet. Det illustrerer godt hvorfor forstå historyof programvareutvikling kan være så gunstig—plukke opp og re-examiningobsolete verktøy vil lære deg mye om hvorfor bak verktøyene vi usetoday.

hvis du likte dette innlegget, mer som det kommer ut hver fjerde uke! Følg @ TwoBitHistory På Twitter eller abonnere PÅ RSS-feedå sørge for at du vet når et nytt innlegg er ute.

Korreksjon

jeg har blitt fortalt at det er mange organisasjoner, spesielt risiko-adverseorganisations som gjør ting som gjør medisinsk utstyr programvare, som fortsatt useCVS. Programmerere i disse organisasjonene har utviklet små triks forarbeid RUNDT CVS begrensninger, for eksempel å lage en ny gren for nesten everychange for å unngå å forplikte seg direkte til HEAD. (Takk Til Michael Kohne for å påpeke dette.)