[Git] Git 서브모듈 활용하기
서브모듈 사용하는 이유
깃 저장소 내에서 다른 레포지토리를 클론 후 스테이지에 올리면
$git add .
warning: adding embedded git repository: gnlTester
hint: You've added another git repository inside your current repository.
hint: Clones of the outer repository will not contain the contents of
hint: the embedded repository and will not know how to obtain it.
hint: If you meant to add a submodule, use:
hint:
hint: git submodule add <url> gnlTester
hint:
hint: If you added this path by mistake, you can remove it from the
hint: index with:
hint:
hint: git rm --cached gnlTester
hint:
hint: See "git help submodule" for more information.
이와 같은 내용이 표시된다.
깃 저장소 내에서 다른 깃 저장소를 불러오려면 깃의 서브모듈을 활용해서 사용하는 것이 좋다.
깃의 서브모듈을 활용한다면 Hugo에서는 테마관리를 쉽게 할 수 있으며, 한 프로젝트에서 다른 깃 저장소를 활용할 때에도 .gitmodules 파일을 통해 더 명확하게 이용할 수 있다.
공유된 라이브러리를 활용할 때에 유용하다(주소가 public하지 않을 경우 사용 불가!)
서브모듈로 변경
위에 나와 있듯이 우선 gnlTester 디렉토리를 제거 후 gnlTester의 경로를 git에서 또한 제거해준다.
제거 후 서브모듈을 활용해 추가해준다.
rm -rf gnlTester
git rm --cached gnlTester
git submodule add https://github.com/Tripouille/gnlTester.git
이렇게 추가하면 자동으로 클론되는데
git status
파일목록을 확인ㅎ해 보면 .gitmodules라는 파일과 gnlTester라는 디렉토리가 생성된 것을 확인할 수 있다.
.gitmodules는 .gitignore파일처럼 깃의 모듈에 대한 정보를 담고 있다.
현재 저장소에서는
[submodule "gnlTester"]
path = gnlTester
url = https://github.com/Tripouille/gnlTester.git
이렇게 저장소 내의 경로와 서브모듈의 저장소 주소를 담고 있다.
서브모듈 불러오기
처음에 add로 추가할 경우에는 자동으로 내용을 가져오지만 메인 프로젝트를 클론할 경우에는 gnlTester라는 디렉토리는 빈 디렉토리로 클론된다.
내용을 불러오려면
git submodule init
git submodule update
를 입력하여 파일들을 불러올 수 있다. 혹은
git clone --recurse-submodules 메인프로젝트
메인 저장소를 클론할 때 이 옵션으로 클론하면 자동으로 서브모듈을 초기화한 후 업데이트 해준다.
서브모듈의 내용
서브모듈 디렉토리 안의 내용은 메인 프로젝트의 깃이 아예 추적하지 않는다.
cd gnlTester/
echo 123 > a.txt
cd ..
git add .
git status
이렇게 확인해보면 서브모듈 내의 수정된 내용은 아예 메인 프로젝트의 스테이지에 올라오지 않는다.
서브모듈 디렉토리로 들어가서 확인을 하면
$cd gnlTester/
$git status
HEAD detached at 2e28a6c
Untracked files:
파일 목록
이런 식으로 나온다.
서브모듈은 업데이트할 경우 기본적으로 아무런 브랜치와 연결되어 있지 않기 때문에 수정하거나 git를 이용할 때에는 브랜치를 변경해주어야 한다.
git checkout master
서브모듈 내에서 수정을 한 후에 커밋을 하여 기록을 남겨 놓았는데 만약 서브모듈에서 픽스가 이루어졌다든가 하는 이유로 새롭게 내용을 가져와야할 수도 있다.
이 때 만약 앞서 한대로 git submodule update를 한다면 기존의 작업내용이 날아가고 새롭게 들어오는 커밋으로 내용이 향한 다음 다시 detached HEAD 상태가 될 수 있다.
따라서 수정한 상태에서 새롭게 불러올 때에는
git submodule update --remote --rebase
git submodule update --remote --merge
rebase인지 merge인지 방식을 정한 후에 옵션을 부여하면 된다.