깃(Git) 사용법, 처음 쓰는 명령을 순서대로 직접 해 보니

이 글은 git 사용법을 처음 찾는 1인 개발자를 위해 git version 2.54.0으로 저장소 만들기부터 커밋, 브랜치, 합치기, 되돌리기까지 12단계를 한 번씩 실행하고, 그 명령과 출력을 그대로 옮겼습니다. 깃 명령은 12단계 모두 종료 코드 0으로 끝났습니다.

처음 따라 할 순서 한눈에 보기

새 폴더를 하나 만들고 아래 순서대로 실행하면 됩니다. 명령과 실제 출력은 뒤에 이어지는 절에서 단계별로 보여 드립니다.

1. 버전 확인: git --version
2. 저장소 만들기: git init -b main 실행 후 git status로 상태 보기
3. 작성자 정하기: git config user.name, git config user.email(이 저장소에만 적용)
4. 파일을 만들고 짧은 상태 보기: git status --short
5. 스테이지에 올리기: git add
6. 첫 커밋: git commit -m 실행 후 git log --oneline으로 확인
7. 고친 내용을 git diff로 보고 다시 커밋하기
8. 브랜치를 만들면서 옮겨 가기: git switch -c feature
9. 그 브랜치에서 커밋하기
10. main으로 돌아와 합치기: git merge feature
11. 커밋 전 실수 되돌리기: git restore
12. 같은 일을 영어 메시지(LC_ALL=C)로 다시 보기

AI 코딩 도구에 파일 수정을 맡기고 있다면 이 순서를 이렇게 활용할 수 있습니다. 2~6단계로 출발점을 커밋해 두고, 8단계처럼 브랜치를 따로 만들어 그 위에서 작업하게 하는 거죠. 커밋하기 전에는 7단계의 diff로 바뀐 줄을 확인하고, 아직 스테이지에 올리지 않은 추적 파일의 수정이 마음에 들지 않으면 11단계처럼 git restore로 버립니다. 기본 git restore는 스테이지(index)에서 내용을 가져와 작업 폴더를 되돌리는 명령이므로, 브랜치에 이미 쌓은 커밋은 검토한 뒤 10단계처럼 main에 합칠지 따로 판단하는 편이 좋습니다.

도식출처: 직접 실행한 순서

그런데 명령을 외우기 전에 파일이 어디에서 어디로 옮겨 가는지부터 알아 두면 출력이 훨씬 잘 읽힙니다.

함께 읽을 글

• 깃(Git) pull 사용법, 받아오기부터 충돌 해결까지 직접 해 보니
• 깃(git) commit 사용법, 메시지 고치기와 취소·되돌리기까지
• 올라마(Ollama) 로컬 AI 사용법, 맥에서 직접 돌려 보니

작업 폴더, 스테이지, 커밋은 어떤 관계일까요?

Git 공식 책 한국어판 2.2절은 작업 폴더의 파일을 깃이 관리하는 Tracked 파일과 관리하지 않는 Untracked 파일로 나눕니다. 새로 만든 파일은 Untracked 상태이고, 깃은 이 파일을 절대 커밋하지 않습니다. 그래서 git add로 스테이지(Staging Area)에 올려 다음 커밋에 넣겠다고 표시해야 하죠.

커밋하면 스테이지에 올린 내용이 저장소 기록에 남습니다. 그 뒤에 파일을 다시 고치면 Modified 상태가 되고, 다시 스테이지에 올려 커밋하는 순환이 반복됩니다. 책은 add를 프로젝트에 파일을 추가한다기보다 다음 커밋에 추가한다는 뜻으로 받아들이라고 설명합니다.

git status --short의 두 글자 표시도 이 관계를 그대로 보여 줍니다. 왼쪽 칸은 스테이지의 상태, 오른쪽 칸은 작업 폴더의 상태입니다.

이제 실제 출력을 보면서 이 표시가 어떻게 나오는지 확인해 보세요.

저장소를 만들고 작성자를 정하는 방법

먼저 설치된 깃 버전을 확인합니다.

$ git --version
git version 2.54.0

다음으로 빈 폴더인지 확인한 뒤 저장소를 만들고 상태를 봅니다.

$ ls -a && git init -b main && git status
.
..
./.git/ 안의 빈 깃 저장소를 다시 초기화했습니다
현재 브랜치 main

아직 커밋이 없습니다

