
#1에서 Git Branch와 Worktree 개념을 정리했다. 나뭇가지와 작업대 비유로.
그때는 "이런 게 있다" 수준이었다. 이번엔 실전. Git 명령어 없이 Claude한테 맡기는 법.
솔직히 말하면, 나는 Git 명령어를 거의 외우지 않았다. git add, git commit, git push 정도? 그것도 매번 검색해서 쳤다.
브랜치 만들기, 머지, 충돌 해결? 이런 건 두려움의 영역이었다. "잘못 치면 다 날아가는 거 아냐?"
Claude Code를 쓰면서 이게 바뀌었다. Git 명령어를 몰라도 Git을 쓸 수 있게 됐다.
코드를 수정한 후에 이렇게만 하면 된다:
> 지금까지 변경한 내용으로 커밋 메시지 써줘
Claude가 실제 변경사항을 분석해서 메시지를 만든다:
docs(level-3): MCP 서버 연결 챕터 작성
- 3가지 전송 방식(HTTP, SSE, stdio) 설명 추가
- 인기 서버 예시(GitHub, Sentry, PostgreSQL) 포함
- 보안 고려사항 섹션 추가
내가 직접 쓰면 "파일 수정함" 정도가 될 걸, Claude는 뭘 왜 바꿨는지를 정리해준다.
> 뉴스레터 기능 추가할 건데, 브랜치 만들어줘
Claude가 git checkout -b feature/newsletter를 실행한다. 이름도 적절하게 지어준다.
작업 끝나면:
> main 브랜치로 돌아가서 합쳐줘
머지까지 해준다. 충돌이 나면 어떻게 해결할지도 제안한다.
> 지난주에 뭘 바꿨는지 요약해줘
> 이 파일이 왜 이렇게 돼 있는지 히스토리 보고 설명해줘
Claude가 git log, git blame 등을 분석해서 알려준다. 명령어를 몰라도 히스토리를 읽을 수 있다.
위에서 소개한 기능을 조합하면 이런 흐름이 가능하다:
1. 작업 시작
> 새 브랜치 만들어줘 — 이번에 할 건 OOO야
2. 작업 중
Claude가 파일을 수정한다
(체크포인트가 자동으로 쌓인다 — #9 참고)
3. 작업 끝
> 커밋해줘
Claude가 변경사항을 보고 메시지를 제안한다
확인하면 커밋 완료
4. 반영
> main에 합쳐줘
이 흐름에서 직접 치는 Git 명령어는 0개다.
사실 나는 커밋은 IDE의 Source Control 패널로 하고 있다. 변경된 파일 목록이 보이고, 메시지 쓰고 버튼 누르면 끝이라서 직관적이다.
반면 브랜치 만들기, 히스토리 조회, 충돌 해결 같은 건 Claude한테 맡긴다. 명령어를 외울 필요 없이 말로 시키면 되니까.
Git의 모든 걸 Claude한테 맡길 수도 있고, 일부만 맡기고 나머지는 IDE 기능을 쓸 수도 있다. 자기한테 편한 조합을 찾으면 된다.
Claude한테 맡기더라도, 최소한 이건 알아야 한다:
개념을 모르면 Claude의 제안을 이해할 수 없다. "main에 머지할까요?"라는 질문에 답하려면, 머지가 뭔지는 알아야 한다.
#1에서 정리한 나뭇가지 비유가 여기서 살아난다.
CLAUDE.md에 이런 식으로 적어두면 된다:
## 커밋 메시지 규칙
- Conventional Commits 형식: type(scope): description
- type: docs, feat, fix, design
- 한국어로 작성
이걸 적어두면 Claude가 매번 이 형식을 따른다. 별도로 말 안 해도 된다. #2에서 다룬 CLAUDE.md의 힘이다.
| 작업 | Git 명령어 직접 | Claude에게 맡기기 |
|---|---|---|
| 커밋 메시지 | 직접 작성 | "커밋해줘" |
| 브랜치 생성 | git checkout -b | "브랜치 만들어줘" |
| 히스토리 조회 | git log --oneline | "뭐 바뀌었는지 알려줘" |
| 충돌 해결 | 수동으로 마커 편집 | "충돌 해결해줘" |
Git 명령어를 외워야 코딩할 수 있다는 건 옛날 이야기다. 개념만 알면 Claude가 실행해준다.
Git의 진입장벽은 명령어였다. 개념만 알면 나머지는 Claude가 해준다.
이 글은 Claude Code 플레이북을 만들면서 배운 것을 비개발자 시점으로 정리한 시리즈입니다.