Miért jobb, mint a Git Subversion?

szavazat
393

Már használja Subversion egy pár év, és használata után SourceSafe , Imádom Subversion. Kombinált TortoiseSVN , nem igazán tudok elképzelni, hogyan lehetne jobb.

Mégis van egyre több fejlesztő azt állítja, hogy a Subversion problémái és hogy mi kell a költözés az új fajta elosztott verziókövető rendszerek, mint például a Git .

Hogyan Git javít Subversion?

A kérdést 03/08/2008 23:38
a forrás felhasználó
Más nyelveken...                            


30 válasz

szavazat
54

Google Tech Talk: Linus Torvalds a git

http://www.youtube.com/watch?v=4XpnKHJAok8

A Git Wiki összehasonlító oldalt

http://git.or.cz/gitwiki/GitSvnComparsion

Válaszolt 03/08/2008 23:44
a forrás felhasználó

szavazat
548

Git nem jobb, mint a Subversion. De szintén nem rosszabb. Ez más.

A legfontosabb különbség az, hogy decentralizált. Képzelje el, hogy egy fejlesztő az úton, akkor alakulnak ki a laptop, és azt akarjuk, hogy forrás kontroll, így megy vissza 3 óra.

A Subversion, van egy probléma: a SVN lehet olyan helyre nem tudja elérni (a cég, és nincs internet abban a pillanatban), akkor nem lehet elkövetni. Ha azt szeretnénk, hogy egy másolatot a kódot, akkor a szó szoros értelmében a másolás / beillesztés azt.

Git, akkor nem ez a probléma. Helyi példányát egy tároló, és akkor lehet elkövetni, hogy ez, és kap minden előnyét forrás ellenőrzés. Ha visszanyeri az összeköttetést a main tárolóból, akkor lehet elkövetni ellene.

Ez jól néz ki az első, de csak szem előtt tartani a komplexitás, hogy ezt a megközelítést.

Git úgy tűnik, hogy az „új, fényes, cool” dolog. Ez egyáltalán nem azt jelenti, rossz (okkal Linus írta a Linux kernel fejlesztése után), de úgy érzem, hogy sok ember ugrik a „Elosztott Source Control” vonat csak azért, mert az új és írta Linus Torvalds, anélkül, hogy ténylegesen tudta, miért / ha ez jobb.

Subversion problémái, de így nem Git, Mercurial, CVS, TFS, vagy bármi.

Edit: Tehát ez a válasz most egy éves, és még mindig termel sok upvotes, ezért úgy gondoltam, adok még néhány magyarázatot. Az elmúlt évben, mivel ezt írom, Git szerzett sok lendület és a támogatást, különösen, mivel oldalak, mint a GitHub tényleg levette. Én mindkét Git és Subversion manapság, és szeretnék megosztani néhány személyes betekintést.

Először is, Git lehet igazán zavaró az első, amikor dolgozik decentralizált. Mi a távoli? és hogyan kell helyesen beállítani a kezdeti repository? Két kérdés, hogy jöjjön létre az elején, különösen összehasonlítva SVN egyszerű „svnadmin létre”, Git „git init” tudja tenni a paramétereket --bare és --shared amely úgy tűnik, hogy a „helyes” módja annak, hogy hozzanak létre egy központosított tárolóból. Különböző okok miatt, de ez növeli a bonyolultságot. A dokumentáció a „checkout” parancs nagyon zavaró, hogy az emberek változnak át - a „helyes” utat úgy tűnik, hogy „git clone”, míg a „git checkout” Úgy tűnik, hogy váltani ágak.

Git ragyog igazán, ha a decentralizált. Van egy szerver otthoni és egy laptop az úton, és SVN egyszerűen nem működik jól van. Az SVN, nem tudom, hogy a helyi forrás ellenőrzés, ha én nem csatlakozik az adattár (Igen, tudom SVK vagy arról, hogyan másolja a repo). Git, ez az alapértelmezett mód egyébként. Ez egy extra parancsot bár (git commit követ helyben, mivel git push-eredetű mester kitolja a mester ága a távoli nevű „származás”).

