Git이란 무엇인가? 직접 사용하며 이해한 Git의 핵심 개념

개발을 하다 보면 Git이라는 말을 정말 자주 듣는다. 나 역시 웹앱을 만들면서 Git을 계속 사용해 왔지만, 사실 Git을 제대로 알고 사용했다고 말하기는 어려웠다. AI 코딩 도구가 commit, push 같은 작업을 상당 부분 대신 처리해 주다 보니, Git이 뒤에서 무슨 일을 하는지 굳이 들여다볼 필요가 없었기 때문이다.

그러다 『Git 교과서』를 처음부터 읽으면서 Git Bash를 직접 실행하고, 실제로 사용 중인 프로젝트의 Git 저장소를 하나씩 살펴보기 시작했다. 그 과정에서 Git이 단순히 “소스코드를 GitHub에 올리는 프로그램”이 아니라는 사실이 조금씩 보이기 시작했다.

특히 Working Tree → Staging Area → Commit → Repository라는 구조를 이해하고 나니 그동안 별개의 명령처럼 보이던 git status, git add, git commit 같은 명령들이 하나의 흐름 안에서 연결되기 시작했다.

이 글에서는 지금까지 직접 Git을 만져보며 이해한 내용을, 처음 접하는 사람도 개념을 따라갈 수 있도록 차근차근 정리해 보려고 한다.

1. Git은 무엇인가?

Git은 분산 버전 관리 시스템(Distributed Version Control System)이다. 말이 조금 거창하지만, 초보자의 입장에서는 우선 “프로젝트의 변화 과정을 기록하고 관리해 주는 프로그램”이라고 생각하면 이해하기 쉽다.

예를 들어 어떤 웹페이지를 만들면서 오늘은 로그인 기능을 수정했고, 내일은 검색 기능을 추가했고, 며칠 뒤에는 디자인을 크게 바꿨다고 해보자. 그냥 파일만 저장해 가면서 작업한다면 현재 파일은 남아 있지만, “어제 상태”, “지난주 상태”, “검색 기능을 넣기 직전 상태” 같은 과거 시점은 따로 보관하지 않는 이상 사라져 버린다.

Git은 이런 변화의 순간들을 버전으로 기록해 둔다. 그래서 나중에 어느 시점에 어떤 변경이 있었는지 확인하거나, 필요하다면 과거의 상태로 돌아갈 수 있다.

Git과 GitHub는 같은 것이 아니다

처음 Git을 접하면 Git과 GitHub를 같은 것으로 생각하기 쉽다. 하지만 둘은 분명히 다르다. Git은 내 컴퓨터에서 실행되는 버전 관리 프로그램이고, GitHub는 Git으로 관리하는 저장소를 인터넷상의 원격 서버에 보관하고 공유할 수 있도록 제공하는 서비스다.

따라서 GitHub가 없어도 Git 자체는 사용할 수 있다. 내 컴퓨터 안에서 다음과 같은 작업은 인터넷 연결 없이도 가능하다.

git init
git add
git commit
git log

GitHub는 Git을 더욱 편리하게 협업하고 백업하고 공개하기 위한 서비스이지, Git 그 자체는 아니다.

2. Git은 프로젝트마다 설치하는 프로그램이 아니다

처음에는 이 부분부터 조금 헷갈렸다. “Git을 사용하려면 작업 폴더마다 Git을 설치해야 하는 것일까?”라는 생각이 들었는데 그렇지 않았다.

Git 프로그램 자체는 Windows에 한 번 설치하면 된다. 설치 여부는 다음 명령으로 확인할 수 있다.

git --version

버전 번호가 정상적으로 출력된다면 Git 프로그램은 이미 PC에 설치되어 있다는 뜻이다. 즉 PC 한 대에 Git 프로그램 하나가 설치되어 있고, 여러 프로젝트가 그 Git 프로그램을 공통으로 사용하는 구조다.

내 PC
│
├── Git 프로그램   ← PC에 한 번 설치
│
├── 프로젝트 A
├── 프로젝트 B
└── 프로젝트 C

