Bevezetés a Git egyesítésébe és újbóli megalkotásába: mik ezek és hogyan kell használni őket

Fejlesztőként sokunknak választania kell az Egyesítés és az Újrabázis között. Az internetről származó összes hivatkozással mindenki úgy véli, hogy „Ne használja a Rebase-t, ez komoly problémákat okozhat.” Itt elmagyarázom, hogy mi az egyesítés és újrabázis, miért kell (és nem kellene) használni őket, és hogyan kell ezt megtenni.

A Git Merge és a Git Rebase ugyanazt a célt szolgálják. Úgy tervezték, hogy a több ágból származó változásokat integrálják egybe. Annak ellenére, hogy a végső cél ugyanaz, ez a két módszer különböző módon éri el ezt, és hasznos tudni a különbséget, amikor jobb szoftverfejlesztővé válik.

Ez a kérdés megosztotta a Git közösséget. Egyesek úgy gondolják, hogy mindig újra kell alapozniuk, mások pedig, hogy mindig egyesülniük kell. Mindkét félnek vannak meggyőző előnyei.

Git Merge

Az egyesítés a verziókezelő rendszereket használó fejlesztők számára bevett gyakorlat. Akár az ágakat tesztelés, hibajavítás vagy más okokból hozzák létre, az összevonás változtatásokat hajt végre egy másik helyre. Pontosabban: az összevonás elveszíti a forráság tartalmát, és integrálja azokat egy célággal. Ebben a folyamatban csak a célág változik. A forráság története ugyanaz marad.

Előnyök

• Egyszerű és ismerős
• Megőrzi a teljes történelmet és időrendet
• Fenntartja az ág összefüggéseit

Hátrányok

• Az elkötelezettség története sok egyesítési elkötelezettséggel szennyeződhet
• A hibakeresés használatával git bisectnehezebbé válhat

Hogyan kell csinálni

A checkoutés a mergeparancsok segítségével egyesítse a főágat a szolgáltatáságba .

$ git checkout feature $ git merge master (or) $ git merge master feature

Ez egy új „ Merge-elkötelezettséget ” hoz létre a szolgáltatáságban, amely mindkét ág történetét tartalmazza.

Git Rebase

A Rebase egy másik módja az egyik ágról a másikra történő integráció integrálásának. A Rebase az összes változtatást egyetlen „javítássá” tömöríti. Ezután integrálja a javítást a célágba.

Az egyesítéssel ellentétben az újbóli alapozás ellapozza a történelmet, mert az elkészült munkát egyik ágról a másikra továbbítja. Ennek során megszűnik a nem kívánt előzmények.

Az újrabázisok azt mutatják, hogy a változásoknak miként kell haladniuk a hierarchia tetejétől lefelé, az egyesülések pedig hogyan folynak visszafelé

Előnyök

• Korszerűsíti a potenciálisan összetett történelmet
• Egyetlen elkötelezettség kezelése egyszerű (pl. Visszaállítás)
• Kerüli a „zaj” egyesítését a forgalmas repókban, forgalmas ágakkal
• Megtisztítja a köztes kötelezettségvállalásokat egyetlen kötelezettségvállalássá téve őket, ami hasznos lehet a DevOps csapatai számára

Hátrányok

• Ha a funkciót elhalasztja egy maroknyi elkötelezettségig, elrejtheti a kontextust
• A nyilvános adattárak újrafeldolgozása veszélyes lehet, ha csapatként dolgozunk
• Ez több munka: A rebase használatával a szolgáltatáság mindig frissül
• A távoli ágakkal történő újbóli futtatáshoz kényszeríteni kell a lökést. A legnagyobb probléma, amellyel az emberek szembesülnek, kényszerítik a push-t, de nem állítják be a git push alapértelmezett értékét. Ennek eredményeként frissülnek az összes azonos ágú ágak, mind lokálisan, mind távolról, és ez rettenetes kezelni.

Ha helytelenül újrabázolsz, és akaratlanul is átírod az előzményeket, az komoly problémákhoz vezethet, ezért győződjön meg róla, hogy tudja, mit csinál!

Hogyan kell csinálni

Újra futtassa a szolgáltatáságat a főágra a következő parancsokkal.

$ git checkout feature $ git rebase master

Ez az egész szolgáltatáságat a főág tetejére helyezi. Ezt úgy csinálja, hogy átírja a projekt előzményeit, és új kötelezettségvállalásokat hoz létre az eredeti (szolgáltatás) ág minden egyes elkötelezettségéhez.

Interaktív újraindítás

