0b10

Github indult 2008. Ha a szoftvermérnöki karriered, mint az enyém, nem régebbi, mint a Github, akkor a Git lehet az egyetlen verzióvezérlő szoftver, amelyet valaha is használtál. Míg az emberek néha feldühítik a meredek tanulási görbét vagyunintuitív felületet, a Git mindenki számára elérhetővé vált a verzióvezérléshez. Az InStack Overflow 2015-ös fejlesztői felmérése szerint a válaszadók 69,3%-a használta a Git-et, majdnem annyi,mint a második legnépszerűbb verzióvezérlő rendszert, a Subversion-t.1 2015 után a Stack túlcsordulás abbahagyta a fejlesztők kérését az általuk használt verzióvezérlő rendszerekről, talán azért, mert a Git annyira népszerűvé válthogy a kérdés érdektelen volt.

maga a Git nem sokkal idősebb, mint a Github. Linus Torvalds kiadta az elsőa Git verziója 2005-ben. Bár manapság a fiatalabb fejlesztőknek nehéz idejük lehetegy olyan világ megteremtése, ahol a “verzióvezérlő szoftver” kifejezés nem többé vagykevesebb, csak Git-et jelent, egy ilyen világ nem olyan régen létezett. Volt sokalternatívák közül lehet választani. A nyílt forráskódú fejlesztők preferált Subversion,vállalkozások videojáték-fejlesztő cégek használt Perforce (néha még most is), míg theLinux kernel projekt híresen támaszkodott egy verziókezelő rendszer calledBitKeeper.

ezeknek a rendszereknek egy része, különösen a BitKeeper, ismerősnek érezheti magát egy fiatal felhasználó számára, akit az időben szállítottak. A legtöbb nem. BitKeeper félre, a verziókontroll rendszerek, amelyek a Git előtt jöttek, alapvetően eltérő paradigma szerint működtek. Eric Sink, a VersionControl szerzője által kínált taxonómiában a Git egy harmadik generációs verzióvezérlő rendszer, míg a Git elődeinek többsége,az 1990-es években és a 2000-es évek elején népszerű rendszerek második generációs verzióvezérlő rendszerek.2, ahol a harmadik generációversion vezérlőrendszerek vannak elosztva, második generációs verzió controlsystems központosított. Már szinte biztosan hallott Git le, mint egy “elosztott” verzió vezérlő rendszer előtt. Soha nem értettem teljesen aelosztott / központosított megkülönböztetést, legalábbis addig, amíg nem telepítettem ésszemélyesítve egy központi második generációs verzióvezérlő rendszerrel.

az általam telepített rendszer CVS volt. A CVS, a párhuzamos verziók rendszerének rövidítése voltaz első második generációs verzióvezérlő rendszer. Ez volt a leginkábbnépszerű verzióvezérlő rendszer körülbelül egy évtizede, amíg 2000-ben fel nem cserélték. Még akkor is a Felforgatásnak “CVS-nek, de jobbnak” kellett lennie, ami csak aláhúzza, hogy az 1990-es években milyen domináns CVS lett.

A CVS – t először 1986-ban fejlesztette ki Dick Grune nevű holland számítástechnikai tudós,aki egy compilerproject-en kereste a módját, hogy együttműködjön diákjaival.3 CVS kezdetben alig több, mint egy gyűjtemény shell scriptswrapping RCS (Revision Control System), Egy első generációs verzió controlsystem hogy Grune javítani akart. Az RCS pesszimista modell szerint működik, ami azt jelenti, hogy egyetlen programozó sem tud egyetlen fájlon dolgozni. A fájl szerkesztéséhez először meg kell kérdeznie az RCS-t egy exkluzív zárróla fájlon, amelyet addig tart, amíg befejezi a szerkesztést. Ha valaki másmár szerkeszti a szerkeszteni kívánt fájlt, várnia kell. CVs javult RCSand bevezette a második generációs verzió ellenőrzési rendszerek kereskedelmi thepessimistic zár modell egy optimista. A programozók most egyszerre szerkeszthetik ezeket a fájlokat, összevonva a szerkesztéseiket és megoldva a konfliktusokat. (Brian Berliner, egy mérnök, aki később átvette a CVS projektet, írtaegy nagyon olvasható papír a CVS innovációiról 1990-ben.)