그렇다면 Git은 어떻게 “이 폴더는 내가 버전 관리해야 할 프로젝트다”라고 구분할까? 그 역할을 하는 것이 바로 각 프로젝트 안의 .git 폴더다.

3. git init과 .git 폴더의 의미

어떤 일반 폴더에서 다음 명령을 실행하면,

git init

그 폴더 안에 숨김 디렉터리인 .git이 만들어진다.

my-project/
│
├── index.html
├── app.js
├── style.css
│
└── .git/

이 .git 폴더가 만들어졌다는 것은 이제부터 Git이 이 폴더를 하나의 저장소(repository)로 관리한다는 뜻이다. 그리고 .git 내부에는 커밋, 브랜치, 객체, 인덱스 등 Git이 프로젝트의 역사를 관리하기 위해 필요한 정보가 들어간다.

프로젝트 폴더의 일반 파일들이 “현재 내가 작업하고 있는 모습”이라면, .git은 그 프로젝트가 어떻게 변화해 왔는지를 기억하는 Git의 장부라고 생각하면 이해하기 쉽다.

그래서 Git 저장소가 아닌 일반 폴더에서 git status를 실행하면 다음과 같은 메시지를 볼 수 있다.

fatal: not a git repository

이 메시지는 Git 프로그램이 설치되지 않았다는 뜻이 아니다. 현재 위치에 .git이 없기 때문에 “여기는 Git 저장소가 아니다”라고 알려주는 것이다.

4. Git Bash는 Git 자체가 아니다

Windows에서 Git을 설치하면 보통 Git Bash도 함께 설치된다. 처음에는 Git과 Git Bash가 거의 같은 것처럼 느껴질 수 있지만, 둘은 역할이 다르다.

즉 Git Bash가 없으면 Git을 못 쓰는 것이 아니다. Windows CMD, PowerShell, VS Code 터미널에서도 Git이 PATH에 정상 등록되어 있다면 git status 같은 명령을 실행할 수 있다.

Git Bash에서는 Windows의 드라이브 경로 표현이 조금 다르다. 예를 들어 Windows에서 C:\site\my-project라면 Git Bash에서는 보통 다음과 같이 표현한다.

cd /c/site/my-project

현재 폴더의 파일을 보려면:

ls

숨김 파일까지 함께 보고 싶다면:

ls -a

Git 도움말을 보다 화면 아래에 (END)라고 나타나는 경우도 있다. 이것은 프로그램이 멈춘 것이 아니라 긴 내용을 한 화면씩 보여주는 pager 화면이다. 이때는 q를 누르면 빠져나올 수 있다.

5. Git의 핵심 구조 — Working Tree, Staging Area, Repository

Git을 공부하면서 가장 중요한 전환점은 이 구조를 이해한 것이었다. Git에서는 내가 파일을 수정했다고 해서 그 변경이 곧바로 하나의 버전으로 기록되는 것이 아니다. 중간에 Staging Area라는 단계가 존재한다.

이 구조를 이해하고 나니 git add와 git commit이 왜 서로 따로 존재하는지도 자연스럽게 이해되기 시작했다.

6. Tracked / Untracked와 Staged / Unstaged는 서로 다른 개념

Git에서 파일의 상태를 설명하는 용어 가운데 초보자가 특히 헷갈리기 쉬운 것이 Tracked/Untracked와 Staged/Unstaged다. 처음에는 네 단어가 비슷하게 느껴지지만 서로 다른 질문에 답하는 개념이다.

구분	무엇을 묻는가?	의미
Untracked	Git이 이 파일을 추적하고 있는가?	Git이 아직 버전 관리 대상으로 알고 있지 않은 파일
Tracked		Git이 이미 버전 관리 대상으로 추적하고 있는 파일
Unstaged	현재 변경분을 다음 Commit에 넣을 것인가?	수정되었지만 다음 Commit 대상으로 아직 선택되지 않은 변경
Staged		다음 Commit에 포함하도록 선택된 변경

