Ha a megélhetéshez írsz szoftvert 2018-ban, akkor azt mondhatom, hogy magabiztosan ismeri a Git-et. A Linus Torvalds által létrehozott eszköz a verziószabályozás szinonimájává vált. Kétségtelen, hogy Git egyik legjobb tulajdonsága az, hogy hogyan szünteti meg az elágazás és az egyesülés fájdalmát. Többféle módon hozhat létre fiókot a Git-ben. Ebben a bejegyzésben néhányat áttekintünk. Ezután egy kis gondolkodással zárjuk le Git elágazási modelljét és általában az elágazást.

Ág létrehozása a mesterből

Nem meglepő módon hoz létre fiókokat a Git-ben az branch parancs használatával. Mint sok más Git-parancs, az “branch” is nagyon hatékony és rugalmas. Az ágak létrehozása mellett felsorolásra és törlésre is használható, és tovább testreszabható a parancsot a paraméterek széles listájának felhasználásával. Kezdjük az ág létrehozásának első módszerével. Mondjuk, hogy új mappát akarsz létrehozni “my-app” néven, írd be, és indíts el egy új Git-tárat. Pontosan így csinálod:

mkdir my-appcd my-appgit init

Most van egy új, üres Git-tárod. De az üres tárak unalmasak. Mi a helyzet akkor, ha létrehozsz egy új jelölőfájlt, amelyben a “Hello World!” felirat szerepel?

echo Hello World! > file.md

Ha a “git status” futtatja, akkor egy üzenetet kell látnia, amely szerint a fájlja nincs nyomon követve:

A nem nyomon követett fájlok szintén nem hűtettek, tehát kövessük nyomon:

git add file.md

És végül hozzuk létre első elkötelezettség:

git commit -m "First commit"

Most egy tárral rendelkezünk egy ággal, amelynek pontosan egy elkötelezettsége van. Lehet, hogy ez nem úgy hangzik, mint legizgalmasabb dolog a világon (mert valójában nem “t”), de minden bizonnyal kevésbé unalmas, mint egy repo, amelynél nincs semmilyen kötelezettségvállalás, igaz? Most mondjuk azt, hogy bármilyen okból meg kell változtatnia a fájlt tartalma. De nem teszed van kedve ezt csinálni. Mi van, ha valami elromlik, és valahogy elrontja a fájl gyönyörű, érintetlen tartalmát? (Igen, tudom, hogy ez csak egy hülye fájl, benne a „Hello World!”, De használja ki fantáziájának csodálatos erejét, és gondolja a fájlt egy sokkal összetettebb projekt proxyként.) A probléma megoldása természetesen új ágat hoz létre:

git branch exp

Tehát most van egy új “exp” nevű fióktelepünk a kísérletezéshez Néhány ember, aki szokott használni különféle verziós rendszereket, különösen központosítottakat, azt mondhatja, hogy az ágak azonos “tartalommal” rendelkeznek. Ez azonban nem egészen pontos, ha Gitről beszélünk. Gondoljon olyan ágakra, mint a hivatkozások, amelyek egy adott elkötelezettségre utalnak.

Ág létrehozása elkötelezettségből

Tegyük fel, hogy bármilyen okból lemondunk kísérletünkről, egyetlenegy hozzáadása nélkül. kötelezze el magát az új ág mellett. Térjünk vissza a mesterre és töröljük az exp ágat:

git checkout mastergit branch -d exp

Most, hogy visszatérünk egyetlen ághoz, adjunk hozzá néhány elkötelezettséget, az elvégzett munka szimulálására:

Képzelje el, hogy mindezen „munka” elvégzése után megtanulja, hogy bármilyen okból is vissza kell térnie az időben, amikor ott van csak két sor volt a fájlban, és onnantól kezdve új változásokat hoztak létre. Ugyanakkor meg kell őriznie a már elért előrehaladást. Más szavakkal, egy elkötelezettséget szeretne létrehozni egy korábbi elkötelezettségből. Hogyan tenné ezt ? A Git-ben minden elkötelezettségnek egyedi azonosítója van. Tehát ezt könnyedén láthatja a “git log” paranccsal. Ha új elágazást szeretne létrehozni egy adott elkötelezettség alapján, egyszerűen adja át annak hashját paraméterként az branch parancshoz:

git branch new-branch 7e4decb

Félretéve nem is kell az egész kivonat legtöbbször. Csak az első öt vagy hat karakter fogja megtenni.

Elágazás létrehozása címkéből

Ha egy kicsit tapasztaltabb vagy a Gitnél, akkor ismernie kell a címkék fogalma. Címkékkel jelzi, hogy egy adott elkötelezettség valamilyen szempontból fontos vagy különleges. Például a címkéket általában a termék tényleges verzióinak jelzésére használják. Ha egy ideje dolgozik az alkalmazásában, és úgy gondolja, hogy itt az ideje kiadni az 1.0-s verziót, amit tipikusan az tesz, hogy a verziószámokat ütközik, ahol csak szükséges, elvégzi ezeket a változtatásokat, majd hozzáad egy címkét az adott időponthoz. Címke létrehozásához általában ilyesmit futtat:

