A Git-előzmények ismertetése

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

A Git az előzményeket a teljes adattár pillanatképeinek – úgynevezett véglegesítéseknek – gráfjaként tárolja. Minden véglegesítés egy vagy több korábbi véglegesítésre mutató mutatót is tartalmaz. A véglegesítések több szülővel is rendelkezhetnek, és egyenes vonal helyett gráfnak tűnő előzményeket hozhatnak létre. Ez a különbség a történelemben hihetetlenül fontos, és ez a fő oka annak, hogy a felhasználók zavarónak találják a Gitet.

Feljegyzés

Ha nem talál olyan változást a Git-előzményekben, amelyet ön is ismer, többet tudhat meg arról, hogyan működik a Git előzményeinek egyszerűsítése a Gitnél : A Git előzményeinek egyszerűsítése.

A véglegesítési előzmények alapjai

Kezdje egy egyszerű előzmény példával: egy adattár 3 lineáris véglegesítéssel.

három véglegesítés egy sorban

Az A véglegesítés a B véglegesítés szülője, a B véglegesítés pedig a C véglegesítés szülője. Ez az előzmény nagyon hasonlít a CVCS-hez. A C véglegesítésre mutató nyíl egy ág. Azért van elnevezve main , mert ez a Git-adattár fővonali ágának alapértelmezett neve. Az ágak adott véglegesítésekre mutatnak, ezért az elágaztatás olyan egyszerű és egyszerű a Gitben.

A Gitben a CVCS-hez képest az a legfontosabb különbség, hogy az adattár saját teljes másolatával rendelkezem. A helyi adattárat szinkronban kell tartanom a távoli adattárral úgy, hogy lekértem a legújabb véglegesítéseket a távoli adattárból. Ehhez lekéri a fő ágat a következő paranccsal:

git pull origin main

Ez a másolat ("lekérés") minden véglegesítést a main távoli adattár ágából (alapértelmezés szerint meghívva origin ) a main helyi adattár ágára másol. A lekéréses művelet egy új véglegesítést másolt, és a main helyi adattár ága most erre az új véglegesítésre mutat.

A negyedik véglegesítés (D) hozzáadva a sorhoz

Ágelőzmények ismertetése

Most módosítani szeretném a kódomat. Gyakori, hogy több aktív ága van, amelyeken párhuzamosan különböző funkciókon dolgozik. Ez éles ellentétben áll a CVCS-rel, ahol az új ágak nehézkesek és ritkán jönnek létre. Az első lépés egy új ágba való kivétel a következő paranccsal:

git checkout -b cool-new-feature

Ez egy billentyűparancs, amely két parancsot kombinál: git branch cool-new-feature az ág létrehozásához, majd git checkout cool-new-feature az ágban való munka megkezdéséhez.

A rendszer hozzáadja a ritka elérésű ág új funkcióját

Két ág most ugyanarra a véglegesítésre mutat. Módosítok néhány módosítást az cool-new-feature ágon két új véglegesítésben: E és F.

két új véglegesítés hozzáadása

A véglegesítéseket az ág érheti el, mivel ebben az cool-new-feature ágban készítettem őket. Befejeztem a funkciómat, és szeretném egyesíteni a funkcióval main. Ehhez a következő parancsot használom:

git merge cool-feature main

az egyesítés után

Az előzmények gráfszerkezete egyesítéskor láthatóvá válik. A Git új véglegesítést hoz létre, amikor az ágat egy másik ágba egyesítem. Ez egy egyesítési véglegesítés. Az egyesítési véglegesítés nem tartalmaz módosításokat, mivel nem voltak ütközések. Ha ütközések lennének, az egyesítési véglegesítés tartalmazza az ütközések feloldásához szükséges módosításokat.

Történelem a való világban

Íme egy példa a Git-előzményekre, amelyek jobban hasonlítanak a csapat aktív fejlesztéséhez szükséges kódra. Három személy egyesíti a véglegesítéseket a saját ágaiból a fő ágba nagyjából ugyanabban az időben.

a Git Graph konzolnaplója

Most, hogy megismerte, hogyan hozzák létre az ágak és az egyesítések a gráf alakját, ez nem lehet túl ijesztő!