예를 들어 이미 여러 번 커밋해 온 a.txt가 있다고 하자. 어제까지 모든 변경을 커밋했다면 현재 상태는 깨끗하다. 그런데 오늘 다시 a.txt를 수정했다.

이때 a.txt 자체는 여전히 Git이 알고 있는 파일이므로 Tracked다. 하지만 오늘 새롭게 수정한 내용은 아직 다음 커밋에 넣겠다고 선택하지 않았으므로 Unstaged 상태다.

어제 Commit 완료
      ↓
a.txt = Tracked
      ↓ 오늘 수정
a.txt = Tracked + Unstaged
      ↓ git add a.txt
a.txt = Tracked + Staged

7. git add의 진짜 의미

처음에는 git add라는 이름 때문에 단순히 “Git에 파일을 추가하는 명령”이라고 생각하기 쉽다. 새 파일을 처음 Git에 등록할 때 실제로 git add를 사용하기 때문에 더욱 그렇게 느껴진다.

하지만 이미 Tracked 상태인 파일을 수정한 뒤에도 다시 git add를 한다. 따라서 Git의 전체 흐름을 이해한 뒤에는 다음 표현이 훨씬 정확하게 느껴진다.

git add = 이 변경사항을 다음 Commit에 포함시키겠다고 선택하는 것

즉 git add는 단순히 파일을 “등록”하는 명령이라기보다, 현재 Working Tree에 있는 특정 상태를 Staging Area에 올려 다음 스냅샷의 후보로 만드는 작업이다.

8. 왜 굳이 Staging Area가 필요한가?

처음에는 이런 의문도 들었다. “어차피 수정한 파일을 커밋할 것이라면 Working Tree에서 바로 Commit하면 되지 않을까?”

그런데 실제 개발에서는 여러 종류의 작업이 동시에 일어난다. 예를 들어 오늘 다섯 개 파일을 수정했다고 해보자.

login.js       로그인 오류 수정
auth.js        로그인 오류 수정

customer.js    고객 검색 기능 추가
search.js      고객 검색 기능 추가

style.css      버튼 디자인 수정

Working Tree에는 다섯 파일의 변경이 모두 함께 존재한다. 하지만 이것을 하나의 Commit으로 묶어야 할 이유는 없다. 오히려 변경의 목적에 따라 나누어 기록하면 나중에 이력을 이해하기 훨씬 쉽다.

git add login.js auth.js
git commit -m "로그인 오류 수정"

git add customer.js search.js
git commit -m "고객 검색 기능 추가"

git add style.css
git commit -m "버튼 디자인 수정"

실제 작업은 한꺼번에 이루어졌지만 Git의 역사에는 “로그인 오류 수정”, “고객 검색 기능 추가”, “버튼 디자인 수정”이라는 세 개의 의미 있는 버전으로 나뉘어 남는다.

그래서 Staging Area는 단순한 임시 대기 공간이라기보다 다음 버전에 무엇을 담을지 선택하고 구성하는 공간이라고 이해하는 편이 좋다.

9. 하나의 파일이 Staged이면서 Unstaged일 수도 있다

조금 더 흥미로운 경우도 있다. a.txt를 수정한 뒤 git add a.txt를 했다고 해보자. 그 시점의 파일 상태가 Staging Area에 올라간다.

그런데 Commit하기 전에 같은 a.txt를 다시 수정하면 어떻게 될까?

Staging Area            Working Tree

A                       A
B                       B
C                       C
                        D

Staging Area에는 A B C까지의 상태가 있고, Working Tree에는 거기에 D가 추가된 더 최신 상태가 존재하게 된다.

따라서 같은 파일이라도 A B C까지는 Staged이고, 그 후 새로 추가한 D는 Unstaged일 수 있다.

이 점을 생각하면 “파일이 Staged다”라는 표현보다 “그 파일의 특정 변경 상태가 Staged되어 있다”고 이해하는 것이 더 정확하다.

10. Commit이 바로 스냅샷을 만드는 작업이다

Git에서 Commit은 단순한 저장 버튼이 아니다. git add를 통해 다음 버전에 들어갈 내용을 준비한 다음, git commit을 실행하는 순간 그 상태가 하나의 확정된 스냅샷으로 Git의 역사에 기록된다.

