이 글에서는 GitHub에 코드를 올리기 전 단계인 로컬 Git 사용법을 먼저 정리한다. 내 PC에서 Git 저장소를 만들고, 파일을 추가하고, 커밋을 남기고, 기록을 확인하고, 실수했을 때 되돌리는 방법까지 다룬다.
GitHub 원격 저장소 연결, push, pull, 협업용 브랜치 관리는 다음 글에서 따로 다룰 예정이다.
목차
1. Git 설치 및 사용자 설정
Git은 파일의 변경 이력을 추적할 때 "누가" 그 변경을 했는지 문서에 도장을 찍듯 반드시 기록한다. 따라서 코드를 저장하기 전에 내 이름과 이메일을 Git에 미리 등록해 주어야 한다. (이때 등록하는 이메일은 웹에서 가입한 GitHub 계정의 이메일과 동일하게 맞추는 것이 나중에 기여도를 확인하는 데 유리하다.)
Windows에서는 Git Bash, PowerShell, 명령 프롬프트 중 하나를 사용하면 된다.
# git 설치 여부 확인
git --version실행 결과 예시는 아래 사진처럼 git version 2.54.0.windows.1 형태로 나타난다.
# 이름 등록
git config --global user.name "나의 영문이름"
# 이메일 등록
git config --global user.email "본인의_이메일@example.com"
# 설정 확인
git config --list여기서 --global은 현재 컴퓨터 사용자 계정 전체에 적용되는 기본 Git 설정이라는 뜻이다. 특정 프로젝트에서만 다른 이름이나 이메일을 쓰고 싶으면 저장소 안에서 --global 없이 설정할 수 있다.
만약 개인 이메일 공개가 부담된다면 GitHub에서 제공하는 noreply 이메일을 사용할 수도 있다.
2. 기본 브랜치 이름을 main으로 맞춰두기
본격적으로 Git 저장소를 만들기 전에, 새 저장소의 기본 브랜치 이름을 main으로 맞춰두면 좋다.
Git에서 브랜치(Branch)는 작업 흐름이 이어지는 하나의 갈래라고 생각하면 된다. 처음 Git을 배우는 단계에서는 너무 어렵게 생각할 필요 없이, main 브랜치를 "내 프로젝트의 기본 작업 줄기" 정도로 이해하면 충분하다.
예전에는 Git 저장소를 처음 만들면 기본 브랜치 이름이 보통 master로 생성되는 경우가 많았다. 그래서 오래된 강의나 예전 프로젝트를 보면 아래처럼 표시되는 경우가 있다.On branch master
하지만 최근에는 GitHub를 비롯한 여러 개발 환경에서 기본 브랜치 이름으로 main을 사용하는 경우가 많다. 따라서 이 글에서도 앞으로의 실습은 main 브랜치를 기준으로 진행한다.
앞으로 새로 만드는 저장소의 기본 브랜치 이름을 main으로 설정하려면 터미널에 아래 명령어를 한 번 입력한다.
git config --global init.defaultBranch main설정이 잘 적용되었는지 확인하려면 아래 명령어를 입력한다.
git config --global init.defaultBranch출력 결과가 아래처럼 나오면 정상이다.main
이 설정을 해두면 앞으로 git init으로 새 저장소를 만들 때 기본 브랜치가 자동으로 main으로 생성된다.
만약 이미 git init을 실행한 뒤라서 현재 브랜치가 master로 만들어졌다면, 아래 명령어로 현재 브랜치 이름을 main으로 바꿀 수 있다.
git branch -m master main물론 master라는 이름을 사용한다고 해서 Git 사용이 틀린 것은 아니다. 브랜치 이름은 프로젝트에서 정하기 나름이다. 다만 처음 Git을 배울 때부터 main 기준으로 연습해두면, 이후 GitHub와 연동할 때 화면과 명령어가 더 자연스럽게 맞아 떨어진다.
3. Git의 3가지 핵심 구역
명령어를 배우기 전에, Git이 작동하는 3가지 핵심 구역을 이해하는 것이 정말 중요하다. 이 개념을 잡으면 앞으로 배울 명령어들이 헷갈리지 않는다.
- 작업 디렉터리 (Working Directory) - "내 책상" 🪑: 현재 파일을 만들고 코드를 수정하는 공간이다. 아직 Git이 변경 사항을 확정 짓지 않은 날것의 상태이다.
- 스테이징 영역 (Staging Area) - "택배 상자" 📦: 책상 위 물건 중 보낼 것만 골라서 택배 상자에 담아두는 대기실이다. 수정한 파일 10개 중 3개만 먼저 기록하고 싶을 때 이 공간을 활용한다.
- 저장소 (Repository) - "창고" 🏢: 스테이징 영역에 담아둔 변경 내용을 하나의 커밋 기록으로 저장하는 공간이다. 이곳에 저장된 기록은 나중에 다시 확인하거나 되돌아볼 수 있다.
결국 우리가 앞으로 할 일은 [책상에서 파일 수정] > [택배 상자에 담기] > [밀봉해서 창고에 넣기]의 반복이다.
4. 새 Git 저장소 만들기
이제 내 컴퓨터에 첫 번째 '창고(저장소)'를 직접 만들어 보자. 바탕화면이나 원하는 위치에 연습용 새 폴더(예: git-practice)를 하나 만든다. 그리고 터미널에서 그 폴더로 이동한 뒤, 빈 폴더를 Git 저장소로 변환하는 아래 명령어를 입력해 본다.
# PowerShell 예시
cd D:\git-practice
# 현재 폴더를 Git 저장소로 만들기
git init5. 새 파일 추가하고 첫 커밋 만들기
- 파일 생성 📝: D:\git-practice 폴더를 열고, 메모장 등을 사용해 hello.txt라는 이름의 텍스트 파일을 하나 만든다. 파일 안에는 "첫 Git 연습"과 같은 간단한 문장을 적고 저장한다.
- 상태 확인 🔍: 다시 터미널 창으로 돌아와서, 현재 Git이 내 책상 위를 어떻게 파악하고 있는지 물어보는 아래 명령어를 입력한다. (앞으로 Git을 쓰면서 가장 자주 치게 될 명령어다.)
git status
명령어를 입력한 후, 출력되는 결과 중에 hello.txt라는 파일 이름이나 "Untracked files"라는 단어가 포함된 메시지가 보이면, 이 파일은 지금 '내 책상(작업 디렉터리)' 위에 막 올려진 상태이다. Git이라는 관리자가 아직 이 파일의 변화를 기록할 준비를 하지 않았다는 뜻이기도 하다.
이제 이 파일을 포장하기 위해 '택배 상자(스테이징 영역)'에 담아볼 차례다. 화면 안내문구 중에 (use "git add …" to include in what will be committed)라는 힌트가 보일 것이다.
터미널에 아래 명령어를 입력해서 hello.txt를 택배 상자에 담아준다.
git add hello.txt
명령어를 입력해도 화면에는 아무런 완료 메시지가 뜨지 않는 것이 정상이다. 상자에 잘 담겼는지 확인하려면 아래 명령어를 입력하면 된다.git status
On branch main
No commits yet
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: hello.txt위와 같이 뜨면 성공이다.
"Changes to be committed" 아래에 hello.txt가 있는 것을 볼 수 있다. 앞서 말한 비유를 쓰자면, 드디어 책상 위에 있던 물건을 택배 상자(스테이징 영역) 📦 안에 안전하게 담아둔 상태다.
이제 상자를 테이프로 밀봉하고, 나중에 알아볼 수 있게 이름표를 붙여 저장소의 커밋 기록으로 남길 차례다.
Git에서는 이 마지막 밀봉 과정을 '커밋(Commit)'이라고 부른다. 커밋을 할 때는 내가 어떤 작업을 했는지 짧은 메모(메시지)를 반드시 같이 남겨야 한다.
터미널에 아래 명령어를 입력해서 첫 번째 커밋을 만들어 보자. (-m은 메시지를 남기겠다는 뜻의 옵션이다.)git commit -m "첫 번째 연습용 파일 추가"
[main (root-commit) ccae480] 첫 번째 연습용 파일 추가
1 file changed, 1 insertion(+)
create mode 100644 hello.txt출력 결과가 의미하는 바를 사실 기반으로 분석해보자.
- main: 현재 작업 중인 기본 갈래(Branch)의 이름이다.
- root-commit: 이 저장소에 기록된 아주 첫 번째 커밋이라는 뜻이다.
- ccae480: 이 커밋에 부여된 고유 식별자(Commit Hash)의 앞 7자리다. 택배 상자의 고유 송장 번호라고 생각하면 된다.
- 1 file changed, 1 insertion(+): 파일 1개가 변경되었고, 1줄의 내용이 추가되었다는 뜻이다.
이로써 hello.txt 파일의 현재 상태가 저장소(창고)에 하나의 커밋 기록으로 남게 되었다.
6. 커밋 기록 확인하기
이제 창고에 어떤 상자들이 보관되어 있는지, 즉 지금까지의 저장 기록(History) 📝을 장부에서 확인해 볼 차례이다. 터미널에 아래 명령어를 입력해보자.
git log출력 결과는 다음과 비슷하게 나타난다.
commit ccae480423f9bd09735d3691e56554be4eba2b1e (HEAD -> main)
Author: example <example@example.com>
Date: Wed Jun 10 14:48:02 2026 +0900
첫 번째 연습용 파일 추가처음 보면 복잡해 보일 수 있지만, 하나씩 나누어 보면 어렵지 않다.
commit ccae480423f9bd09735d3691e56554be4eba2b1e: 이 커밋에 부여된 고유한 식별자이다. 보통 커밋 해시 또는 커밋 ID라고 부른다.(HEAD -> main): 현재 내가 보고 있는 위치가main브랜치의 최신 커밋이라는 뜻이다. 처음에는 현재 작업 위치가 main 브랜치에 있다 정도로 이해하면 충분하다.Author: example <example@example.com>: 이 커밋을 만든 작성자 이름과 이메일이다. 앞에서git config --global user.name,git config --global user.email로 등록했던 이름과 이메일이 여기에 표시된다.Date: Wed Jun 10 14:48:02 2026 +0900: 커밋이 만들어진 날짜와 시간이다.+0900은 한국 시간대처럼 UTC보다 9시간 빠른 시간대를 의미한다.첫 번째 연습용 파일 추가: 커밋을 만들 때git commit -m "첫 번째 연습용 파일 추가"로 입력했던 커밋 메시지이다.
정리하면, git log는 지금까지 만든 커밋 기록을 보여주는 명령어다. 이 기록을 보면 누가, 언제, 어떤 메시지로 커밋을 남겼는지 확인할 수 있다.
다만 git log는 출력 내용이 길다. 커밋이 많아지면 화면을 많이 차지하기 때문에, 간단히 확인하고 싶을 때는 아래 명령어를 자주 사용한다.
git log --oneline출력 결과는 다음과 비슷하게 나타난다.
ccae480 첫 번째 연습용 파일 추가git log --oneline은 커밋 하나를 한 줄로 간단하게 보여준다. 앞에는 커밋 해시의 짧은 버전이 나오고, 뒤에는 커밋 메시지가 표시된다.
즉, 자세히 보고 싶을 때는 git log, 빠르게 커밋 목록만 확인하고 싶을 때는 git log --oneline을 사용하면 된다.
참고로 git log 화면에서 빠져나오지 못하고 멈춘 것처럼 보인다면 키보드에서 q를 누르면 된다.
이제 커밋 기록을 확인하는 방법을 알았으니, 다음으로는 이미 만들어둔 파일을 수정하고 다시 커밋하는 과정을 살펴보자.
7. 기존 파일 수정하고 다시 커밋하기
우리는 방금 '새로운 파일'을 만들어서 창고에 넣었다. 하지만 실제 작업에서는 '이미 만들어둔 파일을 계속 수정'하는 일이 훨씬 많다. 기존 파일을 수정했을 때 Git이 어떻게 반응하는지, 그리고 그 변경 사항을 어떻게 다시 창고에 넣는지 알아보자. 이 과정은 초보자들이 가장 많이 헷갈려 하는 부분이기도 하다.
바로 다음 실습으로 이어가 보자.
- 파일 수정 📝: 아까 만들었던 hello.txt 파일을 메모장으로 다시 연다. 그리고 두 번째 줄에 "두 번째 줄 추가해 보기"라는 문장을 적은 뒤 저장한다.
- 상태 확인 🔍: 다시 터미널 창으로 돌아와서, Git에게 현재 상태를 물어본다.
git status
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: hello.txt
no changes added to commit (use "git add" and/or "git commit -a")위와 같이 출력될 것이다. 화면에 나온 메시지를 처음 파일을 만들었을 때와 비교해 보면 확연한 차이가 있다.
여기서 중요한 부분은 modified: hello.txt와 Changes not staged for commit이다.
- 처음 만들었을 때 (
Untracked): 처음hello.txt를 만들었을 때는 Git이 아직 모르는 새 파일이었기 때문에Untracked files로 표시되었다. - 지금 수정한 상태 (
modified): 하지만 지금은 이미 한 번 커밋된 파일을 수정한 것이기 때문에modified, 즉 수정됨 상태로 표시된다.
다만 아직 이 수정 내용은 스테이징 영역에 올라가지 않았다. 그래서 not staged이 출력된다. 쉽게 말해 책상 위에서 파일을 고치기는 했지만, 아직 택배 상자에 담지는 않은 상태다.
그런데 git status는 어떤 파일이 바뀌었는지는 알려주지만, 파일 안에서 정확히 어떤 내용이 바뀌었는지는 자세히 보여주지 않는다. 이때 사용하는 명령어가 git diff다.
git diff는 아직 택배 상자, 즉 스테이징 영역에 담기지 않은 변경 내용을 보여준다. 다시 말해, 현재 작업 디렉터리에서 수정했지만 아직 git add 하지 않은 내용을 확인하는 명령어다.
예를 들어 hello.txt에 두 번째 줄을 추가했다면, 출력 결과는 다음과 비슷하게 보일 수 있다.
diff --git a/hello.txt b/hello.txt
index 0aea15d..7b1d6dd 100644
--- a/hello.txt
+++ b/hello.txt
@@ -1 +1,2 @@
-첫 Git 연습
\ No newline at end of file
+첫 Git 연습
+두 번째 줄 추가해 보기
\ No newline at end of file여기서 - 기호가 붙은 줄은 이전 버전에서 사라진 줄이고, + 기호가 붙은 줄은 새 버전에서 추가된 줄이다.
이번 예시에서 실제로 새로 작성한 내용은 두 번째 줄 추가해 보기이다. 그런데 첫 Git 연습 줄도 -와 +로 다시 표시되고 있다. 이것은 기존 파일의 마지막 줄 끝에 줄바꿈이 없었기 때문이다.
\ No newline at end of file 문구는 파일의 맨 마지막 줄 끝에서 엔터(Enter)를 치지 않고 저장했을 때 Git이 보여주는 안내 메시지다. 그래서 Git은 기존의 첫 Git 연습 줄을 그대로 유지한 것이 아니라, 줄바꿈 상태가 바뀐 줄로 보고 이전 줄을 제거하고 새 줄을 추가한 것처럼 보여준다.
그래서 나중에 커밋 결과에서 단순히 한 줄을 추가했는데도 2 insertions(+), 1 deletion(-)처럼 보일 수 있다. 이것은 Git이 문서를 줄(Line) 단위로 비교하기 때문에 나타나는 현상이다.
텍스트 파일이나 코드를 작성할 때 맨 마지막 줄 끝에서 엔터(줄바꿈, Newline)를 쳐서 빈 줄로 끝나게 해주는 것이 매우 좋다.
변경 내용을 확인했다면 이제 수정된 내용을 다시 커밋하기 위해 스테이징 영역에 올린다.
git add hello.txtgit add를 실행하면 수정된 hello.txt의 현재 내용이 스테이징 영역에 올라간다.
여기서 바로 커밋해도 되지만, 실제 프로젝트에서는 커밋하기 전에 한 번 더 확인하는 습관이 좋다. 이번에는 작업 디렉터리의 변경 내용이 아니라, 스테이징 영역에 담긴 내용을 확인해야 한다. 이때 사용하는 명령어가 git diff --staged다.
git diff --stagedgit diff --staged는 현재 스테이징 영역에 올라간 변경 내용을 보여준다. 쉽게 말해 이번 커밋에 실제로 들어갈 내용을 미리 확인하는 명령어다.
변경 내용에 문제가 없다면 이제 커밋을 만든다.git commit -m "hello.txt 수정"
출력 결과는 다음과 비슷하게 나타날 수 있다.
[main e974d2e] hello.txt 수정
1 file changed, 2 insertions(+), 1 deletion(-)출력된 결과 중 2 insertions(+), 1 deletion(-) 부분에 대해 사실 기반으로 짧게 설명하면, 단순히 줄만 추가했는데 삭제(deletion)가 발생한 이유는 Git이 문서를 '줄(Line)' 단위로 추적하기 때문이다. 기존 문장 끝에 줄바꿈(Enter)을 추가하거나 띄어쓰기를 변경하면, Git은 기존의 한 줄을 지우고 새로운 내용을 포함한 줄로 대체한 것으로 인식한다.
따라서 파일을 수정하고 커밋할 때의 흐름은 다음과 같이 정리할 수 있다.
git status
git diff
git add hello.txt
git diff --staged
git commit -m "hello.txt 수정"이 습관을 들이면 실수로 원하지 않는 내용을 커밋하는 일을 줄일 수 있다. 특히 실제 프로젝트에서는 파일을 여러 개 수정하는 경우가 많기 때문에, 커밋하기 전에 git diff와 git diff --staged로 내용을 확인하는 습관이 중요하다.
8. 실수했을 때 되돌리기
Git을 처음 사용할 때는 파일을 잘못 수정하거나, 아직 커밋하고 싶지 않은 파일을 실수로 git add 하는 일이 자주 생긴다. 그래서 기본적인 되돌리기 명령어를 알고 있으면 실습하다가 당황하지 않을 수 있다.
먼저 아직 스테이징하지 않은 수정 내용을 버리고 싶을 때는 아래 명령어를 사용한다.
git restore hello.txt이 명령어는 hello.txt 파일을 마지막 커밋 상태로 되돌린다. 즉, 작업 디렉터리에서 수정한 내용이 사라진다. 따라서 실행하기 전에 정말 버려도 되는 수정 내용인지 확인해야 한다.
반대로 파일을 수정한 뒤 이미 git add hello.txt까지 실행했는데, 다시 스테이징 영역에서 내리고 싶을 때는 아래 명령어를 사용한다.
git restore --staged hello.txt이 명령어는 파일의 수정 내용을 지우는 것이 아니라, 스테이징 영역에 올려둔 상태만 취소한다. 쉽게 말해 택배 상자에 넣었던 물건을 다시 책상 위로 꺼내는 것과 비슷하다.
정리하면 다음과 같다.
- 아직
git add하지 않은 수정 내용을 버리고 싶을 때:git restore hello.txt - 이미
git add한 파일을 스테이징 영역에서 내리고 싶을 때:git restore --staged hello.txt
이 두 명령어를 알고 있으면 Git 실습 중 실수했을 때 훨씬 안전하게 되돌릴 수 있다.
9. Git이 무시할 파일 관리하기: .gitignore
실제 프로젝트에서는 Git으로 관리하지 말아야 하는 파일도 있다. 예를 들어 비밀번호나 API 키가 들어간 설정 파일, 자동으로 생성되는 로그 파일, 용량이 큰 의존성 폴더 등은 보통 Git에 올리지 않는다.
이런 파일을 Git이 무시하도록 지정할 때 사용하는 파일이 .gitignore다.
예를 들어 secret.txt라는 파일을 Git이 추적하지 않게 만들고 싶다면, 프로젝트 폴더 안에 .gitignore 파일을 만들고 아래 내용을 적으면 된다.
secret.txt터미널에서 바로 만들고 싶다면 아래처럼 입력할 수도 있다.
echo secret.txt > .gitignore그다음 secret.txt 파일을 만들어도 git status에 추적 대상 파일로 표시되지 않는다.
실제 프로젝트에서 자주 무시하는 파일 예시는 다음과 같다.
.env
*.log
node_modules/여기서 .env는 비밀번호나 API 키 같은 민감한 설정값이 들어가는 경우가 많고, *.log는 로그 파일, node_modules/는 Node.js 프로젝트에서 자동으로 설치되는 의존성 폴더다.
단, 중요한 점이 있다. .gitignore는 아직 Git이 추적하지 않는 파일을 무시하는 용도다. 이미 한 번 Git에 추가되어 커밋된 파일은 .gitignore에 적는다고 자동으로 사라지지 않는다.
따라서 나중에 GitHub에 올릴 가능성이 있는 프로젝트라면, 먼저 .gitignore를 설정하고 git status로 어떤 파일이 추적될 예정인지 확인하는 습관이 좋다.
10. 전체 명령어 요약
이번 글에서는 GitHub에 올리기 전 단계인 로컬 Git 사용법을 정리했다. 핵심은 작업 디렉터리에서 파일을 만들거나 수정하고, 스테이징 영역에 올린 뒤, 커밋으로 저장소에 기록하는 흐름이다.
가장 기본적인 작업 흐름은 다음과 같다.
git status
git diff
git add 파일명
git diff --staged
git commit -m "커밋 메시지"각 명령어의 역할을 다시 정리하면 다음과 같다.
| 상황 | 명령어 | 의미 |
| Git 설치 여부 확인 | git --version | 현재 컴퓨터에 Git이 설치되어 있는지 확인한다. |
| 사용자 이름 설정 | git config --global user.name "나의 영문이름" | 커밋에 기록될 작성자 이름을 설정한다. |
| 사용자 이메일 설정 | git config --global user.email "본인의_이메일@example.com" | 커밋에 기록될 작성자 이메일을 설정한다. |
| Git 설정 확인 | git config --list | 현재 적용된 Git 설정 목록을 확인한다. |
| 기본 브랜치 이름 설정 | git config --global init.defaultBranch main | 새 저장소를 만들 때 기본 브랜치 이름을 main으로 설정한다. |
| 기본 브랜치 설정 확인 | git config --global init.defaultBranch | 기본 브랜치 이름 설정이 잘 적용되었는지 확인한다. |
| 현재 브랜치 이름 변경 | git branch -m master main | 이미 만들어진 master 브랜치 이름을 main으로 바꾼다. |
| Git 저장소 만들기 | git init | 현재 폴더를 Git 저장소로 만든다. |
| 현재 상태 확인 | git status | 어떤 파일이 새로 생겼고, 수정되었고, 스테이징되었는지 확인한다. |
| 파일 스테이징 | git add hello.txt | hello.txt 파일을 스테이징 영역에 올린다. |
| 커밋 만들기 | git commit -m "첫 번째 연습용 파일 추가" | 스테이징된 내용을 하나의 커밋 기록으로 남긴다. |
| 커밋 기록 자세히 보기 | git log | 지금까지 만든 커밋 기록을 자세히 확인한다. |
| 커밋 기록 짧게 보기 | git log --oneline | 커밋 기록을 한 줄씩 간단하게 확인한다. |
| 수정 내용 확인 | git diff | 아직 스테이징하지 않은 변경 내용을 확인한다. |
| 스테이징된 변경 확인 | git diff --staged | 이번 커밋에 실제로 들어갈 내용을 확인한다. |
| 작업 디렉터리 수정 취소 | git restore hello.txt | 아직 스테이징하지 않은 hello.txt 수정 내용을 되돌린다. |
| 스테이징 취소 | git restore --staged hello.txt | 파일 내용은 유지한 채, 스테이징 영역에서만 내린다. |
| 무시할 파일 등록 | .gitignore | Git이 추적하지 않아야 할 파일 목록을 적어둔다. |
| .gitignore 간단 생성 | echo secret.txt > .gitignore | secret.txt를 무시하도록 .gitignore 파일을 만든다. |
정리하면, Git은 단순히 파일을 저장하는 도구가 아니라 언제, 누가, 어떤 변경을 했는지 기록으로 남기는 도구다. 이번 글에서는 PC 안에서 Git 저장소를 만들고 커밋을 관리하는 기본 흐름을 다뤘다.
다음 글에서는 이 로컬 Git 저장소를 GitHub 원격 저장소와 연결하고, push로 업로드하는 방법을 다룰 예정이다.