0b10

Github blev lanceret i 2008. Hvis din ingeniørkarriere, som min, ikke er ældre end Github, så er Git muligvis det eneste versionsstyringsprogram, du nogensinde har brugt. Mens folk undertiden ryper om sin stejle indlæringskurve ellerunintuitive grænseflade, er Git blevet alles go-to til versionskontrol. InStack overløbs udviklerundersøgelse fra 2015, 69,3% af de adspurgte brugte Git,næsten to gange så mange som brugte det næstmest populære versionskontrolsystem, Subversion.1 efter 2015 stoppede Stack overløb med at spørge udviklere omversion kontrolsystemer, de bruger, måske fordi Git var blevet så populærtat spørgsmålet var uinteressant.

Git selv er ikke meget ældre end Github. Linus Torvalds udgav den førsteversion af Git i 2005. Selvom yngre udviklere i dag måske har svært ved at forestille sig en verden, hvor udtrykket “versionsstyringsprogram” ikke mere eller mindre bare betød Git, eksisterede en sådan verden ikke så længe siden. Der var mange alternativer at vælge imellem. Open source-udviklere foretrak Subversion, virksomheder og videospilfirmaer brugte Perforce (nogle gør det stadig), mens kernel-projektet berømt påberåbte sig et versionskontrolsystem kaldetbitkeeper.

Nogle af disse systemer, især BitKeeper, kan føle sig bekendt med en youngGit-bruger, der transporteres tilbage i tiden. De fleste ville ikke. BitKeeper til side, versioncontrolsystemerne, der kom før Git, fungerede efter et fundamentalt andet paradigme. I en taksonomi, der tilbydes af Eric Sink, forfatter af VersionControl ved eksempel, Git er et tredje generations versionskontrolsystem, mensde fleste af Gits Forgængere,de systemer, der var populære i 1990 ‘erne og begyndelsen af 2000’ erne, er andengenerations versionskontrolsystemer.2 Hvor tredje generationversion kontrolsystemer distribueres, anden generation version kontrolsystemer er centraliseret. Du har næsten helt sikkert hørt Git beskrevet som et” distribueret ” versionskontrolsystem før. Jeg har aldrig helt forstået dendistribueret / centraliseret skelnen, i det mindste ikke før jeg installerede ogeksperimenteret med et centraliseret anden generations versionskontrolsystemmig selv.

det system, jeg installerede, var CVS. CVS, forkortelse for Concurrent Versions System, varDet allerførste anden generations versionsstyringssystem. Det var også det mest populære versionskontrolsystem i omkring et årti, indtil det blev erstattet i 2000 af Subversion. Selv da skulle Subversion være” CV ‘er men bedre”, hvilket kun understreger, hvor dominerende CV ‘er var blevet gennem 1990’ erne.

CVS blev først udviklet i 1986 af en hollandsk computerforsker ved navn Dick Grune,der ledte efter en måde at samarbejde med sine studerende på et kompilatorprojekt.3 CVS var oprindeligt lidt mere end en samling af shell scriptindpakning RCS (Revision Control System), et første generations versionsstyringssystem, som Grune ønskede at forbedre. RCS fungerer efter en pessimistisklåsning model, hvilket betyder, at ikke to programmører kan arbejde på en enkelt fil atonce. For at redigere en fil skal du først bede RCS om en eksklusiv låsepå filen, som du opbevarer, indtil du er færdig med at redigere. Hvis en anden erredigerer allerede en fil, du skal redigere, Du skal vente. CVS forbedret på Rc ‘ er og indledte anden generation af versionsstyringssystemer ved at handle denpessimistiske låsemodel for en optimistisk. Programmører kunne nu redigere densamme fil på samme tid, fusionere deres redigeringer og løse eventuelle konfliktsenere. (Brian Berliner, en ingeniør, der senere overtog CVs-projektet, skrev et meget læsbart papirom CVs ‘ innovationer i 1990.)

i den forstand var CVS ikke så forskellig fra Git, som også fungererifølge en optimistisk model. Men det er her lighederne slutter. Faktisk, da Linus Torvalds udviklede Git, var et af hans vejledende principper, eller “hvad ville CVS ikke gøre.”Hver gang han var i tvivl om en beslutning,stræbte han efter at vælge den mulighed, der ikke var valgt i designet afcv’ er.4 så selvom CVS går forud for Git med over et årti, påvirkede det Git som en slags negativ skabelon.

Jeg har virkelig nydt at lege med CVS. Jeg tror, at der ikke er nogen bedre måde at forstå, hvorfor Git ‘ s distribuerede natur er sådan en forbedring af, hvad der kom før. Så jeg inviterer dig til at komme sammen med mig på en spændende rejse ogtilbringe de næste ti minutter af dit liv at lære om et stykke programmelingen har brugt i det sidste årti. (Se rettelse.)

Kom godt i gang med CVS