git tag -a v1.0 -m "First major version"

Az “-a” paraméter jelzi, hogy ez megy A könnyű címkével ellentétben ez egy teljes értékű Git objektum, amely olyan információkat tartalmaz, mint az elkövető neve és e-mail címe, az időbélyegző és az üzenet. Most van egy címkéje, amely jelzi, hogy a történelem ezen pontja különleges és van neve. Szép. A szokásos módon folytathatja a munkát, az 1.1-es verzió részét képező módosítások létrehozásával és végrehajtásával. Amíg nem érkezik hibajelentés. Néhány ügyfél, amelyet frissítettek az 1-re.A termék 0 verziója szerint az importálási funkció nem úgy működik, ahogy tervezték. Nos, elméletileg kijavíthatná a hibát a főágban és telepítheti. De akkor az ügyfelek olyan funkciókat kapnak, amelyek potenciálisan nem teszteltek és hiányosak. Ez nem -nem. Szóval, mivel foglalkozol? A válasz: Új fiókot hoz létre az általad létrehozott címkéből, hogy jelezze a fő verziót. Ott kijavítja a problémát, felépíti és telepíti. És valószínűleg ezt később vissza kell egyesítenie a mesterré, így a következő kiadások tartalmazzák a javítást . Hogyan járna ezzel? Könnyű:

git branch <NAME-OF-THE-BRANCH> <TAG>

Pontosabban az előző példánkkal:

git branch fix-bug-123 v1.0

Ezt követően a szokásos módon megtekintheti új fiókját. Vagy még jobb, ha mindezt egy lépésben teheti meg:

git checkout -b fix-bug-1234 v1.0

Kirendeltség létrehozása független fejállamban

Szerettél volna valaha is visszamenni az időben? lehetséges … legalábbis a tárunkban lévő fájlok tekintetében. Bármikor megnézhet egy elkötelezettséget, ha ismeri a kivonatát:

git checkout <SHA1>

A futtatás után a Git kíváncsi üzenetet jelenít meg:

You are in "detached HEAD" state. You can look around, make experimentalchanges and commit them, and you can discard any commits you make in thisstate without impacting any branches by performing another checkout.

Amikor kijelentkezik elkötelezettség, belép egy speciális állapotba c alled, amint láthatja, “levált FEJ”. Míg változtatásokat hajthat végre ebben az állapotban, ezek az elkövetések nem tartoznak egyetlen ághoz sem, és elérhetetlenné válnak, amint megnézel egy másik fiókot. De mi van, ha meg akarod tartani ezeket az elkötelezettségeket? A válasz nem meglepő, hogy használd a “checkout” parancsot új fiók létrehozásához:

git checkout <sha1> #now you"re in detached head state# do some work and stage itgit commit -m "add some work while in detached head state"git branch new-branch-to-keep-commitsgit checkout new-branch-to-keep-commits

És természetesen mostanra már tudod, hogy megírhatod a utolsó két sor egyetlen parancsként:

git checkout -b new-branch-to-keep-commits

Nagyon egyszerű, igaz?

Csak azért, mert tudsz … Nem azt jelenti, hogy kellene

A Git elágazási modellje az egyik eladási pontja. Könnyűvé teszi azt, ami más forrásszabályozó rendszerekben egy fájdalmas, sőt lassú folyamat. Mondhatni hogy a Git sikeresen demokratizálta az elágazásokat a tömegek számára. De komoly veszélyt rejt magában. A Gitben történő elágazás olcsósága miatt egyes fejlesztők csapdába eshetnek, ha rendkívül hosszú életű ágakkal dolgoznak, vagy munkafolyamatokat vagy elágazási modelleket alkalmaznak, amelyek késleltetik reszelés. Mi, mint iparág, ott voltunk. “Megtettük. Nem működik. Ehelyett fogadjon el olyan munkafolyamatokat, amelyek rendkívül rövid életű ágakat alkalmaznak. Lesz egy biztonságos homokozója, amelyben kódolhat, anélkül, hogy félne a dolgok feltörésétől vagy a munkatársak idejétől. De vajon megkérdezi: “Hogyan telepíthetek részben befejezett szolgáltatásokkal rendelkező kódot?” Ebben az esetben a zászlókat megmenti. A Git ágak hatékony eszköz. Használja őket okosan, és ne éljenek vissza velük. Ha pedig nem elegendőek, alkalmazzon folyamatos szállítást / folyamatos integrációt a funkciójelzőkkel együtt – beleértve a rendelkezésére álló speciális eszközöket is -, hogy alkalmazásai a következő szintre kerülhessenek.