Kas yra Git submoduliai ir kokie yra alternatyvos?

Question

Accepted Answer

**Git submoduliai** leidžia įdėti vieną Git saugyklą į kitą kaip poaplankį — naudinga norint įtraukti bendras bibliotekas ar priklausomybes kaip atskiras saugyklas. Jie galingi, bet turi reputaciją dėl sudėtingumo, todėl juos suprasti ir žinoti alternatyvas yra vertinga. ## Kas yra submoduliai ```text A SUBMODULE is a reference to ANOTHER Git repository at a SPECIFIC COMMIT, embedded in your repo as a subdirectory: → the parent repo records WHICH repo and WHICH commit (a pinned reference, not a copy) → the submodule is its own repo with its own history → Used to include shared libraries/components that are themselves versioned repos. ``` ```bash git submodule add path/to/lib # add a submodule git clone --recurse-submodules # clone a repo WITH its submodules git submodule update --init --recursive # initialize/fetch submodules after a normal clone git submodule update --remote # update submodules to their latest ``` ## Sudėtingumas (kodėl submoduliai yra sudėtingi) ```text ⚠️ Submodules are pinned to a SPECIFIC COMMIT (not auto-updating) — easy to forget to update or commit the new reference ⚠️ Clones need --recurse-submodules (forgetting → empty submodule directories) ⚠️ Extra steps for updates; detached HEAD inside submodules; confusing for teams ⚠️ Changes in a submodule must be committed in the SUBMODULE repo, then the parent updated → multi-step, error-prone → Submodules work but have real ergonomic pain — a common source of team confusion. ``` ## Alternatyvos ```text ✓ PACKAGE MANAGERS — publish the shared code as a package (npm, pip, Maven, etc.) and depend on a VERSION → usually the cleanest approach for shared libraries ✓ MONOREPO — keep everything in one repo (no submodules; tooling like Nx/Turborepo/Bazel) ✓ git subtree — merges another repo's content INTO yours (simpler than submodules in some ways; no extra clone steps, but its own trade-offs) → Often a package manager or monorepo is preferable to submodules. ``` ## Kodėl tai svarbu Suprasti Git submodulius ir jų alternatyvas yra vertinga seniorinio lygio žinios dėl **bendro kodo ir priklausomybių valdymo skirtinguose saugyklose**, todėl tai naudinga priimant architektūrines sprendimus apie kodo organizaciją. **Submoduliai** sprendžia realią problemą — vienos saugyklos įdėjimą į kitą (kaip nustatyto nuorodo į konkrečią commit-ą) bendriems bibliotekoms ar komponentams, kurie patys yra versijuojamos saugyklos, įtraukti — ir suprasti, kaip jie veikia (tėvas įrašo, kuri saugykla ir commit-a, submodulį kaip jo paties saugyklą) bei komandas (pridėjimą, klonuojimą su `--recurse-submodules`, atnaujinimą) yra būtina dirbant su projektais, kurie juos naudoja. Kritiškai svarbu suprasti **sudėtingumą**: submoduliai turi gerai užsitarnautos reputacijos dėl sunkumų — pritvirtinti prie konkrečių commit-ų (lengva pamiršti atnaujinti), reikalingi `--recurse-submodules` klonuojant (pamiršus lieka tušti aplankai), reikalingi daugiapakopiai klaidžiai jautūs atnaujinimai ir supainioja komandas — todėl žinoti šiuos sunkumus padeda nustatyti realistas lūkesčius ir padeda išvengti įprastų frustracijų. Daugiausiai vertės turi suprasti **alternatyvas** ir kada jos yra geresnės: **paketų valdytojai** (bendro kodo leidimas kaip versijuotų paketų — paprastai čiaustas metodas bendriems bibliotekoms), **monorepos** (viskas viename repozitorijume su atitinkama įrankiais) ir **git subtree** (kitos saugyklos turinio sulieti, su skirtingais kompromisais). Žinojimas, kad paketų valdytojas arba monorepo dažnai yra geresnė pasirinkimas nei submoduliai, atspindi tvirtą architektūrinę nuomonę — pripažįstant, kad submoduliai, nors prieinami, dažnai nėra geriausias sprendimas. Kadangi bendro kodo valdymas skirtinguose saugyklose yra reali architektūrinė problema ir submoduliai (nepaisant jų sudėtingumo) yra vienas iš galimų sprendimų, suprasti Git submodulius, jų sudėtingumą ir alternatyvas (paketų valdytojus, monorepos, subtree) yra vertinga seniorinio lygio žinios priimant gerus sprendimus dėl kodo dalijimosi ir saugyklos organizacijos, atspindėdami architektūrinę nuomonę pasirinkti tinkamą metodą, o ne standartiškai pasirenkant dažnai problemiškas submodulius.