Working Tree
     ↓ git add
Staging Area
"다음 스냅샷 구성"
     ↓ git commit
Commit
"스냅샷 확정"
     ↓
Repository (.git)

따라서 개념적으로 보면 Staging은 다음 스냅샷의 구성을 준비하는 과정이고, Commit은 그 구성을 실제 하나의 버전으로 확정하는 과정이다.

Ctrl+S와 Commit은 완전히 다르다

그래서 Commit을 단순히 “저장”이라고만 이해하면 Git의 본질을 놓치기 쉽다. 개인적으로는 “Commit = 프로젝트의 버전을 하나 찍는다”라고 생각하는 편이 훨씬 직관적이었다.

11. Git의 스냅샷은 ‘변경분만 저장한다’는 뜻이 아니다

Git의 각 Commit은 논리적으로 그 시점 프로젝트 전체의 스냅샷을 나타낸다. 다만 그렇다고 해서 Commit할 때마다 모든 파일의 내용을 똑같이 복사해서 새로 저장하는 것은 아니다.

두 번째 Commit에서 A만 바뀌었다면 사용자의 관점에서는 프로젝트 전체가 하나의 새 스냅샷이지만, Git 내부에서는 변경되지 않은 B와 C의 동일한 내용을 불필요하게 계속 복제할 필요가 없다. 기존 객체를 다시 참조해 효율적으로 관리한다.

따라서 “Git은 변경사항만 저장하는 시스템”이라고만 말하면 조금 부족하다. 보다 정확하게는 각 Commit은 전체 상태를 나타내는 스냅샷이고, Git 내부에서는 동일한 파일 객체를 효율적으로 재사용한다고 이해하는 것이 좋다.

12. Commit과 Push도 서로 다른 작업이다

commit했다고 해서 GitHub 같은 원격 저장소에 바로 올라가는 것도 아니다. Commit은 우선 내 컴퓨터의 로컬 Git 저장소에 새로운 버전을 만드는 작업이다.

파일 수정
   ↓
Working Tree
   ↓ git add
Staging Area
   ↓ git commit
Local Repository (.git)
   ↓ git push
Remote Repository

즉 add → commit까지는 내 PC 내부의 Git 작업이고, push는 로컬에서 만들어진 Commit들을 원격 저장소로 전송하는 작업이다.

13. .gitignore는 무엇인가?

프로젝트에는 버전 관리할 필요가 없는 파일도 많다. Node.js 프로젝트의 node_modules, 환경설정 파일인 .env, 실행 중 계속 내용이 바뀌는 데이터베이스나 로그, 업로드 파일 등이 대표적이다.

이런 파일이나 폴더를 Git이 추적하지 않도록 규칙을 적어 두는 파일이 .gitignore다.

node_modules/
.env
*.log
uploads/

쉽게 말하면 .gitignore는 “Git 버전 관리에서 제외하고 싶은 파일이나 폴더의 이름 또는 패턴을 적는 규칙표”라고 보면 된다.

*.jpg라고 쓰면 모든 JPG가 무시될까?

.gitignore에 다음과 같이 작성하면,

*.jpg

프로젝트 아래에서 이 패턴에 맞는 JPG 파일은 기본적으로 Git이 무시한다.

project/
│
├── photo.jpg              ← 무시
├── frontend/
│   └── logo.jpg           ← 무시
└── public/
    └── banner.jpg         ← 무시

특정 폴더만 지정할 수도 있고,

uploads/

특정 파일 하나만 지정할 수도 있다.

config.ini

또 !를 사용하면 앞서 무시한 규칙에 예외를 둘 수 있다.