커밋할 사항 없음 (파일을 만들거나 복사하고 "git add"를 사용하면 추적합니다)

그럼 정말 이미 있던 저장소였을까요? ls -a에는 .과 ..만 있었고, 바로 이어진 상태 보기도 아직 커밋이 없다고 말합니다. 같은 일을 새로 만든 en 폴더에서 영어 메시지로 해 보면 출력이 이렇게 달라집니다. 측정에서는 이 명령을 마지막 12단계에 실행했습니다. 이 명령은 en 폴더로 옮겨 가므로, 지금 순서대로 따라 하는 중이라면 마지막에 실행하는 편이 좋습니다. 먼저 실행했다면 원래 폴더로 돌아온 뒤 작성자 설정과 커밋을 이어 가세요.

$ mkdir en && cd en && LC_ALL=C git init -b main && LC_ALL=C git status
Initialized empty Git repository in ./en/.git/
On branch main

No commits yet

nothing to commit (create/copy files and use "git add" to track)

영어로는 빈 저장소를 만들었다고 나오죠. 한국어 메시지가 왜 '다시 초기화'로 나오는지는 이 측정만으로는 가를 수 없습니다. 헷갈린다면 직접 ls -a로 폴더를 확인하고, LC_ALL=C를 붙여 영어 메시지와 비교해 보세요.

저장소를 만들었으면 커밋에 남을 작성자를 정합니다. 이 실행에서는 --global 없이 이 저장소에만 적용되게 정했습니다.

$ git config user.name "Finn" && git config user.email "lab@solodevnote.com" && git config user.name
Finn

파일을 스테이지에 올리고 첫 커밋하기

파일을 하나 만들고 짧은 상태 보기를 실행하면 ??가 붙습니다. 아직 추적하지 않는 새 파일이라는 뜻입니다.

$ printf '# 메모\n' > README.md && git status --short
?? README.md

git add로 스테이지에 올리면 표시가 A로 바뀝니다.

$ git add README.md && git status --short
A  README.md

이제 커밋하고 기록을 한 줄씩 봅니다.

$ git commit -m "첫 커밋" && git log --oneline
[main (최상위-커밋) 2408d42] 첫 커밋
 1 file changed, 1 insertion(+)
 create mode 100644 README.md
2408d42 첫 커밋

고친 내용은 어떻게 확인할까요?

파일이 바뀌었다는 사실은 상태 보기로 알 수 있습니다. 그런데 어떤 줄이 바뀌었는지는 git diff로 봐야 합니다. 공식 책에 따르면 이 명령은 작업 폴더와 스테이지를 비교해서, 고쳤지만 아직 스테이지에 올리지 않은 내용만 보여 줍니다.

$ printf '두 번째 줄\n' >> README.md && git diff && git commit -am "README 수정" && git log --oneline
diff --git a/README.md b/README.md
index 5adde32..13cc03b 100644
--- a/README.md
+++ b/README.md
@@ -1 +1,2 @@
 # 메모
+두 번째 줄
[main c921fde] README 수정
 1 file changed, 1 insertion(+)
c921fde README 수정
2408d42 첫 커밋

+가 붙은 줄이 새로 들어간 내용입니다. 이 실행에서는 -am으로 커밋해서, 이미 추적 중인 README.md를 따로 git add 하지 않고도 커밋이 만들어졌습니다. AI 도구가 여러 파일을 한꺼번에 고쳤다면 커밋하기 전에 이 diff부터 훑어보는 편이 안전합니다.

브랜치를 만들고 메인에 합치는 방법

브랜치는 main을 건드리지 않고 따로 커밋을 쌓는 갈래입니다. git switch -c는 브랜치를 새로 만들면서 그 브랜치로 옮겨 갑니다.

$ git switch -c feature && git branch
새로 만든 'feature' 브랜치로 전환합니다
* feature
  main

*가 붙은 쪽이 지금 있는 브랜치입니다. 이 상태에서 파일을 추가해 커밋해 보세요.

$ printf '기능 메모\n' > feature.txt && git add feature.txt && git commit -m "기능 추가" && git log --oneline --all --graph
[feature a6cff5a] 기능 추가
 1 file changed, 1 insertion(+)
 create mode 100644 feature.txt
* a6cff5a 기능 추가
* c921fde README 수정
* 2408d42 첫 커밋

이제 main으로 돌아와 feature를 합칩니다.

