-
Notifications
You must be signed in to change notification settings - Fork 0
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 저장소에 새 커밋이 생겨도 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 mainblog 저장소의 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/blogblog/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로 남아 있지 않은지 - 코드블록 안에 또 다른 코드블록을 넣어 백틱이 화면에 어색하게 노출되지 않는지
CI는 blog-posts의 최신 main을 자동으로 따라가지 않습니다.
항상 blog 저장소에 커밋된 submodule pointer가 가리키는 글 커밋만 배포합니다.
이 규칙 덕분에 private 저장소에서 초안을 자유롭게 수정해도, 명시적으로 게시하기 전까지 production이 바뀌지 않습니다.