git submodule VS git subtree

1. git submodule VS git subtree ?

1.1. Git Submodule

장점:

• 버전 관리의 유연성:
  • 메인 프로젝트는 하위 모듈의 특정 커밋을 참조함으로써, 사용하고자 하는 정확한 코드 버전을 관리할 수 있음
• 저장소의 깔끔함:
  • 메인 저장소의 크기가 커지지 않고, 외부 저장소의 커밋 이력을 메인 저장소에 포함시키지 않음

단점:

• 하위 모듈의 경로 의존성:
  • 하위 모듈을 제거하거나 경로를 변경하는 것이 까다로움
• 프로젝트 의존성 관리:
  • 외부에서 하위 모듈을 업데이트한 후에는, 메인 프로젝트에도 이를 반영해야 하는 추가적인 작업이 필요
    적합한 사용처:
• 외부 라이브러리나 공통 코드를 개별적으로 업데이트하고 관리하고자 할 때
• 프로젝트의 주요 구성 요소가 독립적인 생명주기를 갖는 경우

1.2. Git Subtree

장점:

• 변경사항의 쉬운 병합: 하위 프로젝트의 변경사항을 메인 프로젝트에 병합하거나 반대로 푸시하는 것이 비교적 간단
• 하나의 저장소 내 이력 유지: 외부 저장소의 커밋 이력을, 메인 프로젝트 내에 유지할 수 있어, 관련 내역을 추적하기 쉬움

단점:

• 저장소 크기 증가: 외부 저장소의 모든 커밋 이력이 메인 저장소에 포함될 수 있어, 저장소의 크기가 커질 수 있음
• 이력 복잡성:
  • 외부 코드의 커밋 이력이 메인 저장소에 통합되어 이력이 복잡해질 수 있음
• 분리의 어려움: 일단 병합하면 하위 프로젝트를 분리하는 것이 어렵습니다.

적합한 사용처:

• 메인 프로젝트와 밀접하게 연동되어 자주 업데이트되는 외부 코드나 라이브러리를 관리할 때
• 하위 프로젝트의 독립성보다는 통합된 관리를 선호할 때

결론

• Submodule: 독립성과 특정 버전에 대한 엄격한 제어가 필요할 때 적합
• Subtree: 하위 프로젝트의 변경사항을 자주 메인 프로젝트로 통합해야 할 때 특히 유용

---

2. git submodule 사용법

2.1. Git Submodule의 개념

• 메인 프로젝트는 하위 모듈의 특정 커밋을 참조

2.2. Git Submodule의 사용법

1. 하위 모듈 추가

   git submodule add <repository-url> <path-to-submodule>

   git submodule add https://es.naverlabs.com/h-sb/Grounded-Segment-Anything.git segmentation/grounded_sam/Grounded-Segment-Anything

   • <repository-url>: 하위 모듈로 추가할 저장소의 URL
   • <path-to-submodule>: 로컬 프로젝트 내에서 하위 모듈의 위치할 경로

• 그 결과로, .gitmodules가 생김

[submodule "segmentation/grounded_sam/Grounded-Segment-Anything"]
	path = segmentation/grounded_sam/Grounded-Segment-Anything
	url = https://es.naverlabs.com/h-sb/Grounded-Segment-Anything.git

2. 하위 모듈 초기화 및 업데이트

   • 프로젝트를 클론한 후, 하위 모듈을 사용하기 위해서는 초기화가 필요

   git submodule init
   git submodule update

   • init: .gitmodules 파일의 설정을 로컬 Git 설정에 추가
     • https://velog.io/@jk01019/.gitmodules-란
   • update: 실제 하위 모듈의 내용을 체크아웃

3. 하위 모듈의 변경 사항 가져오기

   • 하위 모듈에 변경이 있다면 다음 명령으로 최신 상태로 업데이트 할 수 있습니다.

   git submodule update --remote

   • --remote 옵션은 하위 모듈의 원격 저장소에서 최신 커밋을 가져와 업데이트

4. 하위 모듈의 특정 커밋 사용

   • 하위 모듈의 특정 커밋이나 브랜치를 체크아웃하여 사용할 수 있습니다.

   cd <path-to-submodule>
   git fetch
   git branch -r
   
   git checkout -b feature/run origin/feature/run
   cd ..
   git add <path-to-submodule>
   git commit -m "Move submodule to specific commit"

2.3. 하위 모듈 사용 시 유의사항

• 하위 모듈의 독립성: 하위 모듈은 독립적인 저장소이므로, 하위 모듈에서 발생한 변경사항은 해당 모듈의 저장소에 직접 커밋해야 합니다.

---

3. git subtree

git subtree는 하위 프로젝트를 메인 Git 저장소에 통합하는 또 다른 방법으로, git submodule과 비교할 때 다른 특성과 장점을 가지고 있습니다. git subtree를 사용하면 외부 저장소의 코드를 메인 저장소에 직접 병합할 수 있으며, 이 과정에서 외부 저장소의 기록도 함께 유지됩니다.

Git Subtree의 개념

• 저장소 통합: git subtree를 사용하면, 외부 저장소의 내용을 메인 저장소에 직접적으로 병합하고, 외부 저장소의 커밋 기록을 유지할 수 있습니다.
• 독립적인 프로젝트 참조: 외부 저장소는 메인 저장소와 독립적으로 존재하며, 필요에 따라 메인 저장소에서 변경사항을 외부 저장소로 다시 푸시할 수도 있습니다.

Git Subtree의 사용법

1. 하위 프로젝트 추가

   git subtree add --prefix=<path-to-subtree> <repository-url> <branch> --squash

   • --prefix=<path-to-subtree>: 로컬 프로젝트 내에서 하위 프로젝트가 위치할 경로입니다.
   • <repository-url>: 하위 프로젝트로 추가할 저장소의 URL입니다.
   • <branch>: 병합하고자 하는 외부 저장소의 브랜치입니다.
   • --squash: 외부 저장소의 커밋 기록을 하나의 커밋으로 압축하여 메인 저장소의 기록을 간소화합니다.

2. 하위 프로젝트로부터 최신 변경사항 가져오기

   git subtree pull --prefix=<path-to-subtree> <repository-url> <branch> --squash

   • 이 명령은 외부 저장소의 최신 변경사항을 메인 프로젝트에 가져옵니다.

3. 하위 프로젝트에 변경사항 푸시하기

   git subtree push --prefix=<path-to-subtree> <repository-url> <branch>

   • 이 명령은 메인 프로젝트에서 진행된 하위 프로젝트의 변경사항을 외부 저장소로 푸시합니다.

Git Subtree 사용 시 유의사항

• 병합 관리: git subtree는 외부 저장소의 변경사항을 메인 저장소에 병합하는 과정에서 복잡성을 증가시킬 수 있습니다. 따라서, 자주 업데이트되는 외부 코드에는 적합하지 않을 수 있습니다.
• 이력 유지: --squash 옵션을 사용하지 않을 경우, 외부 저장소의 모든 커밋 이력이 메인 저장소에 포함되어 저장소의 크기가 커질 수 있습니다.

git subtree는 메인 저장소에 코드를 직접적으로 통합하면서도 외부 저장소와의 연결을 유지하고자 할 때 유용합니다. 이 방법은 git submodule보다는 더 많은 통합을 제공하면서도 필요한 경우에는 외부 저장소와의 독립성을 유지할 수 있게 해줍니다.