server/uploads/*
!server/uploads/.gitkeep

위 예에서는 server/uploads 안의 파일들을 무시하지만 .gitkeep만은 예외로 둔다. Git은 빈 폴더 자체를 추적하지 않기 때문에, 필요한 폴더 구조를 저장소에 남기려 할 때 이런 방식을 사용하기도 한다.

14. 이미 추적 중인 파일은 .gitignore에 적는다고 자동으로 제외되지 않는다

여기서 중요한 점이 하나 있다. 이미 Git이 과거부터 추적하고 있던 A.jpg가 있다고 해보자. 그 뒤에 .gitignore에 다음 한 줄을 추가했다.

A.jpg

그렇다고 Git이 갑자기 A.jpg를 추적 대상에서 빼는 것은 아니다. 이미 Tracked 상태인 파일이기 때문이다.

실제 파일은 내 PC에 그대로 남겨두면서 Git의 추적에서는 제외하고 싶다면 다음 명령을 사용할 수 있다.

git rm --cached A.jpg

이 명령을 단어별로 나눠 보면 이해하기 쉽다.

git       rm        --cached       A.jpg
│         │             │            │
Git      remove        긴 옵션       대상
프로그램  명령

rm은 remove의 약자다. 그냥 git rm A.jpg라고 하면 Git 관리에서도 제거하면서 Working Tree의 실제 파일도 함께 제거하는 방향으로 동작한다.

반면 --cached 옵션을 붙이면 Working Tree의 실제 파일은 남겨두고, Git의 Index 쪽에서만 해당 파일을 제거할 수 있다.

그 뒤 .gitignore에 A.jpg를 무시하는 규칙이 있다면 앞으로는 해당 파일을 다시 추적하지 않게 된다.

15. --cached의 cached는 ‘임시파일’이라는 뜻일까?

처음 cached라는 단어를 보면 Windows의 임시 캐시 파일 같은 것을 떠올릴 수 있다. “실제 디스크의 원본이 아니라 어딘가에 임시로 저장된 것을 지우는 것인가?”라는 식의 추측이다.

단어의 느낌으로는 완전히 엉뚱한 접근은 아니다. 다만 Git에서는 “잠깐 있다가 사라지는 임시 데이터”라고 이해하기보다는 Working Tree와 별도로 Git이 관리하는 Index 쪽 정보라고 이해하는 편이 정확하다.

Git의 Staging Area는 Index라고도 부르며 실제로 .git/index 형태로 관리된다. 따라서,

git rm --cached A.jpg

는 개념적으로 다음과 같은 뜻에 가깝다.

“Working Tree에 있는 실제 A.jpg는 그대로 두고, Git이 관리하고 있는 Index 쪽에서만 제거해.”

즉 cached라는 단어를 보며 “실제 작업 파일과 별도로 Git이 관리하는 쪽을 대상으로 하는 옵션이구나”라고 생각하고, 그 구체적인 대상이 Index(Staging Area)라고 보정해서 이해하면 된다.

16. Git 설정의 Global과 Local

Git에는 사용자 이름과 이메일 같은 설정도 있다. Global 설정은 해당 사용자 계정에서 기본적으로 사용할 Git 설정이고, Local 설정은 특정 저장소에서만 별도로 적용하는 설정이다.

Global 값을 확인하려면:

git config --global user.name
git config --global user.email

현재 저장소의 Local 값을 확인하려면:

git config --local user.name
git config --local user.email

Local 설정이 따로 없다면 Global 설정이 사용된다. 현재 프로젝트에서 실제로 어떤 값이 적용되는지 보고 싶다면 범위를 지정하지 않고 조회할 수도 있다.

git config user.name
git config user.email

개념적으로는 System → Global → Local 순으로 더 구체적인 설정이 우선한다고 보면 된다.

17. 짧은 옵션과 긴 옵션

Git 명령을 보다 보면 -m처럼 하이픈 하나가 붙기도 하고, --message처럼 하이픈 두 개가 붙기도 한다.

git commit -m "로그인 수정"
git commit --message "로그인 수정"

여기서 -m은 짧은 옵션(short option), --message는 긴 옵션(long option)이다. 이 경우 두 옵션은 같은 기능을 가리킨다.

긴 옵션은 이름만 보고도 의미를 파악하기 쉽고, 짧은 옵션은 자주 사용하는 명령을 빠르게 입력하기 편하다.

다만 모든 짧은 옵션과 긴 옵션이 반드시 단순한 축약 관계인 것은 아니다. 예를 들어 도움말에서 -h와 --help가 서로 다른 수준의 도움말을 보여주는 경우처럼, 각 명령에서 실제로 어떻게 정의되어 있는지를 확인하는 것이 가장 정확하다.

git --version과 git version

두 명령 모두 Git 버전을 보여주지만 구조는 다르다.

git --version
    └─ 옵션

git version
    └─ Git 명령

--version은 Git 프로그램에 전달하는 옵션이고, version은 Git이 제공하는 명령이다. Git이 두 방식을 모두 지원하기 때문에 같은 결과를 볼 수 있다.

18. LF와 CRLF는 왜 Git에서 자주 등장할까?

텍스트 파일의 줄바꿈은 운영체제마다 표현 방식이 다를 수 있다. 대표적으로 Windows는 CRLF, Linux와 macOS는 LF를 사용한다.

Windows       CRLF   \r\n
Linux         LF     \n
macOS         LF     \n

CR은 Carriage Return, LF는 Line Feed의 약자다. 이 이름은 과거 타자기의 동작에서 유래했다. Carriage Return은 타이핑 위치를 왼쪽으로 되돌리는 동작, Line Feed는 종이를 다음 줄로 이동시키는 동작이었다.

사람 눈에는 둘 다 단순한 “줄바꿈”으로 보이지만 파일 내부에 저장되는 문자 표현은 다르다. 그래서 Windows와 Linux가 섞인 개발 환경에서는 실제 내용은 바뀌지 않았는데 줄바꿈 차이 때문에 Git이 변경으로 인식하는 상황이 생길 수 있다.

이런 문제를 관리하기 위해 Git 설정이나 .gitattributes를 사용하기도 한다. 초보 단계에서는 우선 “눈에는 같은 줄바꿈이라도 파일 내부 표현은 다를 수 있다” 정도를 이해하면 충분하다.

19. SourceTree는 Git과 어떤 관계일까?

Git은 반드시 터미널 명령어로만 사용할 필요는 없다. SourceTree 같은 GUI 프로그램을 사용하면 Stage, Commit, Push, Pull 같은 작업을 버튼과 화면으로 조작할 수 있다.

Git Bash
git add
git commit
git push
git pull

        ↕ 같은 Git 기능

SourceTree
Stage 버튼
Commit 버튼
Push 버튼
Pull 버튼

SourceTree가 Git을 대체하는 것은 아니다. Git이라는 버전 관리 시스템을 GUI로 편하게 사용할 수 있도록 만든 관리 도구라고 보면 된다.

그래서 처음 개념을 익힐 때는 Git Bash로 직접 명령을 입력해 보면서 원리를 이해하고, 나중에 필요하다면 GUI 도구를 이용하는 방식도 충분히 가능하다.

20. 결국 지금까지 이해한 Git의 핵심

처음에는 Git을 “코드를 GitHub에 올리는 프로그램” 정도로 생각하기 쉬웠다. 하지만 직접 저장소를 열어보고, .git 폴더를 확인하고, Staging과 Commit의 관계를 하나씩 이해해 보니 Git의 핵심은 조금 다르게 보였다.

Git은 프로젝트의 변화 과정에서 어떤 상태를 하나의 의미 있는 버전으로 기록할 것인지 관리하는 시스템이다. 그리고 그 중심에 Staging과 Commit이 있다.

내가 자유롭게 작업
        ↓
Working Tree
        ↓
이번 버전에 무엇을 넣을까?
        ↓
Staging Area (Index)
        ↓
이 상태를 하나의 버전으로 확정
        ↓
Commit
        ↓
Local Repository (.git)
        ↓
필요하면 git push
        ↓
Remote Repository

결국 지금까지의 내용을 한 문장으로 압축하면 다음과 같다.

Working Tree에서 자유롭게 작업하고 → 이번 버전에 포함할 변경을 Staging Area에서 선택하고 → Commit으로 하나의 스냅샷을 확정하여 → .git 저장소에 프로젝트의 역사로 남긴다.