ebben az értelemben a CVS nem volt annyira különbözik a Git-től, amely szintén optimista modell szerint működik. De ez az, ahol a hasonlóságok véget érnek. Valójában, amikor Linus Torvalds kifejlesztette a Git-t, az egyik vezérelve waswcvsnd volt, vagy “mi lenne a CVS nem.”Amikor kétségei voltak a döntéssel kapcsolatban, arra törekedett, hogy kiválassza azt a lehetőséget, amelyet nem választottak ki a CVS tervezésében.4 Tehát annak ellenére, hogy a CVS több mint egy évtizeddel megelőzi a Git-t, befolyásolta a Git ASA típusú negatív sablont.

nagyon élveztem a CVS-vel való játékot. Azt hiszem, nincs jobb módja annak, hogy megértsük, miért Git elosztott jellege olyan javulás, amit camebeore. Ezért Felkérem Önöket, hogy jöjjenek velem egy izgalmas utazásra, és töltsék el az életed következő tíz percét, hogy megismerjék az elmúlt évtizedben használt softwarenobody darabot. (Lásd a helyesbítést.)

A CVS

telepítésére vonatkozó utasítások megtalálhatók a projekt ‘ shomepage. A MacOS rendszeren telepítheti a CVS-t használvahomebrew.

mivel a CVS központosított, megkülönbözteti az ügyféloldali univerzumot és a szerveroldali univerzumot oly módon, hogy valami hasonló Git nem. Thedistinction nem annyira hangsúlyos,hogy vannak különböző végrehajtható. De ahhoz, hogy elkezdje használni a CVS-t, még a saját gépén is, be kell állítania a theCVS backend-et.

a CVS backend, az összes kód központi tárolója, az adattár.Míg a Git – ben általában minden projekthez van adattár, a CV-benaz adattár tartalmazza az összes projektet. Van egy központi adattármindent, bár vannak módok arra, hogy egyszerre csak egy projekttel dolgozzanak.

helyi adattár létrehozásához futtassa a init parancsot. Te is ezt tennédahol globális, mint az otthoni könyvtár.

$ cvs -d ~/sandbox init

CVS lehetővé teszi acvsparancs vagy ainit subcommand. A cvs parancs után megjelenő opciók a global innature, míg az alparancsok után megjelenő opciók a thesubcommandra jellemzőek. Ebben az esetben a -d zászló globális. Itt előfordul, hogy elmondja a CV-Kethol szeretnénk létrehozni a tárolónkat, de általában a -d zászló pontokaz adattár helyét, amelyet bármely adott művelethez használni akarunk. A -d zászló minden alkalommal megadható, így helyette aCVSROOT környezetváltoztatható.

mivel helyben dolgozunk, most haladtunk el egy utat a -d argumentumunkhoz,de tartalmazhattunk volna egy hostnevet is.

a parancs létrehoz egy sandbox nevű könyvtárat a saját könyvtárában. Ha a sandbox tartalmát sorolja fel, akkor kiderül, hogy egy másik CVSROOTrendezőt is tartalmaz. Ez a könyvtár, amelyet nem szabad összetéveszteni a környezetrelváltoztatható, adminisztratív fájlokat tart a tárolóhoz.

gratulálok! Most hozta létre az első CVS tárolót.

A

kód ellenőrzése tegyük fel, hogy úgy döntött, hogy megtartja kedvenc színeinek listáját. Ön művészileg hajlamos, de rendkívül feledékeny ember. Írja be a színlistáját, majd mentse el favorites.txt:

blueorangegreendefinitely not yellow

feltételezzük azt is, hogy a fájlt egy új könyvtárba mentette, acolors. Most szeretné a kedvenc színlistáját a verzióvezérlés alá helyezni, mert ötven év múlva érdekes lesz visszanézni, hogyanaz ízlésed idővel megváltozott.

ehhez új cvsprojectként kell importálnia a könyvtárat. Ezt a import paranccsal teheti meg:

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

itt adjuk meg a tároló helyét a-d flagagain. A többi argumentum a import subcommand alá kerül. Üzenetet kell adnunk, de itt nincs igazán szükségünk rá, ezért elhagytuk. A következő argumentum, colors, meghatározza az új könyvtár nevétaz adattár; itt csak ugyanazt a nevet használtuk, mint a könyvtár, amelyben vagyunk.Az utolsó két argumentum adja meg a szállító címkét, illetve a kiadási címkét.Egy perc múlva beszélünk a címkékről.

