Egy verziókövető rendszer alatt olyan eszözök összeségét értjük, melyek segítségével fájlok állapotának előzményeit tudjuk tárolni. Tehát egy verziókövető rendszer segítségével bármikor elmentheted a fájlaid aktuális állapotát és a korábbi állapotokat bármikor visszaállíthatod.
Az SVN-ek tipikus műveletei:
add
: fájl hozzáadásacommit
: változtatás fájlokon, a wroking directory állapotát elmenjük a repositorybadelete
: fájl törlésediff
: egy fájl összehasonlítása a repositoryban szereplő verzióvalstatus
: egész repository összehasonlítása a working directoryvallog
: eddigi változtatások listájacheckout
: working directory létrehozás a repository egy megadott verziója alapján update
: a working directory frissítése a repository alapjánrevert
: a working directory visszaállítása hogy egyező legyen a repository egy megadott állapotávalTöbb repository van, cél, hogy mind ugyanazt tartalmazza.
Egy lehetőség, hogy van egy központi repository. Ez többféle gondhoz is vezethet.
A Git nem ezt a modelt követi, hanem minden felhasználó rendelkezik a repository teljes másolatával. Így könnyű offline dolgozni, viszont időnként nehéz összehangolni a repositorykat.
Tutorial: https://realpython.com/python-git-github-intro/
Interaktív vizualizáció: https://learngitbranching.js.org/
A git esetén létezik egy staging area
. Ide kerülnek a commit-ra váró dolgok, melyeket végül egyben lehet commitolni.
Így minden fájlnak háromféle verziója is lehet egyszerre:
Név beállítás: git config --global user.name "your name goes here"
Új repository létrehozása: git init
. Az adott mappához lesz csatolva.
A git add file_név
a megadott fájlt a staging areaba helyezi.
A git commit
pedig a staging area tartalma alapján elmenti a dolgokat a repoba, létrehoz egy új "commit"-ot.
A változtatások mentése hatékonyan van megvalósítva, nem az egész fájl mentődik, hanem a különbség!
A git status
megmutatja, hogy éppen mi a külömbség a staging area és a workspace között
A git log
a korábbi commit-okat felsorolja.
A .gitignore egy szöveges fájl amiben megjelölhetjük, hogy mely fájlokat ne vegye figyelembe a github. Például:
__pycache__
venv
env
.pytest_cache
.coverage
Minden commit után egy hash érték számolódik ki és hozzárendelődik a commithoz. Ezzel az értékkel tudunk hivatkozni a commitokra.
Elég annyit megadni, amiből már egyértlemű.
git checkout sha
A branchekre úgy gondolhatunk mint egy cimke valamelyik commiton. Ha valamelyik cimkét aktiváljuk, akkor ott tudunk dolgozni. A cimke az új commitokkal együtt vándorol lefelé. Így nagyából a commitok által alkotott fa ágainak is megfelelnek branchek.
git branch newbranch
új branch létrehozásagit checkout branchname
Váltás egy adott branchreAz alavető branch általában master
vagy main
.
A HEAD
mutatja, hogy épp hová nézünk a fán. Ha egy commitot checkoutolunk egy branch helyett akkor "deatached HEAD" állapotba kerülünk.
Hármomféle mód van arra, hogy különböző branchekről commitokat rakjunk át egy másik branchre.
merging
rebasing
cherry-picking
Egy új commit segítségével kombinálja a két ágat.
Fast forward merge: ha az egyik ág a másikon alapszik, csak előreugrik a branch a megfelelő commit-ig.
A branch kiindulásának megváltoztatás, hogy úgy nézzen ki mintha máshonnan indultál volna. Ez abban segít, hogy lineáris maradjon a history.
Csak specifikusan megadott commitok végrehajtása az adott branch-en.
A gitre épülő rendszer, mely a távoli repositoryk fentartására lehet használni.
A fő parancsok:
git clone
Távoli repository alapján új repositorygit fetch
Távoli repository alapján megfelelő branchek frissítésegit pull
Távoli repository alapján megfelelő branchek frissítése majd merge git push
Távoli repository frissítése saját alapján