Stratégiák és összevonási stratégiák egyesítése

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

A lekéréses kérelem befejezésekor a témakörágat általában mainaz alapértelmezett ágba egyesíti. Ez az egyesítés hozzáadja a témakörág véglegesítéseit a főághoz, és létrehoz egy egyesítési véglegesítést az alapértelmezett és a témakörág közötti ütközések egyeztetéséhez. A lekéréses kérelemben szereplő megjegyzések és vitafórumok további kontextust adnak a témakörágban végrehajtott módosításokhoz.

Az ág (vagy más alapértelmezett ág) véglegesítési előzményei main nem követnek egyenes vonalat a kapcsolódó témakörágelőzmények miatt. A projekt növekedésével párhuzamosan nő a témakörágak száma, ami egyre nehezebbé teszi az alapértelmezett ágelőzmények követését.

Az alapértelmezett ág az egyes témakörágak előzményeinek pontos ábrázolása, de nehéz válaszolni a projekt fejlesztésével kapcsolatos szélesebb körű kérdésekre.

Squash egyesítés

A squash egyesítés egy egyesítési lehetőség, amellyel összevonhatja a témakörágak Git-előzményeit egy lekéréses kérelem teljesítésekor. Az alapértelmezett ág előzményeihez hozzáadandó témakörág összes véglegesítése helyett a fallabda-egyesítés az összes fájlmódosítást egyetlen új véglegesítéshez adja hozzá az alapértelmezett ágon. A squash-egyesítési véglegesítés nem hivatkozik a témakörágra, egy új véglegesítést hoz létre, amely tartalmazza a témakörág összes módosítását. Ezenkívül javasoljuk, hogy törölje a témakörágat a félreértések elkerülése érdekében.

Erre egyszerűen úgy gondolhat, hogy a squash merge csak a fájlmódosításokat adja meg, a rendszeres egyesítés pedig a fájlmódosításokat és a véglegesítési előzményeket.

Hogyan hasznos egy squash egyesítés?

A squash egyesítésével az alapértelmezett ágelőzmények tisztán és könnyen követhetők maradnak anélkül, hogy munkafolyamat-módosításokat igényelnek a csapaton. A témakörág közreműködői a kívánt módon dolgoznak a témakörágban, az alapértelmezett ágak pedig a squash-egyesítések használatával megőrzik a lineáris előzményeket. A fallabda-egyesítésekkel frissített ág véglegesítési előzményei main minden egyes egyesített ághoz egy-egy véglegesítéssel rendelkeznek. Ezt az előzményeket végigvezetve megtudhatja, hogy pontosan mikor fejeződött be a munka.

A squash egyesítésével kapcsolatos szempontok

A squash egyesítése összevonja az alapértelmezett ág módosításainak előzményeit, ezért fontos, hogy a csapattal együtt döntse el, mikor kell összefésülnie az egyesítést, vagy ha meg szeretné őrizni egy témakörág teljes véglegesítési előzményeit. Egyesítéskor érdemes törölni a forráságat. A forráság törlése megakadályozza a félreértéseket, mivel maga a témakörág nem rendelkezik véglegesítéssel, amely az alapértelmezett ágba egyesíti azt.

Lekéréses kérelmek teljesítése squash-egyesítéssel

A lekéréses kérelem Azure-adattárakban való végrehajtásakor dönthet úgy, hogy összenyomja az egyesítést.

A Teljes lekéréses kérelem párbeszédpanelEn válassza a Squash véglegesítés elemet az Egyesítés típus alatt a témakörág összevonásához.

Több egyesítési alap

A lekéréses kérelem Fájlok lapja háromoldalas összehasonlítással észleli a diffeket. Az algoritmus figyelembe veszi a célág utolsó véglegesítését, a forráság utolsó véglegesítését és a közös egyesítési alapjukat (azaz a legjobb közös elődet). Az algoritmus gyors, költséghatékony és megbízható módszer a változások észlelésére. Sajnos bizonyos esetekben több igaz alap is létezik. A legtöbb adattárban ez a helyzet ritka, de sok aktív felhasználóval rendelkező nagy adattárakban gyakori lehet. Manuálisan ellenőrizheti, hogy léteznek-e több egyesítési alap az ágak között. Ehhez futtassa git merge-base --all feature master a parancsot. Az Azure DevOps több egyesítési bázis meglétét észleli minden lekéréses kérelemhez. Ha ezek észlelhetők, az Azure DevOps megjeleníti a "Több egyesítési alap észlelése" üzenetet. A megjelenített véglegesítések listája hiányos lehet" a lekéréses kérelemhez. Bár az Azure DevOps több egyesítési bázis észlelését futtatja, nem ellenőrzi, hogy a lehetséges egyesítési alap már egyesült-e. Az ilyen ellenőrzést a git merge-base. Az Azure DevOps ezért akkor is megjelenítheti az üzenetet, ha git merge-base csak egy egyesítési alapról számol be.