éppen most húzta be a “színek” projektet a CVS tárolóba. Vannak acouple különböző módon megy körülbelül hozza kódot CVS, de ez themethod által ajánlott pragmatikus változat vezérlő UsingCVS, a PragmaticProgrammer könyvet CVS. Mi teszi ezt a módszert egy kicsit kínos, hogy youthen van, hogy nézd meg a munka friss, annak ellenére, hogy már van anexisting colors könyvtár. Ahelyett, hogy ezt a könyvtárat használná, meg fogod tennitörölje, majd nézze meg azt a verziót, amelyről a CVS már tud:

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

Ez létrehoz egy új könyvtárat, más névencolors. Ebben a könyvtárban megtalálod az eredeti favorites.txtfájlt aCVS nevű könyvtárral együtt. ACVS könyvtár lényegében a.git directoryin every Git repository.

változtatások végrehajtása

készüljön fel az utazásra.

csakúgy, mint a Git, a CVS-nek van egy status subcommand:

Ez az, ahol a dolgok idegennek tűnnek. A CVS-nek nincs commit objektuma. A fenti, van valami úgynevezett “Commit Identifier”, de ez lehetcsak egy viszonylag friss kiadás-nem említi a “Commit Identifier” jelenik inPragmatic Version Control segítségével CVS, amely megjelent 2003-ban. (A lastupdate to CVS 2008.5-ben jelent meg)

míg a Git-nél a commit45de392 – hez társított fájl verziójáról beszélne, a CVS fájlok külön-külön kerülnek verzióra. A fájl első verziója az 1.1 verzió, a következő verzió az 1.2, stb. Amikor az ágak be vannak vonva, extra számokat csatolnak, így a végén valami hasonlóa 1.1.1.1 felett, ami úgy tűnik, hogy az alapértelmezett a mi esetünkben, annak ellenére, hogy wehaven nem hozott létre ágakat.

hacvs log (egyenértékű agit log) egy lotsof fájlokkal és committel rendelkező projektben, minden fájlhoz egyedi előzményeket látna. Az 1.2-es verziójú fájl és az 1.14-es verziójú fájl ugyanabban a projektben.

változtassuk meg a favorites.txt fájl 1.1-es verzióját:

 blue orange green+cyan definitely not yellow

miután elvégeztük a változtatást, futtathatjuk acvs diff hogy lássuk, mit gondol a CVS:

CVS felismeri, hogy hozzáadtunk egy új sort, amely a” cián ” színt tartalmazza a fájlhoz. (Valójában azt mondja, hogy módosítottuk az” RCS ” fájlt; láthatjuk, hogy a CVS soha nem kerülte el teljesen az RCS-vel való eredeti kapcsolatát.) A bemutatott diff a favorites.txt másolata és a tárolóban tárolt 1.1.1.1 verzió közötti különbség.

a tárolóban tárolt verzió frissítéséhez el kell vállalniukváltoztatni. A Git-ben ez többlépcsős folyamat lenne. Meg kell állítanunk a változtatást, hogy megjelenjen az indexünkben. Akkor vállalnánk a változást. Végül, ahhoz, hogy a változás bárki más számára láthatóvá váljon, a commit-ot az origin repository-ra kell tolnunk.

A CVS-ben ezek a dolgok akkor történnek, amikor cvs commitfut. CVS justbundles fel az összes változás megtalálható, és hozza őket a repository:

én annyira hozzászokott Git, hogy ez a sztrájk nekem, mint félelmetes. Ha nincs lehetőség a színpadi változásokra, minden régi dolog, amit megérintett a munkaközvetítőben, a nyilvános adattár részeként végződik. Te passzív-agresszívenírtad egy munkatárs rosszul megvalósított funkcióját katartikus szükségszerűségből, soha nem akarta, hogy megtudja? Kár, hogy most azt hiszi, hogy egy pöcs vagy. Azt isnem szerkesztheti a kötelezi, mielőtt nyomja őket, mivel egy elkövetni egy push. Szeretné, ha a git rebase -i futtatásával 40 percet töltene, amíg a localcommit története úgy folyik, mint egy matematikai bizonyíték levezetése? Sajnálom, de ezt itt nem teheti meg, és mindenki rá fog jönni, hogy előbb nem írja le a tesztjeit.

de most már értem, miért olyan sok ember találja Git szükségtelenül bonyolult.Ha a cvs commit az, amihez hozzászoktál, akkor biztos vagyok benne, hogy a staging and pushingchanges értelmetlen feladatnak tűnik.

