Bitbucket mentés: amit egy git klón nem hoz vissza

A Bitbucket mentés témája általában egy megnyugtató mondattal szokott lezárulni: a git elosztott, minden fejlesztőnél ott a teljes klón, tehát a verziókezelő önmagát menti. Ez félig igaz, és a hiányzó fele a drága. Az Atlassian saját, dokumentált eljárása egy törölt Bitbucket Cloud repository helyreállítására az, hogy építse újra egy helyi másolatból, ami már megvan Önnek — a klón viszont a commitokat és a branch-eket hozza vissza, a köréjük épült review-előzményt nem.

Ez a bejegyzés végigveszi, mit ad a Bitbucket Cloud natívan, mit állít vissza ténylegesen az Atlassian dokumentált helyreállítási útja, és mit tesz hozzá egy független másolat.

Az Atlassian dokumentált helyreállítási útja: az Ön saját klónja

A Jira Clouddal és a Confluence Clouddal ellentétben — amelyekben van adminisztrátor által indítható Backup Manager — a Bitbucket Cloud nem kínál ezzel egyenértékű teljes exportgombot. A témáról szóló tudásbázis-cikkének címe önmagáért beszél: Reinstating deleted Bitbucket repositories from a local copy, azaz törölt repository-k helyreállítása helyi másolatból.

A dokumentált eljárás pontosan az, aminek hangzik:

1. Induljon ki egy olyan helyi másolatból, amely a törölt repository branch-einek nagy részét vagy mindegyikét tartalmazza
2. Legyen admin vagy írási jogosultsága a workspace-hez, SSH-kulccsal vagy API-tokennel
3. Hozzon létre egy új repository-t
4. Irányítsa át rá a helyi klónt — git remote set-url origin <remoteURL>
5. Töltse vissza a teljes tartalmat — git push --force --all

Az Atlassian útmutatója ezután a git log és a git branch -a paranccsal ellenőrizteti, hogy a branch-ek és a commitok visszakerültek. Érdemes észrevenni, mit tesz ez explicitté: a helyreállítás célja a branch és a commit. Törölt repository visszaállítása a Bitbucket Cloud felületén soha nem volt önkiszolgáló művelet.

Ennek a gyakorlati következménye az, hogy a verziókezelés katasztrófa-helyreállítási terve alapértelmezés szerint az, hogy kinél van éppen a legteljesebb klón. Ha egy repository pénteken törlődik, és a legfrissebb másolattal rendelkező kolléga szabadságon van, az visszaállítható állapot annyi, amennyit az utolsó git fetch lehúzott.

Amit egy git klón nem tartalmaz

Ez az a pont, ahol a csapatok rendszeresen meglepődnek, és ez nem is annyira az Atlassian korlátja, mint a git természetéből fakadó tény. A klón az objektum-adatbázist tartalmazza: commitokat, fákat, blobokat, tageket és branch-referenciákat. Nem tartalmaz semmit abból, amit a Bitbucket a kódról saját adatbázisában tárol. Ide tartozik:

• A pull requestek — a diffek, a hozzájuk tartozó vita, a jóváhagyások, és hogy ki mit hagyott jóvá
• A soron belüli review-kommentek és a konkrét kódsorokhoz fűzött szálak
• A branch-jogosultságok és merge-ellenőrzések — azok a szabályok, amelyek meghatározták, hogyan jutott a kód éles környezetbe
• A pipeline-konfiguráció állapota, a repository- és deployment-változók, valamint a deploy kulcsok
• A repository beállításai és hozzáférései — ki mit tehetett, és ez mikor változott

Sok fejlesztőcsapatnál ez bosszantó, de túlélhető. Aki viszont változáskezelési kötelezettség alatt működik, annak ez maga a probléma: a pull request jóváhagyási nyoma a változáskezelés bizonyítéka. Az ISO 27001 auditorok, a SOC 2 értékelők és a NIS2 egyeztetések mind azt kérdezik, hogyan igazolja, hogy az éles rendszereket érintő változásokat átnézték és jóváhagyták. Egy Bitbucket-alapú munkafolyamatban ez a bizonyíték a pull request jóváhagyásokban él — amit egyetlen git clone sem tartalmazott soha.

