Git 조작 자동화 — 커밋부터 PR 머지까지

Claude Code의 Git 자동화는 "커밋해줘", "PR 만들어줘" 같은 자연어 지시를 실제 Git·GitHub 명령으로 바꿔 실행하는 기능입니다. 명령어를 외우지 않아도 리포지토리 초기화부터 커밋, 브랜치, 푸시, PR 작성·머지까지 터미널 안에서 끝나기 때문에 개발 템포가 끊기지 않습니다.

디버깅 지원 기능에서 오류를 고친 다음 할 일이 바로 "그 변경을 안전하게 기록하는 것"입니다. 아래에서 그 흐름을 7단계 실습으로 따라갑니다.

핵심 요약

• 자연어 한 줄이면 됩니다: "커밋해줘", "PR 만들어줘"만으로 일련의 Git 조작이 완결됩니다.
• 커밋 메시지는 Claude Code가 변경 내용을 분석해 Conventional Commits 형식으로 자동 제안합니다.
• GitHub CLI(gh)와 연동하면 브라우저를 열지 않고 PR 작성·머지까지 터미널에서 끝납니다.
• push, PR 작성처럼 영향 범위가 큰 원격 조작은 반드시 Yes/No 확인 화면을 거칩니다.
• 퍼미션 설정에서 git push를 ask로 지정하면 의도치 않은 푸시를 막을 수 있습니다.

사전 준비 — 무엇이 설치돼 있어야 하나

실습에는 아래 세 가지가 필요합니다.

GitHub CLI는 Claude Code가 리포지토리 생성·PR 작성·머지 같은 GitHub 조작을 실행하는 데 쓰는 도구입니다. 인증이 안 돼 있으면 푸시 이후 단계가 진행되지 않습니다.

Git 조작이 동작하는 프로젝트 디렉터리라면 어떤 것이든 아래 실습을 그대로 시험할 수 있습니다.

먼저 알아둘 Git 용어 7가지

아래 7단계에서 이 일곱 가지를 전부 한 번씩 체험합니다.

1단계 — 리포지토리 초기화하기

프로젝트 디렉터리에서 Claude Code를 실행합니다.

cd ~/Desktop/your-project
claude

디렉터리를 Git 리포지토리로 만들어 달라고 부탁합니다.

> 이 디렉터리를 Git 리포지토리로 초기화해 주세요

Claude Code가 git init을 실행합니다.

⏺ Bash(git init)
  ⎿  Initialized empty Git repository in /Users/username/Desktop/your-project/.git/

⏺ Git 리포지토리를 초기화했습니다.

Vite 같은 도구로 만든 프로젝트라면 .gitignore(Git이 추적하지 않을 파일 목록)가 이미 들어 있습니다. node_modules(설치한 패키지 실체), dist(빌드 출력), *.log 같은 항목을 제외해 리포지토리를 가볍게 유지합니다.

2단계 — 첫 커밋 만들기

커밋 전에는 스테이징(대상 파일 등록)이 필요하지만, Claude Code에 맡기면 자동으로 처리합니다.

> 현재 코드를 전부 커밋해 주세요.
  커밋 메시지는 한국어로 부탁합니다

⏺ Bash(git add .gitignore README.md src/ ...)
  ⎿  (No output)

⏺ Bash(git commit -m "chore: 프로젝트 초기 셋업")
  ⎿  [main (root-commit) 563656f] chore: 프로젝트 초기 셋업
      11 files changed, 3683 insertions(+)

⏺ 첫 커밋을 만들었습니다.

주목할 점은 커밋 메시지를 Claude Code가 변경 내용을 분석해 자동 생성한다는 것입니다. git commit 실행 전 승인을 요구하면 내용을 확인하고 "Yes"를 고릅니다. 메시지를 바꾸고 싶으면 "No"를 고른 뒤 이렇게 말하면 됩니다.

> 커밋 메시지를 "초기 커밋: 프로젝트 기본 기능 구현"으로 바꿔 주세요

커밋 메시지의 chore: 는 무엇인가

chore: 접두사는 Conventional Commits 관습입니다. feat(기능 추가), fix(버그 수정), docs(문서), chore(환경 구축) 같은 접두사로 변경 종류를 나타냅니다. 매번 "접두사 붙여 줘"라고 말하는 대신 CLAUDE.md에 규칙으로 적어 두면 자동으로 따릅니다.

언제 커밋해야 하나

Claude Code처럼 한 번에 많은 코드를 생성하는 도구를 쓰면 1회 변경량이 커져 커밋 타이밍을 망설이게 됩니다. 두 가지 방침이 있습니다.

1. 부탁할 때마다 커밋 — 처음엔 이 방법이 좋습니다. 기능 하나를 부탁하면 여러 파일이 한꺼번에 바뀌는 일이 흔합니다. 부탁 1회마다 동작을 확인하고 커밋해 두면 문제가 생겨도 직전 상태로 돌아갈 수 있습니다.
2. 기능 단위로 커밋 — 흐름이 익숙해지면 기능 하나가 완성된 시점에 커밋합니다. 이력이 '의미 있는 변경'만으로 구성되어 나중에 따라가기 쉽습니다.

어느 쪽이든 메시지 작성을 Claude Code에 맡기면 커밋의 심리적 부담이 크게 줄어듭니다.

3단계 — 브랜치를 만들어 기능 추가하기