Amint fentebb már említettük: Git tovább bonyolítja. Két mód létrehozásának adattárak, pénztár vs klón elkövetni vs. tolja ... Meg kell tudni, hogy mely parancsok munkát helyben, és amely együttműködik a „szerver” (Feltételezzük, hogy a legtöbb ember még mindig, mint egy központi „mester-repository” ).

Továbbá, a szerszám még mindig nem elegendő, legalábbis a Windows. Igen, van egy Visual Studio AddIn, de én még mindig használja a git bash a msysgit.

SVN megvan az az előnye, hogy sokkal egyszerűbb megtanulni: Van az adattár, minden változás felé, ha tudja, hogyan kell létrehozni, valamint elkövetésének pénztár és készen áll, hogy menjen, és felszedő ilyesmi elágazás, frissítse stb később tovább.

Git megvan az az előnye, hogy sokkal jobban megfelel, ha egyes fejlesztők nem mindig csatlakozik a mester tárolóból. Továbbá, ez sokkal gyorsabb, mint az SVN. És abból, amit hallottam, elágazás és összefonódó támogatás sokkal jobb (ami várható volt, mivel ezek az alapvető oka volt írva).

Ez azt is megmagyarázza, hogy miért kap annyi buzz az interneten, mint a Git tökéletesen alkalmas nyílt forráskódú projektek: Csak Fork meg, kötelezzék el a módosításokat saját Fork, majd kérje az eredeti projekt fenntartó húzni a módosításokat. Git, ez csak működik. Tényleg, próbálja ki a GitHub, ez varázslat.

Mit is látok olyan Git-SVN Bridges: A központi adattár egy Subversion repo, de a fejlesztők helyben dolgozni Git és a hídon, majd tolja a változtatásokat SVN.

De még ezzel a hosszadalmas kívül, még mindig áll az én fő üzenete: Git nem jobb vagy rosszabb, csak más. Ha szükség van a „Offline Source Control” és a hajlandóság tölteni egy kis időt a tanulás, ez fantasztikus. De ha van egy szigorúan központosított Source Control és / vagy küzd bevezetni Source Control az első helyen, mert a munkatársak nem érdekli, akkor az egyszerűség és a kiváló szerszám (legalább Windows) SVN fényét.

Válaszolt 03/08/2008 23:45
a forrás felhasználó

szavazat
26

Nos, ez oszlik. Felmérés jelzi, hogy ez lényegesen gyorsabb (mivel az osztott jellege, műveletek, mint a diff és naplók minden helyi, így természetesen ez blazingly gyorsabban ebben az esetben), és a munka mappák kisebb (ami még mindig fúj a fejemben).

Amikor dolgozunk felforgatás, vagy bármely más, a kliens / szerver rendszer felülvizsgálata, akkor lényegében munkakulcsokat másolatokat a gép ellenőrzi-out változathoz. Ez egy pillanatkép az időben, amit a tároló néz ki. Frissíti a munkapéldányod keresztül frissítéseket, és frissítheti a forrás keresztül véglegesítésekhez.

Az elosztott verziókezelő, akkor nem kell egy pillanatfelvétel, hanem az egész codebase. Akarok egy diff egy 3 hónapos verzió? Semmi gond, a 3 hónapos verzió még mindig a számítógépén. Ez nemcsak azt jelenti, a dolgok módon gyorsabb, de ha megszakad az Ön központi szerver, akkor is csinálni sok a műveletek van szokva. Más szóval, ha nem csak egy pillanatkép egy adott változatról, hanem az egész codebase.

Azt hihetnénk, hogy a Git venne fel egy csomó hely a merevlemez, hanem egy pár referenciaértékeket láttam, hogy valójában kevesebb. Ne kérdezd, hogyan. Úgy értem, ez építette Linus, ismer egy-két dolgot a fájlrendszert azt hiszem.

Válaszolt 03/08/2008 23:47
a forrás felhasználó

szavazat
5

