이 문서에서 해결하는 것: blog-posts에서 작성한 글을 production에 게시하는 방법을 설명합니다.

이 블로그는 저장소를 두 개로 나누어 운영합니다.

blog
 Next.js 블로그 앱 저장소
blog-posts
 MDX 글을 작성하고 보관하는 글 저장소

blog/content-source/posts는 일반 폴더가 아니라 blog-posts 저장소가 연결된 submodule입니다.

즉, 아래 두 위치는 같은 GitHub 저장소인 yunkooo/blog-posts를 가리킵니다.

별도로 clone한 blog-posts
= blog/content-source/posts

그래서 blog/content-source/posts에서 글을 작성하고 커밋하면, 실제로는 blog-posts 저장소에 커밋하는 것입니다.

자동으로 알지 못합니다.

blog-posts 저장소에 새 커밋이 생겨도 blog 저장소는 그 커밋을 자동으로 따라가지 않습니다.

예를 들어 blog-posts가 아래처럼 바뀌었다고 가정합니다.

blog-posts
A 버전 -> B 버전 -> C 버전

그런데 blog 저장소가 아직 B 버전을 가리키고 있다면, production 블로그는 계속 B 버전의 글 목록을 사용합니다.

blog
content-source/posts -> B 버전

blog 저장소가 C 버전을 사용하려면 아래 작업을 해야 합니다.

cd /Users/koo/Desktop/dev/blog
git -C content-source/posts pull --ff-only origin main
git add content-source/posts
git commit -m "Update posts"
git push origin main

이 커밋이 올라가야 blog 저장소가 새 blog-posts 버전을 사용합니다.

blog/content-source/posts는 blog 저장소 안에 있는 것처럼 보이지만, 그 안에서는 별도의 Git 저장소처럼 동작합니다.

이 위치에서 커밋하면:

cd /Users/koo/Desktop/dev/blog/content-source/posts
git add .
git commit -m "Add new post"
git push origin main

이 커밋은 blog가 아니라 blog-posts 저장소에 올라갑니다.

그 다음 부모인 blog 저장소로 돌아와서 확인하면:

cd ../..
git status

아래처럼 보일 수 있습니다.

modified: content-source/posts

이 의미는 글 파일이 blog 저장소에 직접 들어왔다는 뜻이 아닙니다.

정확히는 blog 저장소가 기억하던 blog-posts 버전이 바뀌었다는 뜻입니다.

그래서 부모 blog 저장소에서도 한 번 더 커밋해야 합니다.

git add content-source/posts
git commit -m "Update posts"
git push origin main

완전히 같은 말은 아닙니다.

blog-posts는 글의 전체 이력이 있는 원본 저장소입니다.

blog/content-source/posts는 blog-posts의 특정 버전을 blog 폴더 안에 펼쳐놓은 작업 공간입니다.

blog-posts
 글 저장소 원본
blog/content-source/posts
 blog가 현재 선택한 blog-posts 버전이 펼쳐진 위치

그래서 blog/content-source/posts 안에서는 blog-posts에 커밋하고 push할 수 있습니다. 하지만 부모 blog 저장소에는 content-source/posts가 어떤 버전을 가리키는지도 따로 기록해야 합니다.

아닙니다.

submodule pointer는 최근 글 하나가 아니라 blog-posts 저장소의 특정 버전 전체를 가리킵니다.

예를 들어 blog-posts에 이런 버전들이 있다고 가정합니다.

A 버전: 첫 번째 글 추가
B 버전: 두 번째 글 추가
C 버전: 첫 번째 글 수정
D 버전: 세 번째 글 추가

각 버전은 그 시점의 전체 글 폴더 상태입니다.

D 버전의 글 폴더 상태:
- 첫 번째 글 수정본
- 두 번째 글
- 세 번째 글

blog 저장소의 content-source/posts pointer가 D 버전을 가리키면, production 블로그는 D 버전 시점의 전체 글 목록을 사용합니다.

한 문장으로 정리하면:

submodule pointer는 blog-posts의 특정 글 하나가 아니라,
blog-posts 전체 폴더의 특정 버전을 가리킨다.

blog-posts에 글을 push하는 것만으로는 production에 공개되지 않습니다.

production에 공개되려면 blog 저장소가 새 blog-posts 커밋을 가리키도록 content-source/posts submodule pointer를 커밋하고 push해야 합니다.

1. 글 저장소에 글 커밋/push
 -> GitHub blog-posts에 글 내용이 올라감
2. blog 저장소에 submodule pointer 커밋/push
 -> blog가 사용할 blog-posts 커밋 SHA가 갱신됨
 -> GitHub Actions 배포가 실행됨

가장 덜 헷갈리는 방식입니다. blog 프로젝트 안에서 글 작성부터 배포 트리거까지 이어서 처리합니다.

먼저 글 저장소 위치로 이동합니다.

cd /Users/koo/Desktop/dev/blog/content-source/posts

새 .mdx 글을 작성하거나 기존 글을 수정합니다.

글 저장소인 blog-posts에 커밋하고 push합니다.

git status
git add .
git commit -m "Add new post"
git push origin main

부모 blog 저장소로 돌아옵니다.

cd ../..

blog 저장소에서 submodule pointer 변경을 확인합니다.

git status

정상이라면 아래처럼 보입니다.

modified: content-source/posts

이 표시는 글 파일 전체가 blog 저장소에 복사되었다는 뜻이 아닙니다. blog 저장소가 바라보는 blog-posts 커밋 SHA가 바뀌었다는 뜻입니다.

이제 pointer 변경을 blog 저장소에 커밋하고 push합니다.

git add content-source/posts
git commit -m "Update posts"
git push origin main

blog 저장소의 main에 push되면 GitHub Actions가 실행되고, 성공하면 Vercel production에 반영됩니다.

별도로 clone한 blog-posts 폴더에서 글을 작성해도 됩니다.

cd /path/to/blog-posts

글을 작성하거나 수정한 뒤 blog-posts에 커밋하고 push합니다.

git status
git add .
git commit -m "Add new post"
git push origin main

그 다음 blog 저장소로 이동합니다.

cd /Users/koo/Desktop/dev/blog

blog/content-source/posts submodule이 방금 push한 최신 글 커밋을 가져오도록 업데이트합니다.

git -C content-source/posts pull --ff-only origin main

이제 blog 저장소에서 submodule pointer 변경을 커밋하고 push합니다.

git status
git add content-source/posts
git commit -m "Update posts"
git push origin main

이미 blog-posts에 글을 push했다면, blog 저장소에서 아래 명령만 실행하면 됩니다.

cd /Users/koo/Desktop/dev/blog
git -C content-source/posts pull --ff-only origin main
git status
git add content-source/posts
git commit -m "Update posts"
git push origin main

이 흐름은 blog-posts의 최신 글 커밋을 content-source/posts submodule에 가져온 뒤, blog 저장소가 바라보는 submodule pointer를 갱신해 배포를 트리거합니다.

GitHub에서 아래 경로를 확인합니다.

blog repo -> Actions -> Deploy to Vercel

성공하면 Vercel production에 반영됩니다.

글을 production에 반영하기 전에 blog 저장소 루트에서 아래 명령을 실행합니다.

cd /Users/koo/Desktop/dev/blog
npm run build

자주 확인할 부분:

• frontmatter의 title, description, publishedAt, category, tags가 줄 단위 YAML 형식인지
• draft: true로 남아 있지 않은지
• 코드블록 안에 또 다른 코드블록을 넣어 백틱이 화면에 어색하게 노출되지 않는지

CI는 blog-posts의 최신 main을 자동으로 따라가지 않습니다.

항상 blog 저장소에 커밋된 submodule pointer가 가리키는 글 커밋만 배포합니다.

이 규칙 덕분에 private 저장소에서 초안을 자유롭게 수정해도, 명시적으로 게시하기 전까지 production이 바뀌지 않습니다.