instruktioner til installation af CVS kan findes på project ‘ shomepage. På MacOS kan du installere CVS ved hjælp afhusbryggeri.

da CVS er centraliseret, skelner det mellem klientsideuniverset ogserversideuniverset på en måde, som noget som Git ikke gør. Denkarakter er ikke så udtalt, at der er forskellige eksekverbare filer. Men for at begynde at bruge CVS, selv på din egen maskine, skal du oprette theCVS backend.

CVS-backenden, den centrale butik for al din kode, kaldes depotet.Mens du i Git typisk vil have et lager for hvert projekt, i Cvsopbevaringsstedet indeholder alle dine projekter. Der er et centralt lager forAlt, selvom der kun er måder at arbejde med et projekt ad gangen.

for at oprette et lokalt lager kører du kommandoen init. Du ville gøre detteet sted globalt som din hjemmekatalog.

$ cvs -d ~/sandbox init

CVS giver dig mulighed for at videregive indstillinger til entencvs kommandoen selv eller tilinit underkommando. Indstillinger, der vises efter kommandoen cvs er globale inatur, mens indstillinger, der vises efter underkommandoen, er specifikke forunderkommandoen. I dette tilfælde er -d flag global. Her sker det at fortælle Cvshvor vi vil oprette vores lager, men generelt -d flag peger påplaceringen af det lager, vi vil bruge til en given handling. Det kan betedious at levere-d flag hele tiden, såCVSROOT environmentvariable kan indstilles i stedet.

da vi arbejder lokalt, har vi lige passeret en sti til vores -d argument,men vi kunne også have inkluderet et værtsnavn.

kommandoen opretter en mappe kaldetsandbox i din hjemmemappe. Hvis duliste indholdet af sandbox, vil du opdage, at det indeholder en anden direktørkaldet CVSROOT. Denne mappe, ikke at forveksle med miljøetvariabel, indeholder administrative filer til lageret.

Tillykke! Du har lige oprettet dit første CVs-arkiv.

kontrol af kode

lad os sige, at du har besluttet at føre en liste over dine yndlingsfarver. Du er en kunstnerisk tilbøjelig, men ekstremt glemsom person. Du skriver din listof farver og gemme det som en fil kaldet favorites.txt:

blueorangegreendefinitely not yellow

lad os også antage, at du har gemt din fil i en ny mappe kaldetcolors. Nu vil du gerne sætte din yndlingsfarveliste under versionskontrol,for halvtreds år fra nu vil det være interessant at se tilbage og se hvordandin smag ændrede sig gennem tiden.

for at gøre det skal du importere din mappe som et nyt Cvsprojekt. Du kan gøre det ved hjælp af kommandoenimport :

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

Her specificerer vi placeringen af vores lager med-d flagagain. De resterende argumenter sendes tilimport underkommando. Vi Harat give en besked, men her har vi ikke rigtig brug for en, så vi har forladt detblank. Det næste argument, colors, angiver navnet på vores nye mappe i repository; her har vi lige brugt det samme navn som den mappe, vi er i.De sidste to argumenter angiver henholdsvis vendor-tag og release-tag.Vi snakker mere om tags om et øjeblik.

du har lige trukket dit “farver” – projekt ind i CVs-arkivet. Der er et par forskellige måder at gå om at bringe kode i CVS, men dette er den metode anbefales af Pragmatic Version Control UsingCVS, den PragmaticProgrammer bog om CVS. Hvad der gør denne metode lidt akavet er, at duderefter skal du tjekke dit arbejde frisk, selvom du allerede har en eksisterende colors directory. I stedet for at bruge den mappe, skal du slette den og derefter tjekke den version, som CVS allerede kender til:

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

dette vil oprette en ny mappe, også kaldetcolors. I denne mappe finder du din originalefavorites.txt fil sammen med en mappe kaldetCVSCVS mappen er dybest set CVS’ ækvivalent med.git directoryin hvert Git-lager.

Foretag ændringer

gør dig klar til en tur.

ligesom Git har CVS enstatus subcommand:

det er her ting begynder at se fremmede ud. CVS har ikke begå objekter. Iovenstående er der noget, der hedder en “Commit Identifier”, men det kan kun værekun en relativt ny udgave—Ingen omtale af en “Commit Identifier” vises ipragmatisk versionskontrol ved hjælp af CVS, som blev offentliggjort i 2003. (Den lastupdate til CVS blev udgivet i 2008.5)

mens du med Git ville tale om versionen af en fil, der er knyttet til commit45de392, i CVS-filer versioneres separat. Den første version af yourfile er version 1.1, den næste version er 1.2, og så videre. Når filialer erinvolveret, tilføjes ekstra tal, så du kan ende med noget som 1.1.1.1 ovenfor, hvilket synes at være standard i vores tilfælde, selvom Vihar ikke oprettet nogen grene.