Git és DVC-k általában nagy a fejlesztők a sok kódolási egymástól függetlenül, mert mindenkinek megvan a saját ága. Ha szüksége van egy változás mástól, bár ő is, hogy kötelezzék el magukat a helyi repo aztán meg kell nyomni, hogy changeset az Ön vagy meg kell húzni tőle.

Saját érvelés is elgondolkodtat DVC-k teszi a dolgokat nehezebb QA és kiadásmenedzsment ha olyan dolgokat, mint a központosított kiadások. Valakinek a felelős, hogy push / pull mindenki mástól adattárát, feloldásában konfliktusok megoldható lett volna a kezdeti elkövetni előtt, akkor ezzel az építménnyel, majd miután az összes többi fejlesztő újraszinkronizál a repo.

Mindez lehet kezelni az emberi folyamatokat, természetesen; DVC-k most tört valami, ami rögzítette központosított verzió ellenőrzése annak érdekében, hogy néhány új kényelmi.

Válaszolt 04/08/2008 00:08
a forrás felhasználó

szavazat
6

Ez mind a könnyű használat / lépéseket kell tennie valamit.

Ha én fejlődő egyetlen projekt a PC / laptop, git jobb, mert sokkal könnyebb beállítani és használni. Nem kell a szerveren, és nem kell tartani beírni adattár található URL, ha nem egyesítést.

Ha ez csak 2 fő részére, azt mondanám, hogy a git is könnyebb, mert akkor csak nyomja, és húzni egymást.

Ha túljutni, hogy bár, megyek a felforgatás, mert ezen a ponton meg kell, hogy hozzanak létre egy „dedikált” szerver vagy helyét.

Megteheti ezt ugyanolyan jól git as SVN, de az előnyeit git kap ellensúlyozza, hogy szükség van további lépésekre, hogy szinkronban egy központi szerverrel. Az SVN csak elkövetni. A git van, hogy git commit, akkor git push. A további lépést kap bosszantó egyszerűen azért, mert a végén csinál annyira.

SVN is megvan az az előnye a jobb GUI eszközök azonban a git ökoszisztéma úgy tűnik, hogy a felzárkózás gyorsan, úgyhogy ne aggódjon emiatt hosszú távon.

Válaszolt 04/08/2008 00:38
a forrás felhasználó

szavazat
145

Git, amit tehetünk gyakorlatilag mindent elérhető, mert mindenki a saját tároló.

Így ágak és összefonódó ágak között nagyon egyszerű.

Még ha nem követ el jogokat a projekt, akkor is van saját tároló az interneten, és közzéteszi a „push kérelmek” a javításokat. Mindenki, aki szereti a foltokat is húzza őket a projekt, beleértve a hivatalos fenntartói.

Ez triviális villa projekt, módosíthatja, és még mindig tartja összevonása a hibajavítás a HEAD ág.

Git működik a Linux kernel fejlesztők. Ez azt jelenti, hogy nagyon gyorsan (azt kell), és skálák ezer szerkesztők. Git is kevesebb helyet (akár 30-szer kevesebb helyet a Mozilla adattár).

Git nagyon rugalmas, nagyon TIMTOWTDI (Van több, mint egy módja annak, hogy csinálni). Használhatja bármilyen munkafolyamat akarsz, és a Git támogatni fogja azt.

Végül, van GitHub , egy nagy telek a tárhely Git-tárhelyek.

Hátrányai Git:

  • ez sokkal nehezebb megtanulni, mert Git több fogalmak és parancsokat.
  • változtatások nem rendelkezik verziószámmal mint felforgatás
  • Sok Git parancsok rejtélyes, és a hibaüzenetek nagyon felhasználóbarát barátságtalan
  • hiányzik belőle a jó GUI (mint például a nagy TortoiseSVN )
Válaszolt 04/08/2008 01:24
a forrás felhasználó

szavazat
7

Git is teszi elágazást és összevonása nagyon egyszerű. Subversion 1.5 csak hozzá egyesítés követéssel, de Git még mindig jobb. Git elágazás nagyon gyors és olcsó. Lehetővé teszi, hogy létrehoz egy ága minden új funkció még megvalósítható. Ja, és Git-tárhelyek nagyon hatékony tárhely, mint Subversion.

