hugo 등 jekyll이 아닌 static site generator를 이용하거나 별도로 개발해서 github pages에 페이지를 배포하는 경우 gh-pages 브랜치나 별도의 디렉토리에 배포하고 배포 path를 연결하여 github pages로 호스팅할 수 있습니다.

다만 이 때 소스코드와 배포된 파일을 별도로 분리해서 관리하고 싶을 때 사용하면 좋은 방법이, subtree를 이용한 배포 방법입니다.

간단하게 git subtree가 어떤 명령이고, 이를 통해서 어떻게 배포할 수 있는지 정리해봅니다.

git subtree

본래 git subtree는 여러 repo를 통합하기 위해 만들어진 명령입니다. 보통 많이 사용하는 git submodule 과 대비되는 개념이며 git submodule이 하나의 repo에 여러 repo를 링크한다면, 반대로 git subtree는 현재 repo를 다른 repo나 브랜치에 추가하는 기능입니다. 그래서 이를 이용해 gh-pages 브랜치에 원하는 디렉토리만 subtree로 내보내면, build로 만들어진 static한 파일들만 넘겨줄 수도 있습니다.

deploy gh-pages branch

자 그럼 subtree를 통해 배포를 한번 해볼까요? 저는 ./public 디렉토리에 static page를 생성했습니다. 그 다음 git subtree를 이용해서 public 디렉토리를 gh-pages 브랜치로 배포합니다. (-prefix로 디렉토리를 명시합니다)

git subtree push --prefix ./public origin gh-pages

이후 gh-pages 브랜치에서 확인해보면 public 디렉토리의 내용이 해당 브랜치의 root(/)로 배포된 것을 확인할 수 있습니다.

why?

사실 git add로 추가하고 commit 후 해당 브랜치에 push해도 됩니다. 다만 이렇게 하면 배포된 브랜치에는 public이라는 디렉토리가 생성되서 배포되고, 브랜치 구성에 따라서 main 브랜치의 내용(소스코드가 되겠죠) 또한 배포될 수 있어서 매번 이런 내용을 신경쓰고 배포하는 것 보단 subtree를 이용해 배포하는 것이 훨씬 쉽습니다.

추가로 저는 엄청나게 많은 파일을 배포했었는데(20만개?), git add로 처리하기엔 os에서 지원하는 최대 인자값 수를 넘어가면 git add 를 하지 못하는 상태가 발생합니다. 예를들면 이렇죠.

git add ./public/*
zsh: argument list too long: grep

제가 예전에도 관련해서 글을 썼었네요.

https://www.hahwul.com/2020/03/30/how-to-solv-argument-list-too-long-grep/

어쩄던 이런 경우 git add를 적절히 나눠서 진행해줘야하는데, find 등으로 돌렸을 떄 엄청나게 느려집니다. 또한 git command 자체가 동시에 처리할 수 없는 명령이라 parallel 로 한번에 여러개를 나눠서 돌려도 충돌이 나서 git add가 진행되지 않습니다.

이럴 때 subtree는 정말 좋은 선택입니다 ;D