Hvis du skulle køre cvs log (svarende til git log) i et projekt med lotsof filer og forpligter, ville du se en individuel historie for hver fil. Du har muligvis en fil i version 1.2 og en fil i version 1.14 i det samme projekt.

lad os gå videre og foretage en ændring til version 1.1 af vores favorites.txt fil:

 blue orange green+cyan definitely not yellow

Når vi har foretaget ændringen, kan vi kørecvs diff for at se, hvad CVS mener, at vi har gjort:

CVS anerkender, at vi tilføjede en ny linje, der indeholder farven “cyan” tilfil. (Faktisk siger det, at vi har foretaget ændringer i “RCS” – filen; du kan se, atcvs aldrig helt undslap sin oprindelige tilknytning til RCS.) Den diff, vi bliver vist, er diff mellem kopien af favorites.txt i vores Arbejdsdirektorat og 1.1.1.1-versionen, der er gemt i lageret.

for at opdatere den version, der er gemt i depotet, skal vi begåændring. I Git ville dette være en multi-trins proces. Vi bliver nødt til at iscenesætte ændringen, så den vises i vores indeks. Så ville vi begå ændringen. Endelig, for at gøre ændringen synlig for nogen anden, bliver vi nødt til at skubbe forpligtelsen op til origin repository.

i CVS sker alle disse ting, når du kører cvs commit. CVS justbundles op alle de ændringer, den kan finde og sætter dem i depotet:

Jeg er så vant til at Git, at dette slår mig som skræmmende. Uden en mulighedat iscenesætte ændringer, enhver gammel ting, du har rørt i din arbejdsdirektørkunne ende som en del af det offentlige arkiv. Har du passivt-aggressivtomskrive en kollegas dårligt implementerede funktion ud af katartisk nødvendighed,aldrig til hensigt for ham at vide? Ærgerligt, han nu tror du er en pik. Du kan heller ikke redigere dine forpligtelser, før du skubber dem, da en forpligtelse er et skub. Nyder du at bruge 40 minutter gentagne gange på at køre git rebase -i, indtil din localcommit-historie flyder som afledningen af et matematisk bevis? Beklager, du kan ikke gøre det her, og alle vil finde ud af, at du ikke rent faktisk skriver dine tests først.

men jeg forstår også nu, hvorfor så mange mennesker finder Git unødvendigt kompliceret.Hvis cvs commit er det, du var vant til, så er jeg sikker på at iscenesættelse og pushingchanges ville slå dig som en meningsløs opgave.

når folk taler om, at Git er et “distribueret” system, er det først og fremmest forskellen de betyder. I CVS kan du ikke lave forpligtelser lokalt. En forpligtelse er somindsendelse af kode til det centrale lager, så det er ikke noget, du kan gøreuden en forbindelse. Alt du har lokalt er din arbejdsmappe. I Git har du et fuldt udbygget lokalt lager, så du kan lave forpligtelser hele dagen langselv mens du er afbrudt. Og du kan redigere disse forpligtelser, vende tilbage, gren, andcherry vælge så meget som du vil, uden at nogen andre behøver at vide.

da forpligtelser var en større aftale, lavede CVs-brugere dem ofte sjældent.Forpligtelser vil indeholde så mange ændringer, som vi i dag kunne forvente at se i Aten-commit pull-anmodning. Dette var især tilfældet, hvis commits udløste en CIbuild og en automatiseret test suite.

Hvis vi nu kører cvs status, kan vi se, at vi har en ny version af vores fil:

fletning

som nævnt ovenfor kan du i CVS redigere en fil, som en anden allerede erredigering. Det var CVS ‘ store forbedring på RCS. Hvad sker der, når du skal bringe dine ændringer sammen igen?lad os sige, at du har inviteret nogle venner til at tilføje deres yndlingsfarver tildin liste. Mens de tilføjer deres farver, beslutter du, at du ikke længereligesom farven grøn og fjern den fra listen.

når du går til at begå dine ændringer, kan du opdage, at CVS bemærker aproblem:

det ser ud til, at dine venner har begået deres ændringer først. Så din version affavorites.txt er ikke opdateret med versionen i depotet. Hvis yourun cvs status, vil du se, at din lokale kopi af favorites.txt er version1. 2 med nogle lokale ændringer, men repository-versionen er 1.3:

Du kan køre cvs diff for at se præcis, hvad forskellene mellem 1,2 og1.3 er:

det ser ud til, at vores venner virkelig kan lide pink. Under alle omstændigheder har de redigeret en anden del af filen, end vi har, så ændringerne er lette at flette. CVScan gøre det for os, når vi kører cvs update, som ligner 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

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

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

$ cvs rtag -b TRY_EXPERIMENTAL_THING colorscvs rtag: Tagging colors

$ cvs update -r TRY_EXPERIMENTAL_THING

$ cvs update -j TRY_EXPERIMENTAL_THING