이전 항목까지를 통해, 로컬 환경의 연습장을 사용하여 commit・push・pull을 한 차례 모두 시도해 보았습니다.

이번에는 그 연습장을 사용하여, AI(Claude Code, GitHub Copilot 등)에게 git 조작을 부탁할 때 주의해야 할 점을 정리합니다.

※ 본 포스팅은 Windows PC에서의 조작을 전제로 합니다.

• git을 사용해 보고 싶지만, 잘 모르겠다

• AI에게 명령어를 물어보지만, 그것이 맞는지 판단할 수 없다

• 단순히 AI와 git의 교제 방법을 알고 싶다

• 원격/로컬의 정리

• git 명령어를 실행할 수 있는 환경을 만들기

• commit+push 해보기

• 별도의 로컬 리포지토리(Local Repository)에서 commit+push 해보기
  AI와 함께 git을 사용할 때 주의해야 할 점(본고)

최근에는 AI에게 git 명령어를 물어보면 즉시 답이 돌아오게 되었습니다.

다만, AI는 "push를 했는지 여부", "지금 어느 브랜치(Branch)에 있는지", "다른 작업자가 있는지"와 같은 그 현장의 상황까지는 완전히 파악할 수 없습니다.

그렇기 때문에 명령어 자체는 틀리지 않았더라도, 상황과 맞지 않아 "잘 모르는 상태가 되어버렸다"라는 이야기를 자주 듣습니다.

①~④에서 만든 연습장은 이러한 명령어를 안전하게 테스트하는 데 그대로 사용할 수 있습니다.

이번에는 "주의해야 할 포인트"를 정리한 후, 실제로 연습장에서 시도해 봅시다.

이번에 파악해 두어야 할 포인트는 크게 다음과 같이 6가지입니다.

• AI의 제안이 어긋나는 이유를 알기
• 위험한 명령어를 알아두기
• push 여부에 따라 대응이 달라짐
• 작업 전후의 3종 세트
• 브랜치를 만든 후에 부탁하기
• 지시력과 검증력

AI는 git status나 git log 등을 스스로 실행할 수 있는 경우, push 여부나 브랜치의 상태는 스스로 확인할 수 있는 경우가 있습니다.

하지만 그럼에도 불구하고 다음 사항은 알 수 없습니다.

• 다른 작업자가 해당 브랜치에 의존한 작업을 하고 있는지
• 팀 내의 운용 규칙 (force push는 금지, main은 직접 건드리지 않는다 등)
• "왜 지금 이 변경을 하고 싶은가"라는 의도 그 자체

즉, "리포지토리의 상태"는 AI가 스스로 확인할 수 있는 경우가 있더라도, 팀의 상황이나 의도까지는 전달하지 않는 한 알 수 없다는 것입니다. 이 전제를 알고 있는 것만으로도 "AI의 제안을 그대로 실행해도 될까"를 한 번 멈춰서 생각할 수 있게 됩니다.

특히 다음 명령어들은 AI가 제안해 왔을 때 실행 전에 한 호흡 쉬어 갑시다.

무엇을 하기 때문에 주의해야 하는가로 정리합니다.

reflog를 사용한 구체적인 복구 절차는 아래 기사에 정리해 두었으니 함께 참고해 주세요.

같은 "커밋을 고치고 싶다" 하더라도, push를 했는지 여부에 따라 취해야 할 수단이 달라집니다.

AI에게 "커밋을 수정해 줘"라고 부탁할 때도, **"아직 push 하지 않았습니다"**라고 한마디 덧붙이는 것만으로 제안의 정밀도가 달라집니다.

git 조작 전후에는 AI에게 부탁하든 아니든, 다음의 3가지 명령어로 상황을 확인하는 습관을 들여 놓으면 안심할 수 있습니다.

$ git status # 변경점·스테이징(Staging) 상황을 확인
$ git branch # 지금 어느 브랜치에 있는지 확인
$ git log --oneline -5 # 최근의 커밋 이력을 확인

특히 AI에게 부탁한 후에는 이것만으로도 "상정과는 다른 변경을 하지 않았는지"를 즉시 알아차릴 수 있습니다.

main 브랜치에 있는 상태로 작업을 의뢰하면, AI의 변경 사항이 그대로 main에 반영되어 버립니다.

연습장이든 실무든, 우선 작업용 브랜치 (branch)를 만든 후 의뢰하는 것을 추천합니다.

$ git branch # 현재 브랜치 확인
* master
$ git switch -c feature/practice # 작업용 브랜치를 만들고 이동
...

마지막으로, AI와 함께 git을 사용할 때 인간 측에 요구되는 능력을 정리합니다.

지시력: 「무엇을 하고 싶은지」를 상황을 포함하여 명확하게 전달하는 능력 (예: "push 완료했습니다", "다른 사람도 작업 중입니다") -
검증력: AI의 답변이 「현재 상황에 맞는지」를 판단하는 능력

이 두 가지는 명령어를 외우는 것보다 더 중요할지도 모릅니다.

①~④에서 만든 local1을 사용하여, git reset --hard로 「실수로 지워버리는」 → 「git reflog로 복구하는」 일련의 흐름을 체험해 봅시다.

$ cd /c/xxxxxx/git-trial/local1 # 로컬 리포지토리 (local repository) ①의 위치로 이동
$ echo "practice" >> sample.txt # 텍스트 파일에 내용 추가
$ git add . # 스테이징 (staging)
...

$ git reset --hard HEAD~1 # 직전 커밋과 함께 변경 사항을 폐기
HEAD is now at xxxxxxx 1st commit
$ git log --oneline -3 # 「practice commit」이 사라졌는지 확인
...

git log에서 「practice commit」이 사라졌습니다. 여기서 당황하지 말고, git reflog를 확인해 봅시다.

$ git reflog # HEAD의 이동 이력 확인
xxxxxxx (HEAD -> master) HEAD@{0}: reset: moving to HEAD~1
yyyyyyy HEAD@{1}: commit: practice commit
...

HEAD@{1}에 방금 지웠던 「practice commit」이 남아 있습니다.

$ git reset --hard yyyyyyy # 지운 커밋의 해시 (hash)를 지정하여 복구
HEAD is now at yyyyyyy practice commit
$ git log --oneline -3 # 「practice commit」이 돌아왔는지 확인
...

연습장이라면 이러한 「되돌릴 수 없는 것 처럼 보이는」 명령어들도 안심하고 결과를 확인할 수 있습니다.

단, git push --force나 git clean -fd는 reflog로도 되돌릴 수 없으므로, 연습장에서 테스트할 때는 특히 주의해서 결과를 확인해 보세요.

AI에게 git 명령어를 부탁하는 것도, 스스로 찾아 입력하는 것도, 명령어의 입수처가 다를 뿐입니다.

어느 경우든 그 제안을 무조건 믿지 말고, 「왜 그 명령어인지」, 「현재 상황에 맞는지」를 검증하는 습관을 들여두면 사고를 크게 줄일 수 있습니다.

①~④에서 만든 연습장은 이를 위한 「안전한 검증의 장」으로도 꼭 활용해 주세요.

끝까지 읽어주셔서 감사합니다!