Válaszolt 09/08/2008 04:22
a forrás felhasználó

szavazat
6

Egyszerű Git egy szép oldal összehasonlítsák a tényleges használat Git és SVN amely megadja egy ötlet, amit a dolgok Git tehet (vagy többre könnyen) képest SVN. (Technikailag ez alapján Easy Git, ami egy könnyű borítás tetején Git.)

Válaszolt 22/08/2008 16:19
a forrás felhasználó

szavazat
8

Az egyik dolog, hogy SubVersion irks nekem, hogy hozza saját mappát minden könyvtár a projekt, mivel git csak hozza egy gyökér könyvtárába. Ez nem , hogy nagy dolog, de kevés ilyen dolgok összeadódnak.

Természetesen SubVersion van teknős, amely [általában] nagyon szép.

Válaszolt 22/08/2008 16:24
a forrás felhasználó

szavazat
3

Annak a ténynek köszönhetően, hogy nem kell kommunikálni a központi szerver folyamatosan, nagyjából minden parancs fut kevesebb, mint egy második (nyilván git push / pull / lekérés lassabb egyszerűen azért, mert a initalise SSH kapcsolat). Elágazás sokkal sokkal könnyebb (egy egyszerű parancsot ág, egyetlen paranccsal egyesíteni)

Válaszolt 30/08/2008 13:01
a forrás felhasználó

szavazat
22

A főbb pontok azt szeretem DVC-k azok:

  1. Akkor elkövetni törött dolgokat. Nem számít, mert más népek nem fogja látni őket, amíg meg nem tesz közzé. Adja idő eltérő a elkövetni időben.
  2. Emiatt lehet elkövetni gyakrabban.
  3. Egyesítheti teljes functionnality. Ez functionnality lesz saját ág. Minden vállalkozik ezen ága lesz ehhez kapcsolódó functionnality. Meg tudod csinálni egy CVC azonban a DVC-k az alapértelmezett.
  4. Kereshet a történelem (találni, amikor egy függvény változott)
  5. A visszavonás a pull, ha valaki csavarja fel a main tárolóból, akkor nem kell kijavítani a hibákat. Csak törölje az egyesítést.
  6. Ha szüksége van egy forrás kontroll minden könyvtárban csinálni: git init. és akkor lehet elkövetni, ha visszavonja változások, stb ...
  7. Ez gyors (akár Windows)

Ennek fő oka a viszonylag nagy projekt a jobb kommunikáció által létrehozott pont 3. Mások szép bónuszokat.

Válaszolt 04/09/2008 12:06
a forrás felhasználó

szavazat
9

Subversion még sokkal használt verziókövető rendszer, ami azt jelenti, hogy az jobb eszköz támogatja. Megtalálja érett SVN plugins szinte minden IDE , és vannak jó felfedező kiterjesztés elérhető (mint TurtoiseSVN). Más, mint, hogy én is, hogy egyetértek Michael : Git nem jobb vagy rosszabb, mint a Subversion, ez más.

Válaszolt 18/09/2008 19:44
a forrás felhasználó

szavazat
110

