Git for subversion felhasználók rész 1
Ez a tartalom a sorozat része: Git for Subversion Users
Vigyázz az új cikkekre ebben a sorozatban.
Azok számára, akik nem ismerik a nyílt forráskódú VCS-t, meg kell mondani, hogy a Subversion valójában a nem kereskedelmi VCS standardává vált, a régi és jó CVS (Concurrent Versions System) helyett. A CVS rendszerek még mindig kiválóak a korlátozott használathoz, de a Subversionra vonzódik az a tény, hogy szinte csak kis konfigurációt igényel a webszerver. A Subversionnek van néhány problémája, amit itt tárgyalunk, de a legtöbb esetben jól működik.
Miért van szükségünk valamire? A Git rendszer (a "G" tőke, mivel a git parancssori eszköz) nagyrészt úgy tervezték, hogy jobb legyen, mint a Subversion. Ez egyike a sok elosztott VCS-nek. Személy szerint dolgoztam az Arch / tla, Mercurial, Bazaar, darcs és másokkal. Számos okból fogok beszélni arról, hogy mikor válnak fontosnak a történetünkhöz, a Git népszerűvé vált, és a személyes és a vállalati VCS között gyakran a két vezető (a Subversion mellett) egyike.
Két oka lehet, hogy Ön, mint Subversion felhasználó, érdekelheti a Git.
- A Git használatát tervezi, mivel a Subversion valamilyen módon korlátozza Önt.
- Szeretne megtudni a Git-ről, és azt szeretné összehasonlítani a Subversiontal.
Bár lehet egy harmadik ok is: a Git egy viszonylag új technológia, amelyet szeretnél kiemelni az önéletrajzában. Remélem, ez nem a fő célod; a tanulási git az egyik leghasznosabb dolog, amit a fejlesztő megtehet. Még ha nem is használja a Git-t, az elosztott VCS-ben megvalósított fogalmak és munkafolyamatok az IT iparág legtöbb szegmenséhez a következő 10 évben fontos tudássá válnak, mivel az ágazat jelentős határokon és földrajzi szerkezetben változik.
Végül, bár ez nem lehet jó oka, ha nem fejleszted a Linux rendszermagot, a Git a rendszermag és számos más fontos projekt támogatására szolgál. Ezért, ha bármelyik nyitott projekthez szeretne hozzájárulni, akkor ismernie kell ezt a rendszert.
A sorozat második részében megismerkedünk a Git: branch összefonódás, a differenciálfájlok és más tipikus feladatok generálásának trükkös módszereivel.
A Subversion és a Git alapjai
Ezután a "Subversion" helyett az "SVN" rövidítést használom, hogy kevésbé használjam ki a billentyűzeten lévő U, B, E, R, S, I és O gombokat.
Talán hallottál a git-svn eszközről, amely lehetővé teszi a Git használatát, amikor a Subversion adattárral dolgozik. Bizonyos esetekben hasznos lehet, de egy elosztott rendszerből származó kliens használatával, amikor egy központosított VCS-vel dolgozik, nem áttérés egy elosztott VCS-re.
Szóval, mi jó az SVN-ről? Talán már tudja, hogy a VCS-ben a legfontosabb dolog nem fájl, de változik. A központi kiszolgálón futó SVN módosítja az adattárat, és minden változás után megadhatja az adatok másolatát. Ez a példány verziószáma; A verziószám nagyon fontos az SVN-hez és az ezzel együtt dolgozó embereknek. Ha a változásod után következik, a verziószámod nagyobb, mint az enyém.
A Git hasonló célt követ - nyomon követi a változásokat - de nincs központi szervere. Ez nagyon fontos különbség. Az SVN egy központosított rendszer, és a Git egy elosztott rendszer, ezért a Git-ban nem lehet a sorrend növekvő sorrendje, mivel nincs benne "legfrissebb verzió". Azonban még mindig vannak egyedi verzióazonosítók, csak önmagukban nem olyan hasznosak, mint az SVN verziószámai (változatok).
Az SVN könyvtárának használata
Listázás 1. A könyvtár konfigurálása az SVN-ben való működéshez
Mit ad ez nekünk? Most megkaphatjuk a könyvtárban lévő fájlok legújabb verzióit a fájlokból, törölhetjük a fájlokat, átnevezhetjük őket, létrehozhatunk új fájlokat és könyvtárakat, módosíthatunk meglévő fájlokat stb.
Listázás 2. Egyszerű fájlműveletek az SVN-ben
Nem fogjuk részletesen tanulmányozni ezeket a parancsokat, de egyszerűen emlékezni fogunk rájuk. A parancsok bármelyikének alapvető súgóinformációinak megtekintéséhez írja be az svn help COMMAND parancsot. és részletes információkat a használati útmutatóban talál.
A Git könyvtárának használata
Ugyanúgy fogok eljárni, mint a példában az SVN-vel. Mint korábban, feltételezem, hogy rendelkezel egy könyvtárral az adatokkal.
Távoli kiszolgálóként a github.com ingyenes szolgáltatást használtam, de természetesen bármilyen más szervert is használhatsz. A GitHub egy egyszerű módja annak, hogy egy távoli Git adattárral próbálkozzon. Az írás idején a szabad számlához tartozó adatok mennyisége 300 MB, ezenkívül az adattárnak nyilvánosnak kell lennie. Létrehoztam egy "tzz" nevű fiókot, és létrehoztam egy nyilvános adattárat "datatest"; használhatja. Adtam a nyilvános SSH kulcsomat. Ha még nem rendelkezik saját kulcsával, akkor generálnia kell. Kipróbálhatja a Gitorious vagy a repo.or.cz szervereket is. A git.or.cz webhely wiki részében nagyszámú webhely található, amely tárhely szolgáltatásokat biztosít a Git adattárak számára (lásd a kapcsolódó témakörökben található hivatkozást).
A GitHub jó, mert barátságos a felhasználók számára. Megadja, hogy mely parancsokat használja a Git konfigurálásához és készítse el a tároló használatát. Ezeket a lépéseket együtt fogjuk végrehajtani.
Listázás 3. Basic Git konfiguráció
Ezután állítom be az adatfájlokat, és inicializálom azokat az adattárral. (A GitHub is importálhatja őket az SVN adattárból, ami hasznos lehet.)
Lista 4. A könyvtár konfigurálása és az első elkövetés
A Git megjeleníti a fájlokhoz való hozzáférési módokkal kapcsolatos információkat; A 100644 oktális ábrázolása az engedélyezési bitekhez ezekhez a fájlokhoz. Nem figyelhet rájuk, de a 2371-es beillesztés üzenetének titokzatosnak tűnhet. Csak 2 fájlt cseréltünk, igaz? Valójában ez a szám jelöli a behelyezett sorok számát. És természetesen nem töröltünk egyetlen sort sem.
Listázás 5. Módosítások közzététele egy távoli tárhelyen
Itt az OpenSSH figyelmeztetést ad, mivel korábban a github.com gép ismeretlen volt számára. Ne figyelj rá.
A Git által adott üzenetek rendkívül részletesek. Ellentétben a tüdővel az SVN üzenetek megértéséhez, a Git üzenetek iniciátorok által íródnak, és kezdeményezésre vannak szánva. Ha a Herbert Frank Dune-ből származik, és biokomputerként képzett, talán meg fogod érteni őket, pedig talán már írtál a Git saját verzióját. Nos, a delta tömörítésről és a szálak számáról szóló jelentések többi része egyszerűen nem túl fontos (és fejfájást okozhat).
A változások átvitele SSH-n keresztül történt, de más protokollokat is használhat, például HTTP, HTTPS, rsync és fájl. További információ a súgóban: git push --help.
A legfontosabb különbség az SVN és a Git között. Az SVN-ben a commit művelet jelzi: "meg kell másolnia a központi kiszolgálóra". Az SVN-ben változásai immateriálisak maradnak, amíg el nem kötelezi őket. A Git-ben a változtatások végrehajtása helyi. van egy helyi adattár, amely nem érdekli, hogy mi történik a távoli oldalon. A változást, az ágat, a fiókváltozást stb. a távoli kiszolgálóval való interakció nélkül. A (Git) változások (push) közzététele lényegében a tároló állapotának szinkronizálása egy távoli szerverrel.
Végül nézzük meg, hogy a Git-naplóban mi is látható:
Listázás 6. Git log
A naplóban csak a változtatások rögzítésének nyilvántartása (megjegyezzük, hogy itt, ellentétben az SVN revíziószámával, a véletlen azonosítója a commit műveletnek). Nincs említés a git push parancs által végrehajtott szinkronizálásról.
A Git-tel való munkavégzés
Eddig a Git-t használtuk az SVN helyettesítésére. Természetesen, hogy mindent érdekesebbé tegyünk, több felhasználóra és számos változtatásra van szükség. Lássunk együtt egy másik gépen lévő tárolóinkkal (egy olyan gépet fogok használni, amelyen az Ubuntu GNU / Linux telepítése nem git, hanem git-core):
Listázás 7. Konfiguráljon még egy Git példányt, és töltsön be benne a repository tartalmát
Az OpenSSH ismét figyelmezteti, hogy ez a gép nem működött az SSH-n keresztül a GitHub segítségével. A git clone parancs hasonló az SVN checkout parancshoz, de ahelyett, hogy megkapná a tartalom egy bizonyos változatát, teljes egészében megkapjuk a teljes tárhelyet.
Bevezettem a datatest / .git könyvtár tartalmát és annak horgok alkönyvtárát, hogy megmutassam, hogy valóban mindent megkapunk. Alapértelmezés szerint a Git nem rejt titkokat, ellentétben az SVN-lel, amely alapértelmezés szerint tárolja az adattárat titokban, és csak a tartalom másolatait teszi lehetővé.
Egyébként, ha a Git-repository-ra szeretnél beállítani minden olyan szabályt, amely végrehajtásra kerül például a változások minden egyes elkötelezettségénél, akkor ezt a hooks könyvtárban lévő szkriptek használatával lehet elvégezni. Ezek a szokásos shell parancsfájlok, sok szempontból hasonlóak az SVN "csapdáihoz", amelyek a UNIX szabványok szerint a sikertelenül és minden más hiba esetén nulla értéket adnak vissza. Nem fogok részletekbe menni a "csapda" forgatókönyvekről, de ha Git-et akarsz használni a csapatmunka során, feltétlenül részletesen meg kell tanulnod őket.
Tehát a "The Other Ted" felhasználó új fájlt szeretne hozzáadni a fő ághoz (ami nagyjából az SVN-ben található TRUNK ághoz kapcsolódhat), és létrehozhat egy új ágat is, a gdbinit fájl néhány módosításával.
Listázás 8. Fájl hozzáadása és új fiók létrehozása
Hosszú példa volt, és remélem, hogy nem elaludtál olvasás közben. Ha elaludtál, remélem, hogy álmodsz a Git tárolóiról, hogy szinkronizáld a végtelen hullámot a változásokkal (ó, ne aggódj, akkor álmodsz róla).
Először hozzáadtam és rögzítettem a fájlt (encode.pl, mindegyik sorból). A rögzítés után a távoli tároló nem tudott semmit arról, amit tettem. Ezután létrehoztam egy üres gdbinit új ágát, és átállítottam rá (ez szintén végrehajtható a git checkout -b empty-gdbinit paranccsal). Ebben az ágban hozzáadtam egy üres gdbinit fájlt, és rögzítettem ezt a változást. Végül áthelyeztem a módosításokat a távoli kiszolgálóra.
Ha átváltunk a fő fiókra, nem fogjuk látni a "üres gdbinit" bejegyzést a naplóban. Ie minden ágnak saját logja van, ami logikusnak tűnik.
Lista 9. Keresse meg a különböző ágak naplóit
Amikor elindítottuk a push parancsot, Git elmondta a GitHub kiszolgálóknak: "Hé, nézd meg, van egy új file, amit encode.pl-nek hívnak"
Listázás 10. Adja meg az összes módosítást
A gondolkodók kezelőfelülete újra megjelenik minden dicsőségében. De kideríthetjük, mi folyik itt, nem igaz? Lehet, hogy nem a nagy gondolkodók, de a józan ész azt mondja, hogy 0000000000000000000000000000000000000000 - egyfajta speciális eredeti címkéhez. Szintén a magazin, amint azt a listában 9, kiderül, hogy a 5512d0a4327416c499dcb5f72c3f4f6a257d209f címke az utolsó (és egyetlen) fixálás üres gdbinit ágak. A többség számára a többség arámnál is írható, mivel nem törődnek vele. Most a GitHub új ágat és annak változásait jeleníti meg.
Vannak parancsok git mv és git rm is. amelyekkel a fájlok áthelyezhetők és átnevezhetők.
következtetés
Ebben a cikkben beszéltem a Git alapfogalmáról, és egy egyszerű könyvtárban szerveztem meg a verzióellenőrzést, összehasonlítva ezzel a történet során a Subversiontal. Egyszerű példa, demonstráltam az ágakkal való munkát.
Másrészről a Git egy nagyon gazdag DVCS; többet megtudni a lehetőségeiről, szinte biztosan használhatja őket, hogy egyszerűsítse és javítsa a VCS-vel való együttműködés stílusát. Talán láthatunk egy-két álmot a Git-tárolókról.