Publishing Posts

Publishing Posts

이 문서에서 해결하는 것: 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에 글을 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/content-source/posts에서 바로 작성

가장 덜 헷갈리는 방식입니다. 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에 반영됩니다.

다른 흐름: 별도 blog-posts 폴더에서 작성

별도로 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/content-source/posts에서 작성	글 작성 후 바로 부모 blog repo로 돌아가 pointer 커밋을 만들 수 있음	현재 위치가 blog-posts submodule 안인지 blog 루트인지 확인해야 함
별도 blog-posts에서 작성	글 저장소만 따로 보기 깔끔함	작성 후 blog repo에서 git -C content-source/posts pull --ff-only 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로 남아 있지 않은지
• 코드블록 안에 또 다른 코드블록을 보여줄 때 바깥 fence를 백틱 4개로 썼는지

주의

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

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

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