스낵깃 🍪 : Git Submodule - 여러 레포를 한 프로젝트에서 다루는 법

Git Submodule을 써야 할까? 🤔

한 프로젝트에서 여러 개의 저장소를 함께 관리해야 하는 순간, Git Submodule을 고려하게 되는데요.

하지만 정말 Submodule이 최선일까요? 🤔

독립적인 프로젝트를 유지하면서 특정 버전 상태를 고정해야 한다면 Submodule이 적절할 수 있습니다.

하지만 코드 변경이 잦고, 최신 버전을 자주 반영해야 한다면 Subtree나 패키지 매니저(npm, pip 등)가 더 나을 수도 있습니다.

이제 Git Submodule의 개념과 활용법, 그리고 실제 MSA(Microservices Architecture)에서 어떻게 활용할 수 있는지 알아보겠습니다.

⸻

MSA에서 Git Submodule을 활용하는 방법

✅ Submodule이 적절한 경우

MSA 환경에서는 여러 개의 독립적인 서비스가 협력하여 하나의 시스템을 구성하는데요.
각 서비스가 공통된 코드를 유지하면서도 독립적으로 운영되길 원할 때, Git Submodule이 유용할 수 있습니다.

📌 예제: 공통 유틸리티를 여러 마이크로서비스에서 공유하는 경우

상황

• MSA에서는 여러 개의 마이크로서비스(예: user-service, order-service, payment-service)가 존재합니다.
• 모든 서비스에서 공통된 유틸리티 코드(common-utils)를 사용해야 합니다.
• 각 서비스가 이 공통 유틸리티를 특정 버전으로 유지해야 합니다.

해결 방법

• 각 마이크로서비스에서 공통 유틸리티를 Git Submodule로 추가하면,
  각 서비스는 독립적으로 개발되면서도 특정 버전의 common-utils를 유지할 수 있습니다.

  각 마이크로서비스에서 공통 유틸리티를 서브모듈로 추가

  cd user-service
  git submodule add https://github.com/company/common-utils.git libs/common-utils
  git commit -m "Add common-utils submodule"

  cd ../order-service
  git submodule add https://github.com/company/common-utils.git libs/common-utils
  git commit -m "Add common-utils submodule"

• 이렇게 하면 common-utils는 각 마이크로서비스의 독립적인 폴더로 존재하지만,
  변경이 필요하면 한 번의 업데이트로 모든 서비스에 반영할 수 있습니다.

  • 각 서비스는 특정 버전의 common-utils를 유지하면서 필요할 때만 업데이트할 수 있습니다.

  공통 유틸리티 업데이트 (필요할 때만)

  cd libs/common-utils
  git pull origin main
  cd ../..
  git add .
  git commit -m "Update common-utils to latest version"

⸻

❌ Git Submodule이 적절하지 않은 경우

MSA에서 Git Submodule을 사용하는 것이 비효율적인 경우도 있습니다.

• 공통 코드가 너무 자주 변경되어 모든 서비스에서 항상 최신 버전을 유지해야 할 때
• 공통 모듈이 아니라 단순 라이브러리라면, 패키지 매니저(npm, pip, maven)로 관리하는 것이 더 효율적
• 모든 마이크로서비스가 같은 저장소에 있는 모놀리식(monolithic) 프로젝트일 때

📌 예제: API 요청을 처리하는 공통 라이브러리가 있는 경우

상황

• api-client라는 공통 라이브러리가 있고,
  모든 마이크로서비스(user-service, order-service, payment-service)에서 이 라이브러리를 사용해야 합니다.
• 이 라이브러리는 자주 변경되며, 모든 서비스에서 최신 버전으로 유지해야 합니다.

해결 방법

• 이 경우 api-client를 Git Submodule로 추가하는 것보다,
  패키지 매니저(npm, pip, maven 등)를 활용하는 것이 더 적절합니다.

  패키지 매니저로 공통 라이브러리 관리 (예: npm)

  npm install @company/api-client@latest

  • 이렇게 하면 모든 마이크로서비스에서 최신 버전의 api-client를 자동으로 가져올 수 있어,
    Git Submodule을 사용하는 것보다 훨씬 편리합니다.

⸻

Git Submodule vs Git Subtree vs 패키지 매니저 비교

Git Submodule을 도입하기 전에, 비슷한 기능을 제공하는 다른 방법들과 비교해볼게요.

즉,

• Git Submodule은 독립적인 프로젝트를 포함해야 하지만, 코드 변경이 자주 일어나지 않는 경우 적절합니다.
• 코드 변경이 자주 일어난다면 Git Subtree나 패키지 매니저가 더 유용할 수 있습니다.

⸻

Git Submodule 사용법 요약

Submodule 추가

git submodule add <서브모듈_레포_URL> <서브모듈_디렉토리_경로>
git commit -m "Add submodule"

서브모듈이 포함된 프로젝트를 클론할 때

git clone --recurse-submodules <레포_URL>

or

git submodule update --init --recursive

서브모듈 업데이트

git submodule update --remote

서브모듈 삭제

git submodule deinit -f <서브모듈_디렉토리>
rm -rf .git/modules/<서브모듈_디렉토리>
git rm -f <서브모듈_디렉토리>
git commit -m "Remove submodule"

⸻

📌 결론: Git Submodule을 써야 할까?

Git Submodule을 쓰기 좋은 경우🤭

• 독립적인 프로젝트를 유지하면서도, 내 프로젝트에 포함해야 할 때
• 특정 외부 라이브러리를 고정된 버전으로 유지해야 할 때
• 변경이 자주 일어나지 않는 서브 프로젝트를 관리할 때

Git Submodule이 비효율적인 경우😵

• 코드 변경이 자주 발생하고, 최신 버전을 계속 유지해야 하는 경우
• 패키지 매니저(npm, pip, maven)로 쉽게 관리할 수 있는 라이브러리인 경우

⸻

Git Submodule, 여러분은 어떻게 생각하시나요?

Git Submodule을 써야 할까요?
아니면 Git Subtree나 패키지 매니저가 더 나을까요?

---

🎁 실수에서 배우는 Git 강의도 있어요!

혹시 Git 충돌, 되돌리기, 협업 브랜치 전략 등
이런 문제들을 실습 중심으로 차근차근 배우고 싶다면,
제가 실무 경험을 바탕으로 만든 강의도 참고해보세요!

• 되돌리는 감각: reflog, reset, revert, 안전한 push
• 협업 루틴: 브랜치 전략, PR 체크리스트, 보호 규칙
• 실습 레포 기반 시나리오 6종으로 직접 몸으로 익히는 흐름

🎬 강의 소개 영상: https://lnkd.in/gMWTUSf3
📌 수강 링크: https://lnkd.in/gVVBhJ4g
💸 오픈 기념 할인 중입니다!

에이전트가 코드는 잘 짜줘도,
버전 관리 습관은 우리가 만들어야 우리가 편해집니다.
이번 기회에 Git과 좀 더 친해져보세요. 🙂