$ git switch main && git merge feature && git log --oneline --graph
'main' 브랜치로 전환합니다
업데이트 중 c921fde..a6cff5a
Fast-forward
 feature.txt | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 feature.txt
* a6cff5a 기능 추가
* c921fde README 수정
* 2408d42 첫 커밋

출력의 Fast-forward는 무슨 뜻일까요? Git 공식 책의 브랜치와 Merge 기초에 따르면, 합칠 브랜치가 현재 브랜치 이후의 커밋을 가리키고 있으면 깃은 브랜치 포인터를 최신 커밋으로 옮기기만 합니다. 이번에는 feature를 만든 뒤 main에 새 커밋이 없었으니 이 경우에 해당하죠. 반대로 두 브랜치가 각자 커밋을 쌓았다면 공통 조상을 써서 3-way Merge를 하고 별도의 Merge 커밋을 만듭니다.

도식출처: 근거를 바탕으로 코드가 그린 도식

커밋 전 실수를 되돌리는 방법

커밋하지 않은 수정을 버리고 싶을 때는 git restore를 씁니다. 아래는 실수로 한 줄을 넣고 되돌린 기록입니다.

$ printf '실수로 넣은 줄\n' >> README.md && git status --short && git restore README.md && git status --short && echo "되돌린 뒤 바뀐 파일 없음"
 M README.md
되돌린 뒤 바뀐 파일 없음

되돌리기 전에는 M(작업 폴더에서만 고침)이 보였고, 되돌린 뒤에는 바뀐 파일이 하나도 나오지 않습니다. git restore 설명서가 밝히는 동작은 조건에 따라 이렇게 나뉩니다.

• 위치 옵션(--staged, --worktree)을 하나도 주지 않으면 작업 폴더를 복원합니다.
• --staged가 없으면 기본으로 스테이지(index)의 내용에서 가져오고, --staged를 주면 HEAD에서 가져옵니다.
• --source를 주면 그 소스에서 가져옵니다.

이번 실행은 옵션 없이 실행했으니 스테이지의 내용으로 작업 폴더를 덮은 경우입니다. 되돌린 수정을 나중에 다시 찾을 수 있는지는 이 실행에서 확인하지 않았습니다. 그러니 AI 도구가 고친 내용을 버리기 전에는 diff로 정말 지울 내용인지 먼저 보세요.

자주 하는 실수

• git add 뒤에 파일을 또 고치고 바로 커밋하기: 공식 책에 따르면 커밋에는 마지막으로 git add 했을 때의 버전이 들어갑니다. 고쳤다면 다시 스테이지에 올려야 합니다.
• git diff가 비었다고 바뀐 게 없다고 여기기: 이 명령은 스테이지에 올리지 않은 변경만 보여 줍니다. 스테이지에 올린 내용은 git diff --staged로 봅니다.
• 커밋하지 않은 파일을 둔 채 브랜치 옮기기: 그 파일이 옮겨 갈 브랜치와 충돌하면 브랜치를 바꿀 수 없습니다. 옮기기 전에 작업 폴더를 정리해 두세요.
• 빌드 결과나 로그 파일까지 커밋하기: 공식 책은 무시할 파일 패턴을 적은 .gitignore를 처음에 만들어 두면 편리하다고 설명합니다.

따라 한 뒤 확인할 것

• git config user.name이 3단계에서 정한 이름을 출력하는가
• git log --oneline에 커밋 세 개가 위에서부터 최신순으로 보이는가
• 합친 뒤 main에 feature.txt가 들어왔는가
• 되돌린 뒤 git status --short가 아무것도 출력하지 않는가

측정 조건과 한계

이 기록은 맥(darwin arm64) 한 대에서 git version 2.54.0으로 새 임시 폴더 하나를 만들어, 원격 저장소 없이 로컬에서만 한 번씩 실행한 결과입니다. 단계별 시간은 모두 0.1초 이내라 비교하지 않았습니다. 깃 메시지는 맥의 언어 설정에 따라 한국어로 나왔고, 마지막 단계에서만 LC_ALL=C로 영어 메시지를 봤습니다.

원격 저장소에 올리기와 GitHub 연결은 다루지 않았습니다. Merge도 충돌이 없는 Fast-forward 경우만 실행했으니, 충돌 해결은 앞에서 링크한 공식 책의 해당 절을 보세요.