"매 repo-in-repo with pinned commit". Git submodule 매 외부 repository 의 specific commit 의 reference 의 host repo 안 의 nest. 매 2026 perspective: monorepo / package manager (pnpm workspaces, npm workspaces) 의 대부분 의 use case 의 replace, 매 vendoring binary asset, plugin SDK, firmware blob 의 niche 의 survive.
매 핵심
매 동작 model
매 host repo 의 .gitmodules file 의 url + path 의 list.
매 host repo 의 tree object 의 submodule path 의 gitlink (commit SHA) 의 store — 매 file 의 X.
매 git clone 의 default 의 submodule 의 fetch X — 매 --recursive 또는 git submodule update --init.
매 detached HEAD state 의 submodule 의 default — 매 branch tracking 의 explicit opt-in.
매 typical pitfall
매 host commit 의 update X 의 submodule pointer 의 stale.
매 force-push 의 submodule remote 의 host 의 SHA 의 missing — fetch fail.
매 nested submodule 의 --recurse-submodules 의 forget 의 partial checkout.
언제: 매 binary asset 또는 cross-language vendor lib 의 pin 의 specific upstream commit 의 reproducibility 의 require.
언제 X: 매 JS/TS 의 shared package — 매 workspace 의 strictly superior. 매 frequently-edited shared code — 매 subtree 또는 monorepo 의 prefer.
❌ 안티패턴
Submodule 의 active dev: 매 submodule 안 의 daily edit 의 host pointer 의 forever-out-of-date — 매 monorepo 의 promote.
Force-push 의 upstream: 매 host repo 의 referenced SHA 의 lose — 매 fetch fail forever.
git submodule update 의 forget: 매 host pull 후 의 stale submodule 의 confusing diff.
Nested submodule 의 5+ level: 매 cognitive overhead 의 explode — 매 flatten 의 prefer.
Submodule 의 source-of-truth treat: 매 fork 의 publish 의 X 의 host-only patch 의 lose.
🧪 검증 / 중복
Verified (Git docs git-submodule(1), Pro Git Book Ch. 7.11).