amikor az emberek arról beszélnek, hogy a Git “elosztott” rendszer, ez elsősorban a különbség, amit jelentenek. A CVS-ben nem lehet elkötelezni magát helyben. A commit az asubmission kód a központi adattár, így ez nem olyasmi, amit dowithout kapcsolat. Minden, ami helyben van, a munkakönyvtár. A Git, van egy teljes körű helyi adattár, így lehet, hogy kötelezi egész napmég közben megszakad. És szerkesztheted azokat a követéseket, visszavonulásokat, ágakat, és választhatsz, amennyit csak akarsz, anélkül, hogy bárki másnak is tudnia kellene.

mivel a kötelezettségvállalások nagyobb üzletet jelentettek, a CVS-felhasználók gyakran ritkán tették őket.A kötelezettségvállalások annyi változást tartalmaznának, mint ma, amit az aten-commit húzási kérelemben várhatunk. Ez különösen akkor volt igaz, ha a committee cibuild-et és egy automatizált tesztcsomagot indított el.

Ha most futunkcvs status, láthatjuk, hogy van egy új verziója a fájlunknak:

összevonása

mint fentebb említettük, a CVS-ben szerkeszthet egy fájlt, amelyet valaki más már megtéveszt. Ez volt a CVS nagy fejlesztése az RCS-n. Mi történik, ha szükség van ráa változásokat újra össze kell hozni?

tegyük fel, hogy meghívott néhány barátot, hogy adja hozzá kedvenc színeit toyour lista. Miközben hozzáadják a színeiket, úgy dönt, hogy már nemmint a zöld szín, majd távolítsa el a listából.

amikor elkezdi végrehajtani a változtatásokat, előfordulhat, hogy a CVS észreveszi aproblem:

úgy tűnik, hogy barátai először követték el a változásokat. Tehát afavorites.txt verziója nem naprakész a tároló verziójával. Ha yourun cvs status, látni fogja, hogy a helyi példányát favorites.txt van version1. 2 néhány helyi változások, de a tároló verzió 1.3:

acvs diff futtatható, hogy pontosan megnézze, mi a különbség az 1.2 és 1.3 között:

úgy tűnik, hogy barátaink nagyon szeretik a rózsaszínt. Mindenesetre már szerkesztett adifferent része a fájlnak, mint mi, így a változások könnyen egyesíthető. CVScan, hogy mikor futunk cvs update, ami hasonló a 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

Ha most vessen egy pillantást favorites.txt, rájössz, hogy ez beenmodified, hogy tartalmazza a változás, hogy a barátaid, hogy a fájlt. A te változásaid is ott vannak. Most már szabadon elkövetheti a fájlt:

a végeredmény az, amit a GIT-ben kapna a git pull --rebasefuttatásával. Yourchanges kerültek a tetején a barátok ‘ változások. Nincs ” mergecommit.”

néha előfordulhat, hogy ugyanazon fájl módosítása nem kompatibilis. Ha a barátaid “zöld” – et “olíva” – ra változtattak volna, például, ez ellentmondott volna a te változásodnak, amely teljesen eltávolítja a “zöld” – et. A CVS korai napjaiban pontosan ez voltaz a fajta eset, amely miatt az emberek aggódtak, hogy a CVS nem volt biztonságos; Az RCS ‘ pessimistic reteszelése biztosította, hogy ilyen eset soha ne merüljön fel. De CVSguarantees biztonsági ügyelve arra, hogy senki sem változik felülírjaautomatikusan. Meg kell mondania a CVS-nek, hogy melyik változtatást szeretné folytatni, így amikor cvs update fut, a CVS mindkét változással megjelöli a fájlt ugyanúgy, mint a Git, amikor a Git egy egyesítési konfliktust észlel. Ezután manuálisan kell szerkesztenie a fájlt, majd válassza ki a megtartani kívánt módosítást.

az érdekes dolog, amit itt meg kell jegyezni, hogy az egyesítési konfliktusokat rögzíteni kellmielőtt elkövethet. Ez egy másik következménye a CVS központosított nature.In Git, addig nem kell aggódnia a fúziók megoldása miatt, amíg nem nyomja meg a helyben kapott ajánlásokat.

Tags and Branches