지금까지는 모든 변경이 main 브랜치 한 줄기에 쌓였습니다. main은 프로젝트의 안정된 상태를 지키는 브랜치라서, 개발 중인 불안정한 코드가 섞이면 곤란합니다. 새 브랜치를 만들면 main을 그대로 둔 채 다른 곳에서 개발할 수 있고, 문제가 생기면 브랜치째 버려도 main에는 영향이 없습니다.

README 업데이트로 연습해 봅니다.

> feature/update-readme 라는 브랜치를 만들어 주세요

Claude Code가 git checkout -b feature/update-readme를 실행하고 새 브랜치로 전환합니다. 이어서 README 업데이트를 부탁하고, 끝나면 커밋합니다.

> README.md를 현재 프로젝트 내용에 맞게 업데이트해 주세요.
  앱 개요, 주요 기능, 실행 방법을 적어 주세요

> 변경을 커밋해 주세요

Claude Code가 README를 읽어 고친 뒤 docs: README.md를 프로젝트 내용에 맞게 업데이트 같은 메시지로 커밋합니다. "브랜치 생성 → 작업 → 커밋"이 Git의 기본 개발 사이클입니다.

4단계 — GitHub 리포지토리를 만들어 푸시하기

feature/update-readme 브랜치는 아직 로컬에만 있습니다. GitHub에 올리면 팀과 공유하고 리뷰받을 수 있고, 개인 개발이라도 백업과 이력 가시화에 도움이 됩니다.

리포지토리 생성부터 푸시까지 한 번에 부탁합니다.

> GitHub에 my-app 이라는 이름의 리포지토리를 만들고,
  코드를 푸시해 주세요

공개 범위(Public·Private)를 지정하지 않으면 아래와 같은 선택 화면이 뜰 수 있습니다.

GitHub 리포지토리 공개 설정은 어느 쪽으로 할까요?
❯ 1. Public        누구나 열람 가능
  2. Private       자신만 접근 가능
  3. Type something.

이 화면은 Claude Code의 AskUserQuestion 도구가 띄우는 것입니다. 선택지를 고르거나 "3. Type something."으로 자유롭게 답할 수 있습니다. 여기서는 Public을 고릅니다.

다음으로 gh repo create가 실행됩니다. 원격 조작은 영향 범위가 크므로 확인 화면이 뜹니다. 내용을 보고 "Yes"를 고르세요.

 Bash command
   gh repo create my-app --public --source=. --push
   Create public GitHub repo and push

 Do you want to proceed?
 ❯ 1. Yes
   2. Yes, and don't ask again for: gh repo:*
   3. No

--push 옵션으로 리포지토리 생성과 동시에 현재 브랜치가 푸시됩니다. Claude Code는 main 브랜치도 푸시가 필요하다고 판단해 추가로 실행합니다.

완료 메시지에 리포지토리 URL(https://github.com/your-username/my-app)이 표시되면 브라우저로 열어 확인해 보세요.

의도치 않은 push 막기

퍼미션 설정 최적화에서 다루는 방법으로 git push를 ask(확인 강제)로 지정해 두면, 어떤 상황에서도 push 전에 반드시 확인을 거칩니다.

{
  "permissions": {
    "ask": ["Bash(git push *)"]
  }
}

.claude/settings.json에 넣으면 프로젝트 단위로 적용됩니다.

5단계 — PR 만들기

PR을 만들면 변경의 차분을 한눈에 보고 리뷰를 부탁할 수 있습니다.

> feature/update-readme 브랜치의 PR을 만들어 주세요.
  제목과 설명문도 알기 쉬운 내용으로 채워 주세요

Claude Code가 gh pr create를 실행하면서 제목과 설명문을 자동 생성합니다.

완료되면 https://github.com/your-username/my-app/pull/1 같은 PR URL이 출력됩니다. 열어서 GitHub의 PR 페이지를 확인해 보세요.

6단계 — PR 머지하기

내용에 문제가 없으면 머지해서 main에 통합합니다.

> 만든 PR을 머지해 주세요

Claude Code가 gh pr merge 1 --merge를 실행합니다. 확인 화면에서 PR 번호와 머지 방식을 확인하고 "Yes"를 고르면, GitHub 상의 main 브랜치에 변경이 통합됩니다.

7단계 — 로컬 main 최신화하기

머지는 GitHub(원격)에서 이뤄졌으므로 로컬 main에는 아직 반영되지 않았습니다.

> main 브랜치로 전환하고, 원격 변경을 로컬에 반영해 주세요

Claude Code가 git checkout main && git pull을 실행해 main으로 전환하고 원격의 머지된 변경을 가져옵니다. 브랜치 생성부터 PR 머지, 로컬 최신화까지 Git 워크플로 한 바퀴가 끝났습니다.

한눈에 보는 지시어 표

정리

• 커밋 메시지 생성을 Claude Code에 맡기면 쓰는 수고가 사라지고, 규칙은 CLAUDE.md에 한 번만 적으면 됩니다.
• 브랜치를 끊어 PR을 만드는 흐름은 개인 개발에서도 습관화해 두면 안전합니다.
• push나 PR 작성처럼 원격에 영향을 주는 조작은 확인 화면에서 반드시 내용을 읽고 승인합니다.
• 먼저 손안의 프로젝트에서 "커밋해줘"라고 한마디 건네 보세요.

입문 코스의 다음 글은 바이브 코딩이란 무엇인가 — 정의와 한계입니다.