Ha egy repository-t egy fejlesztői gépről épít újra, a kód hiánytalanul visszajön, a köré épült teljes audit-nyom viszont nem. A commitok megvannak; annak a bizonyítéka, hogy bárki átnézte őket, nincs.

Hol jelentkezik valójában a kockázat

Törlés jogosult fiókkal. Egy workspace-admin — vagy egy támadó, aki admin hitelesítő adatokat szerzett — a terméken belülről törölhet repository-kat. Nem kell hozzá infrastruktúra-hozzáférés, és nincs a túloldalon önkiszolgáló visszavonás.

Force push és előzmény-átírás. Egy git push --force, amely felülír egy branch-et, jogosult, hitelesített művelet. Ha egyetlen helyi klónban sincsenek meg a felülírt commitok, az az előzmény valóban elveszett. Érdemes megjegyezni, hogy ugyanez a --force kapcsoló szerepel az Atlassian saját helyreállítási eljárásában is — ez jól mutatja, mennyire durva a rendelkezésre álló eszköz.

Lassan érlelődő kompromittálás. Egy támadó, aki hetekig bent ül a workspace-ben, mielőtt lépne, arra fogad, hogy az első változtatása előtti tiszta példány sehol nem maradt meg. Egy fejlesztői laptopokra épülő helyreállítási modell ellen ez észszerű fogadás.

Kilépő munkatárs. Amikor a ritkán használt repository legteljesebb klónjával rendelkező fejlesztő távozik, és a gépét letörlik, az adott repository tényleges mentése vele együtt megy el — és ez csak akkor derül ki, amikor szükség lenne rá.

Ugyanaz a megosztott felelősségi határ húzódik itt is, mint amit az Atlassian Cloud natív mentési korlátairól és arról írtunk, mit őriz meg valójában egy Confluence mentés. Az Atlassian üzemben tartja a Bitbucketet és túléli a saját hardverhibáit. Az, hogy a repository-i és az előzményük visszaállíthatók-e egy választott időpontra, a határvonal másik oldalán van.

Mit tesz hozzá egy független Bitbucket mentés

Egy független Bitbucket Cloud másolatnak azt kell lefednie, amit a klón szerkezetileg nem tud:

• Ütemezett mentés a repository-król — minden branch és tag, ütemezetten, olyan tárba, ami nem egy fejlesztő laptopja
• Pull request metaadatok — a review-k, kommentek és jóváhagyások, amelyek a változáskezelési bizonyítékot hordozzák
• Repository-konfiguráció — branch-jogosultságok, merge-ellenőrzések és pipeline-változók, hogy a visszaállított repo ugyanúgy szabályozva térjen vissza
• Időpont-alapú visszaállítás ahelyett, hogy „amit a legfrissebb klón éppen tartalmaz”
• Anomáliaészlelés, hogy egy tömeges repository-törlés a történés közben jelezzen
• Visszaállítás az Ön által felügyelt workspace-be, támogatási jegy nyitása és várakozás nélkül

Segítünk kiválasztani és bevezetni ezt a réteget, és gondoskodunk róla, hogy működjön is — a platform és a munkafolyamat az Öné marad, mi azt biztosítjuk, hogy a beállítás a tényleges Atlassian-környezetét fedje le. Az Atlassian Cloud mentés és helyreállítás oldal munkaterületenként mutatja be, mi kerül védelem alá, a NIS2 SaaS-mentési követelmények bejegyzés pedig részletesen tárgyalja a bizonyítási oldalt.

Hol érdemes kezdeni

Ha arra a kérdésre, hogy „hogyan állítanánk vissza egy törölt repository-t a review-előzményével együtt”, az őszinte válasz az, hogy „valakinél biztos van klón”, akkor egy felmérés a leggyorsabb módja kideríteni, mekkora ez a rés — rövid, gyakorlatias áttekintés a jelenlegi kitettségéről és arról, mit zárna le egy független másolat.