mivel a CVS nem rendelkezik könnyen címezhető commit objektumokkal, a módosítások gyűjtésének egyetlen módja egy adott munkakönyvtárállapot megjelölése az atag segítségével.

a címke létrehozása egyszerű:

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

később a cvs update

> > zászló:

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

mert szüksége van egy címkére, hogy visszatekerje egy korábbi működő könyvtárállapotba, a Cvsencourases sok megelőző címkézést. Például a nagyobb refaktorok előtt létrehozhat egy BEFORE_REFACTOR_01 címkét, amelyet később használhat, ha thefactor rosszul ment. Az emberek címkéket is használtak, ha generálni akarnakprojekt széles diffs. Alapvetően minden olyan dolgot, amit ma rutinszerűen a komcsikkal csinálunk, előre kell tervezni a CVS-vel, mivel már meg kellett adnod a címkéket.

ágak lehet létrehozni CVS, fajta. Ágak csak egy különleges oftag:

$ cvs rtag -b TRY_EXPERIMENTAL_THING colorscvs rtag: Tagging colors

Ez csak akkor hoz létre a fióktelep (mindenki szeme láttára, az úton), szóval még kell váltani, hogy a cvs update:

$ cvs update -r TRY_EXPERIMENTAL_THING

A fenti parancsok kapcsolja rá a új ág a jelenlegi workingdirectory, de Pragmatikus Verzió Vezérlés CVS valójában azt tanácsolja, hogy youcreate egy új könyvtárat az új ág. Feltehetően a szerzők találtáka könyvtárak összekapcsolása könnyebb, mint a CVS-ek ágainak váltása.

pragmatikus Verzióvezérlés a CVS használatával azt is tanácsolja, hogy ne hozzon létre egy meglévő ág elágazását. Azt javasolják, hogy csak ágakat hozzanak létre a themainline ágról, amely a Git-ben masternéven ismert. Általában az elágazás voltegy “fejlett” CVS készség. A Git-ben lehet, hogy új ágat indítaszszinte bármilyen triviális ok, de a CVS-ben az elágazást általában csak akkor használták, amikor szükség van rá, például a kiadásokhoz.

egy ág később újra egyesíthető a fővonalba a cvs update és -j zászló:

$ cvs update -j TRY_EXPERIMENTAL_THING

Köszönjük a Commit Histories

2007-ben, Linus Torvalds adta atalk körülbelül Git a Google. A Git akkor még nagyon új volt, így a beszélgetés alapvetően egy olyan kísérlet volt, hogy meggyőzze a szobatársakat arról, hogy használják a Git-et, annak ellenére, hogy a Git nem volt más, mint bármi, ami akkor elérhető volt. Ha még nem látta a beszélgetést, akkor ösztönözze, hogy nézze meg. Linus egy szórakoztató hangszóró, még akkor is, ha henever nem az ő pimasz énje. Kiváló munkát végez, hogy elmagyarázza, miértaz elosztott verzióvezérlő modell jobb, mint a központosított. Sok kritikája van fenntartva CVS különösen.

a Git egy összetett eszköz. Tanulás lehet afrustrating tapasztalat. De én is folyamatosan lenyűgözött a dolgokat, hogy Gitcan csinálni. Összehasonlításképpen, a CVS egyszerű és egyszerű, bár gyakran nem képes elvégezni sok olyan műveletet, amelyet most magától értetődőnek tekintünk. A CVS egy ideig történő használata kiváló módja annak, hogy új elismeréssel találja magát. Ez jól szemlélteti, miért megértése volt a családban szoftver-fejlesztés olyan előnyös—veszi fel, majd újra examiningobsolete eszközök mindenre megtanít majd a miért az eszközök mögött mi usetoday.

Ha élvezte ezt a bejegyzést, inkább négyhetente jön ki! Kövesse @TwoBitHistory a Twitteren, vagy iratkozzon fel az RSS feedhogy győződjön meg róla, hogy tudja, ha egy új bejegyzést ki.

Correction

azt mondták, hogy sok szervezet, különösen a kockázat-adverseorganizations, hogy a dolgok, mint a make medical device software, hogy még mindig useCVS. Ezekben a szervezetekben a programozók kis trükköket fejlesztettek kiaz önéletrajzok korlátai körül dolgozva, például szinte minden új ágat létrehozva, hogy elkerüljék a HEADközvetlen elkötelezettségét. (Köszönet Michael Kohne-nak, hogy ezt kiderítette.)