😶🌫️ Submodule
하위 Git 저장소를 다른 GIt 저장소 내부에 포힘시키는 기능. A프로젝트 안에 B라는 외부 저장소를 독립된 버전 상태로 포함시킬 수 있음.
✅ 장점
- 외부 프로젝트의 최신 버전 쉽게 가져올 수 있음.
- 분리된 버전 관리
❌ 단점
- 사용하기 복잡함. (
clone,pull,push모두 별도 관리 필요) - 협업 시 다른 개발자가 업데이트를 놓치기 쉬움.
😶🌫️ Subtree
Subtree는 외부 저장소의 코드를 내부 디렉토리처럼 포함시켜, 단일 Git 저장소로 통합하여 버전 관리할 수 있게 하는 기능.
외부 저장소의 코드가 메인 저장소에 병합됨.
독립적인 저장소처럼 병합과 분리도 가능. (git subtree add, git subtree pull 등)
✅ 장점
- 별도 명령 없이 그냥 커밋/푸시 가능.
- 서브모듈처럼 업데이트 깜빡할 일이 없음.
-협업이 쉬움.
❌ 단점
- 코드가 실제로 포함되므로 저장소 크기가 커질 수 있음.
- 외부 저장소와의 연동이 다소 번거로움. (일일이
pull,push해야 함)
실제 업무 예제로 보는 차이
❗가정[1]: 당신은 웹 서비스를 개발 중입니다.
❗가정[2]:common-utils은 사내에서 사용하는 라이브러리입니다.
💡 Submodule의 경우
🔸상황: common-utils는 다른 팀에서 별도로 관리하는 오픈소스 같은 라이브러리예요. 이건 계속 독립적으로 버전업이 되며, 여러분 팀은 최신 버전을 참조만 하길 원합니다.
✅ 이렇게 사용:
- 메인 저장소에는
common-utils의 특정 커밋을 포인터로만 저장. - 최신 버전이 필요할 때만
git submodule update로 가져옴. common-utils수정은 하지 않음. (읽기 전용처럼 사용)
-> 🧩 이 방식은 마치 외부 라이브러리를 npm처럼 관리하는 느낌.
"이걸 합쳐보면 npm이라는 것은 Node.js로 만들어진 pakage(module)을 관리해주는 툴이라는 것이 됩니다." 링크 내용 중 中
💡 Subtree의 경우
🔸상황
common-utils는 당신 팀 내부에서 프론트/백엔드 공통으로 사용하는 코드예요. 상황에 따라 직접 수정도 해야 합니다. 그런데 별도 저장소로 관리하고 싶긴 해요.
✅ 이렇게 사용:
common-utils는 별도 Git 저장소로 관리됨.
메인 프로젝트에 통합된 형태로 가져오고(push/pull이 가능) 커밋도 자연스럽게 함께 관리됨.
-> 🧩 이 방식은 “내부 라이브러리 통합 관리 + 외부 백업”에 딱이에요.
| 상황 | Submodule 적합 | Subtree 적합 |
|---|---|---|
| 외부 팀 코드 | ✅ | ❌ |
| 직접 수정 필요 없는 라이브러리 | ✅ | ❌ |
| 내부 팀이 함께 사용하는 코드 | ❌ | ✅ |
| 커밋/버전 관리를 함께 하고 싶을 때 | ❌ | ✅ |
| git 관리에 익숙한 팀 | ✅ | ✅ |
마무리
팀 규모에서 작업할 때 유용할 것 같다.
특히 사내에서 사용하는 라이브러리나 tool이 있을 때 유용할 것 같다.
- B팀에서 A팀에서 만든 라이브러리를 사용할 때는, Submodule를 사용.
- B팀 내부에서만 사용하는 라이브러리를 관리할 때는, Subtree를 사용.
필자에게 적용해 보자면, 매 프로젝트마다 비슷한 패턴을 사용할 때가 많은데, 이를 이런 식으로 관리한다면 초기 세팅을 빠르게 할 수 있을 것 같다.
