Github werd gestart in 2008. Als jouw software engineering carrière, zoals de mijne, niet ouder is dan Github, dan is Git misschien de enige versie controle software die je ooit hebt gebruikt. Terwijl mensen soms klagen over de steile leercurve of een intuïtieve interface, is Git ieders go-to geworden voor versiebeheer. InStack Overflow ‘ s 2015 developer survey, 69,3% van de respondenten gebruikt Git, bijna evenveel als gebruikt de tweede meest populaire versie controle systeem,Subversion.1 na 2015 stopte Stack Overflow met het vragen van ontwikkelaars naar deversion besturingssystemen die ze gebruiken, misschien omdat Git zo populair was geworden dat de vraag oninteressant was.
Git zelf is niet veel ouder dan Github. Linus Torvalds bracht de eerste versie van Git uit in 2005. Hoewel jongere ontwikkelaars het vandaag misschien moeilijk hebben om een wereld te ontdekken waar de term “version control software” niet meer of minder gewoon Git betekende, bestond zo ‘ n wereld nog niet zo lang geleden. Er waren veel alternatieven om uit te kiezen. Open source ontwikkelaars gaven de voorkeur aan Subversion, bedrijven en video game bedrijven gebruikten Perforce (sommige nog steeds), terwijl theLinux kernel project vertrouwde op een versie controle systeem genaamd BitKeeper.
sommige van deze systemen, met name BitKeeper, kunnen vertrouwd aanvoelen bij een youngGit-gebruiker die terug in de tijd is getransporteerd. De meesten niet. BitKeeper terzijde, de versioncontrol systemen die voor Git kwamen werkten volgens een fundamenteel verschillend paradigma. In een taxonomie aangeboden door Eric Sink, auteur van VersionControl by Example, is Git een derde generatie versiebeheersysteem, terwijl de meeste van Git ‘ s voorgangers, de systemen die populair waren in de jaren 1990 en begin jaren 2000,tweede generatie versiebeheersystemen zijn.2 Waar systemen van de derde generatie worden gedistribueerd, worden systemen van de tweede generatie voor versiebeheer gecentraliseerd. Je hebt Git bijna zeker eerder als een”gedistribueerd” versiebeheersysteem horen beschrijven. Ik heb nooit helemaal begrepen dedistributed / gecentraliseerde onderscheid, althans niet totdat ik geà nstalleerd en ervaren met een gecentraliseerde tweede generatie versie controle systeem zelf.
het systeem dat ik installeerde was CVS. CVS, kort voor Concurrent Versions System, was het allereerste tweede generatie versiebeheersysteem. Het was ook het meest populaire versiebeheersysteem voor ongeveer een decennium totdat het in 2000 werd vervangen door Subversion. Zelfs toen werd Subversion verondersteld “CVS but better” te zijn, wat alleen maar onderstreept hoe dominant CVS in de jaren negentig was geworden.CVS werd voor het eerst ontwikkeld in 1986 door de Nederlandse computerwetenschapper Dick Grune,die op zoek was naar een manier om met zijn studenten samen te werken aan een compilerproject.3 CVS was aanvankelijk weinig meer dan een verzameling van shell scriptswrapping RCS (Revision Control System), een eerste generatie versiebeheersysteem dat Grune wilde verbeteren. RCS werkt volgens een pessimisticlocking model, wat betekent dat geen twee programmeurs kunnen werken aan een enkel bestand atonce. Om een bestand te bewerken, moet u eerst RCS vragen om een exclusieve lockon het bestand, die u houdt totdat u klaar bent met bewerken. Als iemand anders al bezig is met het bewerken van een bestand dat je moet bewerken, moet je wachten. CVS verbeterde RC ‘ s en luidde de tweede generatie versiecontrolesystemen in door het essimistische vergrendelingsmodel in te ruilen voor een optimistische. Programmeurs kunnen nu hetzelfde bestand op hetzelfde moment bewerken, hun bewerkingen samenvoegen en elk conflictlater oplossen. (Brian Berliner, een ingenieur die later het CVS-project overnam, schreef in 1990 een zeer leesbaar papier over de innovaties van CVS.)
in die zin was CVS niet zo verschillend van Git, dat ook werkt volgens een optimistisch model. Maar dat is waar de overeenkomsten eindigen. In feite, toen Linus Torvalds Git aan het ontwikkelen was, was een van zijn leidende principes wwcvsnd, of “wat zou CVS niet doen.”Wanneer hij twijfelde over een beslissing,streefde hij naar de optie die niet was gekozen in het ontwerp van VSV’ s.4 dus ook al is CVS meer dan tien jaar ouder dan Git, het beïnvloedde Git asa een soort negatieve template.
Ik heb echt genoten van het spelen met CVS. Ik denk dat er geen betere manier is om te begrijpen waarom de gedistribueerde aard van Git zo ‘ n verbetering is ten opzichte van wat daarvoor kwam. Dus nodig ik je uit om met me mee te gaan op een spannende reis en de komende tien minuten van je leven te besteden aan het leren over een stuk software dat iemand de afgelopen tien jaar heeft gebruikt. (Zie correctie.)
aan de slag met CVS
instructies voor het installeren van CVS zijn te vinden op de projectpagina. Op MacOS kunt u CVS installeren methomebrew.
omdat CVS gecentraliseerd is, maakt het een onderscheid tussen het universum aan de clientzijde en het universum aan de serverzijde op een manier die iets als Git niet doet. De distinctie is niet zo uitgesproken dat er verschillende uitvoerbare bestanden zijn. Maar om CVS te kunnen gebruiken, zelfs op je eigen machine, moet je de CVS backend instellen.
de CVS-backend, de centrale opslag voor al uw code, wordt de repository genoemd.Terwijl je in Git meestal een repository voor elk project zou hebben, bevat de repository in Cvst al je projecten. Er is één centrale repository voor alles, hoewel er manieren zijn om met slechts een project tegelijk te werken.
om een lokale repository aan te maken, voer je het init commando uit. Je zou dit doen ergens wereldwijd zoals je home directory.
$ cvs -d ~/sandbox init CVS stelt u in staat om opties door te geven aan de opdracht cvsof aan de subopdrachtinit. Opties die verschijnen na het cvs Commando zijn globale innature, terwijl opties die verschijnen na het subcommando specifiek zijn voor het subcommando. In dit geval is de -d vlag globaal. Hier vertelt het Cvsw waar we onze repository willen aanmaken, maar in het algemeen wijst de -d naar de locatie van de repository die we voor een bepaalde actie willen gebruiken. Het kan belangrijk zijn om de -d de hele tijd aan te geven, zodat de CVSROOT environmentvariable kan worden ingesteld.
omdat we lokaal werken,hebben we net een pad doorgegeven voor ons -d argument, maar we hadden ook een hostnaam kunnen toevoegen.
het commando maakt een map aan genaamd sandbox in uw persoonlijke map. Als u de inhoud van sandbox op een lijst plaatst, zult u zien dat het een andere directory bevat met de naam CVSROOT. Deze map, niet te verwarren met de environmentvariable, bevat administratieve bestanden voor de repository.
Gefeliciteerd! Je hebt zojuist je eerste CVS repository aangemaakt.
controle in Code
stel dat u hebt besloten om een lijst van uw favoriete kleuren bij te houden. Je bent een artistiek geneigd maar extreem vergeetachtig persoon. U typt uw lijst met kleuren in en slaat deze op als een bestand genaamd favorites.txt:
blueorangegreendefinitely not yellowlaten we ook aannemen dat u uw bestand hebt opgeslagen in een nieuwe map genaamdcolors. Nu wilt u uw favoriete kleurenlijst onder versiebeheer zetten, omdat het over vijftig jaar interessant zal zijn om terug te kijken en te zien hoe uw smaak door de tijd is veranderd.
om dat te doen, moet u uw map importeren als een nieuw CVSproject. U kunt dat doen met de opdracht import :
$ cvs -d ~/sandbox import -m "" colors colors initialN colors/favorites.txtNo conflicts created by this import Hier specificeren we de locatie van onze repository met de -dflagagain. De overige argumenten worden doorgegeven aan de subopdracht import. We moeten een boodschap geven, maar hier hebben we er geen nodig, dus we hebben het leeg gelaten. Het volgende argument, colors, specificeert de naam van onze nieuwe map in de repository; hier hebben we net dezelfde naam gebruikt als de map waarin we ons bevinden.De laatste twee argumenten specificeren respectievelijk de vendor tag en de release tag.We praten zo verder over tags.
je hebt zojuist je “colors” project naar de CVS repository getrokken. Er zijn een paar verschillende manieren om code in CVS te brengen, maar dit is de methode die wordt aanbevolen door Pragmatic Version Control UsingCVS, het PragmaticProgrammer boek over CVS. Wat deze methode een beetje lastig maakt, is dat je je werk opnieuw moet bekijken, ook al heb je al een bestaande colors directory. In plaats van die directory te gebruiken, ga je het verwijderen en bekijk dan de versie die CVS al kent:
$ cvs -d ~/sandbox co colorscvs checkout: Updating colorsU colors/favorites.txtDit maakt een nieuwe map aan, ook wel colors. In deze map vindt u het originele favorites.txt bestand samen met een map genaamdCVS. DeCVS directory is in principe CVS’ equivalent van de.git directory in elke Git repository.
wijzigingen aanbrengen
maak je klaar voor een reis.
net als Git heeft CVS een status subcommando:
Dit is waar dingen er buitenaards beginnen uit te zien. CVS heeft geen commit objecten. In het bovenstaande is er iets dat een “Commit Identifier” wordt genoemd, maar dit kan slechts een relatief recente editie zijn—geen vermelding van een “Commit Identifier” verschijnt inPragmatic Version Control met behulp van CVS, die in 2003 werd gepubliceerd. (De laatste datum naar CVS werd uitgebracht in 2008.5)
terwijl je met Git zou praten over de versie van een bestand dat geassocieerd is met commit45de392, worden in CVS bestanden afzonderlijk versiebeheer. De eerste versie van uw bestand is Versie 1.1, de volgende versie is 1.2, enzovoort. Wanneer branches betrokken zijn, worden extra getallen toegevoegd, dus je zou kunnen eindigen met iets als de 1.1.1.1 hierboven, wat in ons geval de standaard lijkt te zijn, ook al hebben we geen branches aangemaakt.
als je cvs log (gelijk aan git log) in een project met veel bestanden en commits zou draaien, zou je een individuele geschiedenis voor elk bestand zien. Je hebt misschien een bestand op versie 1.2 en een bestand op versie 1.14 in hetzelfde project.
laten we een wijziging aanbrengen in versie 1.1 van ons favorites.txt bestand:
blue orange green+cyan definitely not yellow zodra we de wijziging hebben gemaakt, kunnen we cvs diffuitvoeren om te zien wat CVS denkt dat we gedaan hebben:
CVS herkent dat we een nieuwe regel hebben toegevoegd met de kleur” cyaan ” aan het bestand. (Eigenlijk staat er dat we wijzigingen hebben aangebracht in het” RCS ” bestand; Je kunt zien dat CVS nooit volledig ontsnapt is aan de oorspronkelijke associatie met RCS.) De diff die we tonen is de diff tussen de kopie van favorites.txt in onze workingdirectory en de 1.1.1.1 versie opgeslagen in de repository.
om de in de repository opgeslagen versie bij te werken, moeten we de wijziging vastleggen. In Git zou dit een proces met meerdere stappen zijn. We zouden de verandering zo moeten opvoeren dat het in onze index verschijnt. Dan zouden we de verandering begaan. Tot slot, om de verandering zichtbaar te maken voor iemand anders, moeten we de commit naar de origin repository pushen.
in CVS gebeuren al deze dingen wanneer u cvs commituitvoert. CVS bundelt alle wijzigingen die het kan vinden en zet ze in de repository:
Ik ben zo gewend aan Git dat dit Me beangstigend lijkt. Zonder de mogelijkheid om veranderingen op te voeren, kan elk oud ding dat je hebt aangeraakt in je werkdirectorym eindigen als onderdeel van de publieke repository. Heb je passief-agressief de slecht uitgevoerde functie van een collega herschreven uit reinigende noodzaak,nooit van plan dat hij het zou weten? Jammer, hij vindt je nu een lul. Je kunt ook je commits niet bewerken voordat je ze pusht, omdat een commit een push is. Vindt u het leuk om 40 minuten herhaaldelijk git rebase -i te draaien totdat uw localcommit geschiedenis stroomt zoals de afleiding van een wiskundig bewijs? Sorry, dat kun je hier niet doen, en iedereen zal erachter komen dat je niet echt eerst je testen schrijft.
maar ik begrijp nu ook waarom zoveel mensen Git onnodig ingewikkeld vinden.Als cvs commit is wat je gewend was, Dan ben ik er zeker van dat staging en pushingchanges je als een zinloos karwei zouden zien.
wanneer mensen zeggen dat Git een “gedistribueerd” systeem is, is dit in de eerste plaats het verschil dat ze bedoelen. In CVS kun je geen commits lokaal maken. Een commit is een submission van code naar de centrale repository, dus het is niet iets wat je zonder een verbinding kunt doen. Alles wat je lokaal hebt is je werk directory. In Git heb je een volwaardige lokale repository, dus je kunt de hele dag commits maken, zelfs als de verbinding verbroken is. En je kunt die commits bewerken, revert, branch, andcherry zoveel kiezen als je wilt, zonder dat iemand anders het hoeft te weten.
omdat commits een grotere deal waren, maakten CVS gebruikers ze vaak af en toe.Commits zouden zoveel veranderingen bevatten als we vandaag zouden verwachten in aten-commit pull request. Dit was vooral het geval als commits een CIbuild en een geautomatiseerde test suite activeerden.
als we nu cvs status draaien, kunnen we zien dat we een nieuwe versie van ons bestand hebben:
samenvoegen
zoals hierboven vermeld, kunt u in CVS een bestand bewerken dat al door iemand anders wordt bewerkt. Dat was CVS ‘ grote verbetering ten opzichte van RCS. Wat gebeurt er als je je wijzigingen weer bij elkaar moet brengen?
stel dat je vrienden hebt uitgenodigd om hun favoriete kleuren toe te voegen aan je lijst. Terwijl ze het toevoegen van hun kleuren, u besluit dat u niet langer als de kleur groen en verwijder het uit de lijst.
wanneer u uw wijzigingen gaat vastleggen, zou u kunnen ontdekken dat CVS notices aproblem:
Het lijkt erop dat uw vrienden hun wijzigingen eerst hebben vastgelegd. Dus uw versie vanfavorites.txt is niet up-to-date met de versie in de repository. Als uwun cvs status, zult u zien dat uw lokale kopie van favorites.txt versie1. 2 is met enkele lokale wijzigingen, maar de repository versie is 1.3:
u kunt cvs diff uitvoeren om precies te zien wat de verschillen tussen 1.2 en 1.3 zijn:
het lijkt erop dat onze vrienden pink echt leuk vinden. In ieder geval hebben ze een ander deel van het bestand bewerkt dan wij, dus de wijzigingen zijn makkelijk samen te voegen. CVScan doen dat Voor ONS als we cvs update uitvoeren, wat vergelijkbaar is met 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 Als u nu eens kijkt naar favorites.txt, U zult zien dat het is gewijzigd om de wijzigingen die uw vrienden in het bestand hebben aangebracht, op te nemen. Je veranderingen zijn er ook nog. Nu ben je vrij om het bestand te committen:
het eindresultaat is wat je in Git krijgt door git pull --rebasete draaien. Yourchanges zijn toegevoegd bovenop de wijzigingen van je vrienden. Er is geen “mergecommit.”
soms kunnen wijzigingen in hetzelfde bestand niet compatibel zijn. Als je vrienden “groen” hadden veranderd naar” olijf, “bijvoorbeeld, dat zou in strijd zijn geweest met yourchange verwijderen van” groen ” helemaal. In de vroege dagen van CV ’s was dit het soort geval dat mensen bezorgd maakte dat CV’ s niet veilig waren; RCS ‘ persimistische vergrendeling zorgde ervoor dat een dergelijk geval nooit zou kunnen ontstaan. Maar CVs garandeert de veiligheid door ervoor te zorgen dat niemands wijzigingen automatisch worden overschreven. Je moet CVS vertellen welke wijziging je door wilt laten gaan, dus als je cvs update uitvoert, markeert CVS het bestand met beide wijzigingen op dezelfde manier als Git doet wanneer Git een merge conflict detecteert. Vervolgens moet u het bestand handmatig bewerken en de wijziging kiezen die u wilt behouden.
Het interessante om hier op te merken is dat merge conflicten moeten worden opgelost voordat je kunt committen. Dit is een ander gevolg van CVS ‘ gecentraliseerde nature.In Git, je hoeft je geen zorgen te maken over het oplossen van merges totdat je de commits pusht die je lokaal hebt.
Tags en Branches
aangezien CVS geen gemakkelijk adresseerbare commit objecten heeft, is de enige manier om wijzigingen te verzamelen door een bepaalde werkmap status te markeren met atag.
Het aanmaken van een tag is eenvoudig:
$ cvs tag VERSION_1_0cvs tag: Tagging .T favorites.txt u zult later in staat zijn om bestanden naar deze status te retourneren door cvs updateuit te voeren en de tag te koppelen aan de-r:
$ cvs update -r VERSION_1_0cvs update: Updating .U favorites.txt omdat u een tag nodig hebt om terug te spoelen naar een eerdere werkmap, moedigt Cvsen veel preventief taggen aan. Voor belangrijke refactors, bijvoorbeeld, kunt u een BEFORE_REFACTOR_01 tag aanmaken die u later zou kunnen gebruiken als de factor fout ging. Mensen gebruikten ook tags als ze projectbrede diffs wilden genereren. Kortom, alle dingen die we vandaag routinematig doen met commithashes moeten worden voorzien en gepland met CVS, omdat je de tags al beschikbaar moest hebben.
Branches kunnen worden aangemaakt in CVS, een soort van. Branches zijn gewoon een speciaal soort tag:
$ cvs rtag -b TRY_EXPERIMENTAL_THING colorscvs rtag: Tagging colorsdie alleen de branch aanmaakt (in volledige weergave van iedereen trouwens), dus je moet er nog steeds naar overschakelen met cvs update:
$ cvs update -r TRY_EXPERIMENTAL_THINGde bovenstaande commando ‘ s schakelen over naar de nieuwe branch in uw huidige WorkingDirectory, maar pragmatisch versiebeheer met cvs adviseert eigenlijk dat u een nieuwe directory maakt om uw nieuwe branch te behouden. Vermoedelijk vonden de auteurs het wisselen van directory ‘ s makkelijker dan het wisselen van branches in CVS.
pragmatische versiebeheer met behulp van CVS adviseert ook tegen het creëren van branchesoff van een bestaande branch. Ze raden alleen branches aan van de mainline branch, die in Git bekend staat als master. In het algemeen werd vertakking beschouwd als een “geavanceerde” CVS-vaardigheid. In Git zou je om bijna elke triviale reden een nieuwe branch kunnen starten, maar in CVS werd branching meestal alleen gebruikt als het echt nodig was, zoals voor releases.
een branch kan later worden samengevoegd in de hoofdregel met cvs update en -j vlag:
$ cvs update -j TRY_EXPERIMENTAL_THINGBedankt voor de commit geschiedenissen
in 2007 gaf Linus Torvalds atalk over Git op Google. Git was toen erg nieuw, dus de talk was eigenlijk een poging om een zaal vol skeptical programmeurs ervan te overtuigen dat ze Git zouden moeten gebruiken, ook al was Git zo verschillend van alles wat toen beschikbaar was. Als je het gesprek nog niet hebt gezien, moedig ik je aan om het te bekijken. Linus is een vermakelijke spreker, zelfs als henever faalt om zijn brutale zelf te zijn. Hij legt uitstekend uit waarom het gedistribueerde model van versiebeheer beter is dan het gecentraliseerde. Veel van zijn kritiek is vooral voorbehouden aan CV ‘ s.
Git is een complex gereedschap. Leren kan een indrukwekkende ervaring zijn. Maar ik ben ook voortdurend verbaasd over de dingen die Gitkan doen. Ter vergelijking, CVS is eenvoudig en rechttoe rechtaan, maar vaak niet in staat om veel van de operaties die we nu als vanzelfsprekend beschouwen uit te voeren. Terug te gaan en CVS te gebruiken voor een tijdje is een uitstekende manier om jezelf te vinden met een nieuwe waardering voor de kracht en flexibiliteit van het. Het illustreert goed waarom het begrijpen van de geschiedenis van software-ontwikkeling kan zo nuttig zijn-oppakken en opnieuw onderzoeken van obsolete tools zal je leren volumes over het waarom achter de tools die we vandaag gebruiken.
als je dit bericht leuk vond, komt er elke vier weken meer uit! Volg @TwoBitHistory op Twitter of abonneer je op de RSS-feed om ervoor te zorgen dat je weet wanneer een nieuw bericht is uit.
correctie
Er is mij verteld dat er veel organisaties zijn, in het bijzonder risk-adverseorganisaties die dingen doen zoals software maken voor medische hulpmiddelen, die nog steeds gebruik maken vanecv ‘ s. Programmeurs in deze organisaties hebben kleine trucs ontwikkeld om de beperkingen van CVS te omzeilen, zoals het maken van een nieuwe branch voor bijna elke verandering om te voorkomen dat ze direct committen naar HEAD. (Met dank aan Michael Kohne forounting dit uit.)