<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>GitHubAPI on Simon의 AI 시대에 살아남는 법</title><link>https://mhub.uk/tags/githubapi/</link><description>Recent content in GitHubAPI on Simon의 AI 시대에 살아남는 법</description><generator>Hugo</generator><language>ko-KR</language><copyright>2026 mhub. 이 블로그의 모든 글·그림과 전자책(그림으로 배우는 시리즈)의 저작권은 mhub에 있으며, 저작권자의 허락 없는 무단 복제·배포·전재를 금지합니다. 이용 허락이나 오류 제보는 문의하기로 보내 주세요.</copyright><lastBuildDate>Sun, 08 Nov 2026 00:15:00 +0900</lastBuildDate><atom:link href="https://mhub.uk/tags/githubapi/index.xml" rel="self" type="application/rss+xml"/><item><title>글 올리기는 GitHub 커밋 한 번 — Git Data API 4단계, 422 재시도, 토큰 권한 진단, 같은 slug 409</title><link>https://mhub.uk/posts/cf-07-publish-is-one-github-commit/</link><pubDate>Sun, 08 Nov 2026 00:15:00 +0900</pubDate><guid>https://mhub.uk/posts/cf-07-publish-is-one-github-commit/</guid><description>&lt;p&gt;폰 시절의 글 올리기 API는 파일을 디스크에 쓰고 Hugo를 다시 돌렸다. 그런데 그 API에는 git 커밋이 없었다. 폰 사이트에는 글이 140개인데 git에는 97~120개 수준으로 늘 뒤처져 있던 이유가 이것이었다. 클라우드로 오면서 &amp;ldquo;글 올리기 = GitHub 커밋&amp;quot;으로 정의를 바꿨다. 커밋이 곧 저장이고, 저장이 곧 배포 트리거다.&lt;/p&gt;
&lt;h2 id="왜-contents-api가-아니라-git-data-api인가"&gt;왜 Contents API가 아니라 Git Data API인가&lt;/h2&gt;
&lt;p&gt;파일 하나만 올린다면 GitHub의 Contents API(&lt;code&gt;PUT /repos/.../contents/경로&lt;/code&gt;)가 가장 쉽다. 하지만 글 하나에는 본문 마크다운과 첨부 이미지 여러 장이 같이 올라간다. 파일마다 커밋을 하나씩 만들면 커밋이 쪼개지고, 그 사이사이에 빌드가 여러 번 돌 수 있다. 그래서 Git Data API로 &lt;strong&gt;한 커밋에 여러 파일&lt;/strong&gt;을 넣었다. 순서는 네 단계다.&lt;/p&gt;</description></item></channel></rss>