Git submodule의 장단점을 설명해주세요.

Submodule은 다른 저장소를 특정 커밋으로 포함합니다. 의존 버전을 명확히 고정할 수 있지만 초기화, 업데이트, 동기화 절차가 번거로울 수 있습니다.

핵심 개념

핵심 기준은 외부 저장소의 커밋 고정과 운영 복잡도입니다.

Git submodule은 저장소 안에 다른 저장소를 포함하되 특정 커밋 해시를 기록합니다. 공통 라이브러리 버전을 정확히 고정할 수 있지만 clone 후 초기화, 업데이트, 상위 저장소 포인터 커밋 등 운영 절차가 복잡합니다.

동작 흐름

1. 현재 브랜치의 상태와 변경 범위를 먼저 확인합니다.
2. 명령이 히스토리, 브랜치 포인터, 작업 디렉터리 중 무엇을 바꾸는지 구분합니다.
3. 공유 브랜치에 영향을 주는 작업인지 확인합니다.
4. 실행 후 git status와 git log --oneline --graph로 결과를 검증합니다.

실제 예시

git submodule add https://github.com/org/shared-lib libs/shared
git submodule update --init --recursive

예시는 핵심 흐름을 단순화한 것입니다. 실무에서는 팀의 배포 방식, 데이터 크기, 장애 영향도, 유지보수 비용까지 함께 고려해야 합니다.

실무에서 주의할 점

• 공유된 히스토리를 재작성하면 동료의 로컬 작업과 충돌할 수 있습니다.
• 충돌 해결은 한쪽 선택이 아니라 양쪽 변경 의도를 통합하는 과정입니다.
• 위험한 작업 전에는 임시 브랜치나 태그로 복구 지점을 남기면 안전합니다.

함께 연결해서 보면 좋은 키워드

Git, submodule, dependency, repository

정리

한 줄로 정리하면, Submodule은 다른 저장소를 특정 커밋으로 포함합니다. 의존 버전을 명확히 고정할 수 있지만 초기화, 업데이트, 동기화 절차가 번거로울 수 있습니다. 개념의 정의뿐 아니라 적용 조건과 실패했을 때의 증상까지 함께 이해하는 것이 중요합니다.