Ez lehetővé teszi a változtatások végrehajtását, amikor az új ágba kerülnek. Ez erőteljesebb, mint az automatikus újbóli bontás, mivel teljes ellenőrzést kínál a fióktelep története felett. Jellemzően ezt használják a rendetlen történelem megtisztítására, mielőtt a funkció ágat beolvasztanák a masterbe.

$ git checkout feature $ git rebase -i master

Ez megnyitja a szerkesztőt azáltal, hogy felsorolja az összes áthelyezni kívánt elkötelezettséget.

pick 22d6d7c Commit message#1 pick 44e8a9b Commit message#2 pick 79f1d2h Commit message#3

Ez pontosan meghatározza, hogy az ág hogyan fog kinézni az újrabázis végrehajtása után. Az entitások újrarendelésével az előzményeket úgy alakíthatja ki, amilyet csak akar. Például, ha olyan parancsokat, mint a fixup, squash, editstb helyett pick.

Melyiket kell használni

Tehát mi a legjobb? Mit ajánlanak a szakértők?

Nehéz általánosítani és dönteni egyik vagy másik mellett, mivel minden csapat más és más. De valahol el kell kezdenünk.

A csapatoknak számos kérdést kell figyelembe venniük a Git újrabázis és egyesítés irányelveinek meghatározásakor. Mert mint kiderült, az egyik munkafolyamat-stratégia nem jobb, mint a másik. Ez a csapatától függ.

Vegye figyelembe az újrabázolás és a Git kompetencia szintjét az egész szervezetében. Határozza meg, hogy milyen mértékben értékeli az újrabázis futtatásának egyszerűségét az egyesítés nyomon követhetőségéhez és történetéhez képest.

Végül az egyesítésre és az újrabeépítésre vonatkozó döntéseket egy világos elágazási stratégia keretében kell mérlegelni (Az elágazási stratégiával kapcsolatos további információkért olvassa el ezt a cikket ). A sikeres elágazási stratégia a csapatok szervezete köré épül.

Mit ajánlok?

Ahogy a csapat növekszik, a mindig egyesülő politikával nehéz lesz kezelni vagy nyomon követni a fejlesztési változásokat . A tiszta és érthető elköteleződési előzményekhez a Rebase használata ésszerű és hatékony.

A következő körülmények és irányelvek figyelembevételével a lehető legjobban kihozhatja a Rebase-t:

• Helyben fejlődik: Ha nem osztotta meg másokkal a munkáját. Ezen a ponton előnyben kell részesítenie az újrabázolást az összevonás helyett, hogy az előzmények rendben legyenek. Ha megvan a személyes tárolóvillája, és ezt nem osztják meg más fejlesztőkkel, akkor biztonságosan újrabázolhatja az fiókját is.
• Kódja készen áll az ellenőrzésre: Ön létrehozott egy lekérési kérelmet. Mások felülvizsgálják az Ön munkáját, és potenciálisan behelyezik a villájukba helyi ellenőrzés céljából. Ezen a ponton nem szabad újraalapoznia a munkáját. Létre kell hoznia egy „átdolgozott” elkötelezettséget, és frissítenie kell a szolgáltatáságat. Ez elősegíti a lekérés nyomon követhetőségét és megakadályozza a történelem véletlenszerű feltörését.
• A felülvizsgálat elkészült és készen áll a célágba történő integrálásra. Gratulálunk! Törölni készülékszakaszt. Tekintettel arra, hogy más fejlesztők ettől a ponttól kezdve nem fognak beolvadni ezekbe a változtatásokba, ez az esély arra, hogy megtisztítsa az előzményeket. Ezen a ponton átírhatja az előzményeket, és összecsukhatja az eredeti kötelezettségvállalásokat, és ezek a bosszantó „pr átdolgozás” és „egyesítés” elkötelezettségek egy kis összpontosított kötelezettségvállalássá válnak. Ezeknek az elkövetéseknek a létrehozása nem kötelező, de értéke van. Rögzíti, hogy a funkció mikor lett master.

Következtetés

Remélem, hogy ez a magyarázat némi betekintést adott a Git egyesítésébe és a Git újraindításába. A Merge vs rebase stratégia mindig vitatható. De talán ez a cikk segít eloszlatni a kételyeidet, és lehetővé teszi, hogy a csapatod számára megfelelő megközelítést alkalmazzon.

Alig várom, hogy írjak a Git munkafolyamatairól és a Git koncepcióiról . Kommentelje azokat a témákat, amelyekről azt szeretné, hogy legközelebb írjak. Egészségére!

code = coffee + developer

kódoló iskola szoftverfejlesztőknek