Egyéb válaszokat végzett jó munkát elmagyarázza az alapvető jellemzői a Git (amelyek nagy). De van még olyan sok apró módon Git jobban viselkedik, és segít megőrizni az életemet normális. Íme néhány a kis dolgok:

  1. Git egy „tiszta” paranccsal. SVN nagy szüksége van a parancs, figyelembe véve, hogy milyen gyakran fogja szedni extra fájlokat a lemezen.
  2. Git rendelkezik a „felezik” paranccsal. Ez szép.
  3. SVN teremt .svn könyvtárak minden egyes mappa (Git csak akkor hoz létre egy .git könyvtár). Minden script írsz, és minden grep teszel, akkor ki kell írni, hogy figyelmen kívül hagyják ezeket .svn könyvtárakat. Azt is meg kell egy teljes parancs ( „svn export”) csak azért, hogy egy normális példányt a fájlokat.
  4. Az SVN, minden fájl és mappa jöhet egy újabb verziója, vagy elágazik. Eleinte úgy hangzik, hogy ezt a szabadságot. De mi ez valójában azt jelenti, hogy van egy millió különböző módon a helyi pénztár, hogy teljesen elcseszte. (Például, ha „svn switch” sikertelen felénél, vagy ha egy parancs rossz). És a legrosszabb az egészben: ha valaha is a helyzet, amikor bizonyos fájlok jönnek egy helyen, és néhány közülük más, a „svn status” fogja mondani, hogy minden normális. El kell csinálni „svn info” minden fájl / könyvtár felfedezni milyen fura dolgok. Ha a „git status” azt mondja, hogy a dolgok normális, akkor bízom abban, hogy a dolgok valóban normális.
  5. Meg kell mondani, SVN, ha áthelyezi vagy törölni valamit. Git majd csak kitalálom.
  6. Figyelmen kívül hagyja szemantika könnyebb Git. Ha figyelmen kívül hagyjuk a mintát (például * .pyc), akkor figyelmen kívül hagyja az összes alkönyvtárat. (De ha igazán akarjuk, hogy figyelmen kívül hagyja valamit, csak egy könyvtárba, akkor). Az SVN, úgy tűnik, hogy nincs egyszerű módja annak, figyelmen kívül hagyja a minta az összes alkönyvtárat.
  7. Egy másik elem bevonásával fájlok kihagyása. Git lehetővé teszi, hogy a „saját” figyelmen kívül hagyja a beállításokat (a fájl .git / info / kizárás), amely nem befolyásolja senki másnak.
Válaszolt 26/09/2008 01:18
a forrás felhasználó

szavazat
15

A vicces az: I fogadó projektek Subversion Repos, de őket elérni a git clone parancs.

Kérjük, olvassa el kidolgozni a Git egy Google Code Project

Bár a Google Code natívan beszél Subversion, könnyen használható Git fejlesztés során. Keres „git svn” azt sugallja, ez a gyakorlat széles körben elterjedt, és mi is javasoljuk, hogy kísérletezzen vele.

Használata Git egy SVN ad nekem ellátások:

  1. Tudok dolgozni elosztott több gépre, elhatározod és meghúzva, és rájuk
  2. Van egy központi backup/public SVN mások, hogy ellenőrizze
  3. És szabadon használhatja Git saját
Válaszolt 02/10/2008 14:05
a forrás felhasználó

szavazat
5

Szeretem Git mert valóban segít kommunikáció fejlesztő fejlesztő egy közepesen nagy csapat. Mint egy elosztott verziókezelő rendszer révén toló / húzó rendszer, ez segít a fejlesztőknek, hogy a forráskód öko-rendszer, amely segít kezelni a nagy medence fejlesztő dolgozik egy közös projekt.

Például azt mondják, ha megbízik 5 fejlesztők, és csak húzza kódokat a tárolóból. Mindegyik azok a fejlesztők a saját bizalmi háló, ahonnan húzza kódokat. Így a fejlődés alapja a bizalom, hogy a szövet a fejlesztők ahol a kódot felelőssége megoszlik a fejlesztői közösség.

Természetesen vannak más előnyök, amelyek különböznek a más válaszokat.

Válaszolt 05/10/2008 17:52
a forrás felhasználó

szavazat
56

Miért Git Jobb, mint az X ” felvázolja a különböző előnyeiről és hátrányairól Git vs más SCM.

röviden:

  • Git pályák tartalom helyett fájlokat
  • Ágak könnyű és összevonása az egyszerű , és azt jelenti, nagyon egyszerű .
  • Ez elosztva, lényegében minden adattár egyik ága. Ez sokkal könnyebb fejleszteni egyidejűleg vagy másokkal együtt, mint a Subversion, véleményem szerint. Azt is teszi az offline fejlődés lehetséges.
  • Ez nem ró munkafolyamat , ahogy a fenti linkelt