Git 서브모듈은 정확히 커밋을 고정하지만 워크트리와 충돌하고 URL 변경에도 취약함
- Git 워크트리는 서브모듈이 있으면 깨끗한 상태여도
git worktree remove --force가 필요하며,git worktree move는 서브모듈이 든 워크트리를 아예 거부함 - 슈퍼프로젝트의 mode
160000gitlink는 특정 커밋 SHA를 기록하는 락파일 항목이고,.gitmodules의 경로·URL 매핑은 매니페스트이며git submodule update가 설치 역할을 함 - 서브모듈 URL은 최초
git submodule init때.git/config로 복사돼 이후.gitmodules만 고쳐도 기존 클론은 바뀌지 않으며,git submodule sync나url.<base>.insteadOf설정이 필요함 - 일반
git clone뒤 서브모듈 디렉터리는 비어 있고git submodule update --init또는--recurse-submodules가 필요하며, 기본값인submodule.recurse는 꺼져 있음 - 슈퍼프로젝트에서 브랜치를 바꾸면 서브모듈 작업 트리는 기존 커밋에 남아 수정 상태로 표시될 수 있고, Rust는 이 문제 때문에 빌드 도구에 각 서브모듈을 맞는 커밋으로 되돌리는 로직을 넣었음
Hacker News opinions
서브모듈을 패키지 관리자로 쓰면 개발 경험이 지금과 같지는 않을 것 같음. 다만 일시적인 문제일 수도 있겠지.
진짜 패키지 관리자로 만들 생각이면 프로젝트를 클론할 때마다 패키지를 중복 저장하지는 말아야 함. 멀쩡한 패키지 관리자처럼 프로젝트 간 저장소를 공유해야 함.
공유가 항상 더 낫다고는 못 보겠음. pip처럼 시스템 전체에 깔면 서로 다른 버전을 쓰려면 venv가 필요하고, 초기 npm도 예전 Python 환경보다는 훨씬 나았음. uv를 써도 가끔은 여전히 어색함.
서브모듈이 꼭 gitfile과 $GIT_DIR/modules/<name> 구조를 써야 하는 건 아님. 20GB짜리면 경로에 직접 clone한 뒤 git submodule add <path>를 쓰는데, 그러면 삭제만 해도 완전히 지워지고 이식성도 더 나음.
나는 git-fetch-file이 더 실용적이라고 봄. .gitmodules와 비슷한 매니페스트로 원하는 파일만 받고, 커밋이나 태그, 최신 버전까지 직접 지정할 수 있음.
Git 저장소를 패키지처럼 바로 쓰는 건 우연히 편한 방식일 뿐임. 소스 저장소는 빌드 뒤 소비용 산출물로 패키징해야 하고, Git 저장소를 경계로 삼으면 한 저장소에서 여러 패키지를 만들거나 여러 저장소를 한 패키지로 묶기 어려워짐.