Skip to content
Snippets Groups Projects
Forked from Rafael László / Git Presentation
1 commit behind, 19 commits ahead of the upstream repository.

Sziasztok, <insert name here> vagyok!

Üdvözlök mindenkit. A videóban a gitről szeretnék mesélni nektek, és a végére remélem sikerül olyan szintű tudást átadnom, hogy a jövőben ne nagyon okozzon problémát a verziókezelés.
Olyan kérdésekre fogok választ adni, mint "Miért kell git-et használnom?", "Miért ilyen bonyolult ez az egész?" és "Mégis mi a francot nyerek ezzel?"
Amire szükséged lesz: egy konzol, működő git-el (erre majd később visszatérek).

A parancsokat nem kötelező nektek is kiadni, de egész hasznos lesz, ha már csináltatok ilyet a gyakorlatra.

Mi is az a verziókezelés?

(ide beszúrhatod a saját szövegedet, ha szeretnéd)

Biztos mindannyiótoknak van egy olyan élménye, hogy írt egy dokumentumot. Ezt elmentette, majd egy hét múlva újra írt bele, és szerette volna, hogy a korábbi munkája megmaradjon, vagy csak rögzíteni a különböző állapotokat.

Ezekből szoktak megszületni az itt látható mappák, fájlok.

(ide majd be fogok vágni egy képet, amin látszik a első.docx, első_v2.docx, etc...)

Természetesen ez lehetne egy használható megoldás, de mi van, ha szeretnénk valakivel ezt megosztani? Mi van ha a módosítás dátuma megváltozik közben? Hogyan biztosítjuk, hogy nem sérülnek a fájlok, és nem veszik el egy változata a munkánknak, amire lehet egy-két hét/hónap múlva mégiscsak vissza kell térjünk?

Erre adnak megoldást a különböző verziókezelő rendszerek. Ezeknek többek között dolguk, hogy számon tartsák a fájljainkat, ahogyan mi ezt kézzel megtettük.

Helyi

Erre a fenti példa a legjobb példa.
Vannak különböző verziói a fájlunknak és ezeket valamilyen adatbázisban rögzítjük.

(ide kép jön majd)

Központosított

Ez már egy fokkal okosabb. A különböző verziókat a központi szerverre rakjuk fel és onnan szedjük le.
Például van egy Fájlszerverünk amit minden gépről elérnek az emberek és oda dolgoznak közösen...
Érezhető probléma, hogy így ha meghal a központi szerver, akkor mindent elvesztünk (eskü nem volt még ilyen :sweat_smile:).
Továbbá probléma lehet, hogy egymás munkáját felülírjük, szerencsére egy jó rendszernél erről értesítést kapunk, hozzá és nem felülírjuk a módosításaink.

(ide kép jön majd)

Megosztott

Na és itt lépünk be a ma is használt Git világába. Ennél a megoldásnál már az a trükk, hogy mindenkinek megvan a teljes projekt az összes verziójával. Felmerül, hogy na de akkor honnan szedjük le a legújabb verziót? Különböző megoldások léteznek, például a fejlesztők a módosításokat azonnal megosztják egymással (pl.: p2p Torrenthez hasonló módon) vagy kijelölnek egy központi szervert amivel mindenki szinkronban van. Ilyen központi szerver lehet például a Github vagy a Gitlab.
Csak megjegyzem, akár a módosításokat emailben is el lehet küldeni és a szoftver automatikusan megcsinálja a többit a mi részünkön.

Git története

Még mielőtt belemerülnék a git telepítésébe, használatába, szeretnék némi sztorizást is megejteni.

Annó a Linux kernel fejlesztése során okozott nagy fejtörést az egész verziókezelés megoldása. 1991-től 2002-ig, tehát 11 éven át patchekben (pl.: e-mailben elküldött szöveg a módosításokkal) és tömörített fájlokban küldözgették a verziókat a fejlesztők. Aztán 2002-től egy zárt licenszű verzió kezelőre, a BitKeeper-re váltottak.

Ezt a Linux fejlesztői ingyen használhatták egészen 2005-ig, mikorra annyira elromlott a kapcsolat a fejlesztők és a cég között, hogy elvették tőlük a licenszt. Az i-re a pontott az tette fel, mikor az egyik kernel fejlesztő reverse engineer-elte a BitKeeper-t.
Ekkoriban Linus Torvalds úgy döntött, hogy egy új megoldást kell találnia, mely

  • gyors
  • egyszerű
  • támogatja a többszálú fejlesztést
  • teljesen elosztott
  • nagy projekteket is képes kezelni (pl.: Linux kernel)

Így hát megírta a Git-et, mely a mai napig a legelterjedtebb, leggyorsabb és legkényelmesebb verzió kezelő rendszer.