A Git és hasonló verziókezelő rendszerek közötti különbség elsősorban abban érhető tetten, hogy minden Git munkamásolat (working copy) egy teljes értékű repository teljes verzió történettel és teljes revízió követési lehetőséggel. Ennek egyik előnye az, hogy a Git nem függ a hálózat elérésétől vagy központi szervertől.
A Git felépítése, szintézise Linus Torvalds nagy, szétosztott fejlesztési projektekben nyert tapasztalatain, a fájlrendszerekben való jártasságának, és egy működő rendszer mielőbbi felállításának igényén alapszik. Ezek alapján hozták meg az az alábbi megvalósítási szabályokat:
- A nem-lineáris fejlesztés erős támogatása: természetesen támogatja a branch-ok készítését, összefésülésüket, de tartalmaz eszközöket a nem-lineáris fejlesztési történet ábrázolására is (előzetes fejlesztési tapasztalatok alapján a Gitben egy változás többször kerül összefésülésre, mint amennyi időt maga a változtatás igényel)
- Szétosztott fejlesztés: minden fejlesztő helyi munkaváltozatában rendelkezésre áll a teljes addigi fejlesztési történet, és a változtatások másolása MINDIG két repository között történik. Ezek a változtatásokat mint külön ágakat importálják és összefésülhetőek, hasonlóan a helyben létrehozott fejlesztési branch-okhoz.
- A repositoryk elérhetőek HTTP, FTP, rsyncen keresztül, vagy a Git protokollt használva egy socketen vagy SSH-n keresztül.
- Nagy objektumok hatékony használata: Gitet egy nagyon gyors és skálázható rendszerként mutatták be és a Mozilla által végzet teljesítménytesztek megmutatták, hogy egy nagyságrendi sebességfölénye van minden más revízió követő rendszerhez képest (bizonyos műveletek esetén akár két nagyságrenddel is).
- Kriptográfiailag hitelesített történet: a Git-történet (hiostory) olyan módon kerül tárolásra, hogy a szóban forgó revízió neve függ a hozzávezető fejlesztési történettől, így ha egyszer már publikálva van, akkor nem lehetséges megváltoztatni egy régi revíziót észrevétlenül.
Git erősségei
- A legtöbb verziókezelő a fájlok eredeti verzióit és az ahhoz képesti változásokat rögzíti.Ezzel szemben a git ún. snapshot-okat tárol, ami lehetővé teszi azt, hogy úgy működjön mint egy mini fájlrendszer.
- A git tömörített objektumokban tárol és a SHA-1 hash értékkel azonosít mindent (fájlok, könyvtárfa, commitok).
- Egyszerű esetben a commitok szép sorban követik egymást, de merge esetén egy commit-nak két (vagy több) szülője is lehet majd.
- Egy fájl háromféle állapotban lehet a git tárolón belül: modified, staged vagy committed.
- Stage area: egy átmeneti terület, ahol commitálás előtt összerakhatod a commitodat, hogy az úgy nézzen ki, ahogyan szeretnéd. Ez egyben lehetővé teszi azt is, hogy egy módosított fájl csak bizonyos részeit rakd be az indexbe.
- Stash: Néha branch-váltáskor (páldául amikor csak gyorsan szeretnél megnézni valamit a másik ágon) nem kellemes commitolni csak azért hogy válthass, pedig a váltáshoz tiszta munkakönyvtár kell. Hogy a munkakönyvtáradat gyorsan kitakarítsd, felteheted a még nem commitolt változtatásaidat és az index(stage) tartalmát „ a polcra”, ami egy stack a félkész dolgoknak.
- Squash: egyszerűsített histroy. A sok kicsi kommit lokálisan hasznos, de áttekinthet ˝obb lesz ha egyben töltöd fel az új feature-t a központba. Több szekvenciális kommit egybeolvasztható a –squash opcióval. Ha a feature-branch ágban kész vagy valamivel, akkor ezzel az összes feature-kommitot egyetlen kommitként is merge-elheted a master-be.
- Submodule: Al-projektek (repository-k) egy nagy projekten belül
- Remotes: Több távoli ”forrás” is használható egy repositoryban