Feljegyzés

Ha a lekéréses kérelem ellenőrzése során nem történt változás, győződjön meg arról, hogy nem több egyesítési alap okozza a problémát.

Az Azure DevOps a következő forgatókönyveket észleli több bázisként (az egyesítési alapokat az 1. és a 2. szám jelzi):

• Keresztegyesítések (más néven criss-cross) a különböző ágak között (az Azure DevOps és a git merge-base)

---1---o---A
    \ /
     X
    / \
---2---o---o---B

• Egy ág egyesítése másik kettővel (az Azure DevOps jelentése szerint, de nem azzal git merge-base , hogy megszünteti a 2. egyesítési bázist)

---1---o---o---o---A
    \         /
     \-------2
      \       \
       \---o---o---o---B

• A főág-visszaállítások utóhatásainak kezelése, például az egyesítési véglegesítés módosítása

*   42bb2d2 (HEAD, A) Amended merge commit
|\  
| | *   67c9bb8 (other) Merge branch 'A' into B
| | |\  
| |/ /  
|/| /   
| |/    
| * fa78e32 add second commit
* | 15845c9 add first commit
|/  
* 6a52130 add init

• Funkcióágak aktív újrafelhasználása
• Egyéb, nem intuitív és konvolúciós manipulációk visszaállítással, cseresznyecsákányokkal és egyesítésekkel

A több egyesítési alap észlelése a biztonságtudatosság része. Ha több egyesítési alap létezik, előfordulhat, hogy a felhasználói felület fájldiff algoritmusa nem észleli megfelelően a fájlmódosításokat attól függően, hogy melyik egyesítési bázist választja. Ha a lekéréses kérelemben szereplő fájlok különböző verziójúak az egyesítési bázisok között, több egyesítési alap figyelmeztetés jelenik meg.

További részletekért tekintse át a git hivatalos dokumentációját .

Több bázisból való egyesítés lehetséges biztonsági kockázatai

• A rosszindulatú felhasználók visszaélhetnek a felhasználói felületi algoritmussal a lekéréses kérelemben nem szereplő rosszindulatú módosítások véglegesítéséhez.
• Ha a lekéréses kérelemben javasolt módosítások már a célágban vannak, azok megjelennek a Fájlok lapon, de előfordulhat, hogy nem aktiválják a mappamódosításra leképezett ágszabályzatokat.
• Előfordulhat, hogy ugyanazon fájlok több egyesítési alapból származó két módosítása nem jelenik meg a lekéréses kérelemben. Ez az eset áruló logikai réseket eredményezhet.

Több egyesítési alap problémájának megoldása

A több egyesítési alap nem feltétlenül rossz, de ellenőrizze, hogy minden rendben van-e. Több egyesítési alap eltávolításához kösse az ágakat egyetlen közös elődhöz úgy, hogy az ágat a célhoz alakítja, vagy egyesíti a célokat az ágba. Ezek a műveletek eltávolítják a figyelmeztető üzenetet, és segítenek ellenőrizni, hogy a tényleges módosítások rendben vannak-e.

Az egyik módszer a helyreállítható visszaállítás és a folyamat elrejtése az újratelepítés vagy egyesítés előtt. Ezután létrehozhat egy új ágat, vagy újrabázisozhat egy üres ágat, és világos pontból alkalmazhatja a módosításokat. Ehhez a folyamathoz szükség lehet egy kényszerített leküldésre a távolira, ha a módosítások már léteznek.

A többszörös egyesítési alapokkal kapcsolatos probléma elkerülése

Az alábbiakban általános tippeket talál a többszörös egyesítési alapproblémák elkerüléséhez:

• Lekéréses kérelem előkészítésekor hozzon létre szolgáltatáságakat a fő vagy kiadási ág legújabb verzióiból.
• Ha szükséges, ne hozzon létre olyan ágakat, amelyek nem közvetlenül az adattár stabil ágaiból származnak.

Mi a teendő, ha újra megjelenik a több egyesítési alap problémája?

A sok aktív közreműködővel rendelkező nagy adattárakban ez a probléma különösen kényelmetlen lehet. Még ha több bázistól is megszabadul az egyesítéssel, előfordulhat, hogy a helyzet újra megjelenik. Ha valaki bezár egy régóta fennálló lekéréses kérelmet, az újra létrehozhatja a helyzetet. Annak ellenére, hogy a buildelési szabályzatok és tesztek futnak, nincs eszköze a lekéréses kérelem befejezésére. Az új ág alaphelyzetbe állítása és indítása segíthet. Ha semmi sem változik, a módosítások valószínűleg egyértelműek, még akkor is, ha a helyzet ismétli magát.

Következő lépések

• Egyesítési ütközések feloldása
• Lekéréses kérelem befejezése
• Tudnivalók a lekéréses kérelmekről