Git을 공부하면서 처음에는 명령어를 외우는 데 집중했는데,
명령어보다 먼저 이해해야 하는 것은 Git이 파일을 어떤 방식으로 관리하는지였다.
이번 글에서는 커밋과 레포지토리의 개념부터 git add, git commit, git push, git reset까지 공부한 내용을 한 번에 정리해봤다.
커밋과 레포지토리
커밋(Commit)
커밋은 프로젝트의 변경 사항을 하나의 기록으로 저장하는 작업 또는 그 결과물을 말한다.
언제 어떤 내용을 수정했는지 이력을 남길 수 있어서 이전 상태로 돌아가거나 변경 내용을 추적할 때 사용한다.
커밋에는 다음과 같은 정보가 포함된다.
- 커밋을 작성한 사용자
- 커밋한 날짜와 시간
- 변경된 파일과 내용
- 커밋 메시지
사용자와 날짜는 Git이 자동으로 기록하지만, 커밋 메시지는 직접 작성해야 한다.
레포지토리(Repository)
레포지토리는 프로젝트 파일과 Git의 변경 이력을 저장하는 공간이다.
코드뿐만 아니라 커밋, 브랜치, 태그 등 프로젝트의 버전 관리 정보가 함께 보관된다.
로컬 프로젝트에서 git init을 실행하면 숨김 폴더인 .git이 생성되는데, 이 폴더에 Git의 버전 관리 정보가 저장된다.
자주 사용하는 터미널 명령어
pwd # 현재 위치 확인
ls # 파일 목록 확인
ls -al # 숨김 파일까지 확인
mkdir 폴더명 # 폴더 생성
cd 폴더명 # 해당 폴더로 이동
cd .. # 상위 폴더로 이동
cd ~ # 홈 디렉터리로 이동
touch 파일명 # 파일 생성
cat 파일명 # 파일 내용 확인
clear # 터미널 화면 정리자주 사용하는 Git 명령어
git init # Git 저장소 생성
git status # 현재 파일 상태 확인
git add 파일명 # 특정 파일을 Staging Area에 추가
git add . # 모든 변경 사항 추가
git commit -m "메시지" # 커밋 생성
git log # 커밋 기록 확인
git log --oneline # 커밋 기록을 한 줄로 확인
git diff # 변경 내용 확인
git diff --staged # 커밋 예정인 변경 내용 확인
git restore 파일명 # 커밋하지 않은 수정 내용 취소
git restore --staged 파일명 # git add 취소
git rm 파일명 # Git에서 파일 삭제
git mv 기존이름 새이름 # 파일 이름 변경GitHub와 함께 사용하는 명령어
git remote -v # 연결된 원격 저장소 확인
git push # 원격 저장소에 업로드
git pull # 원격 저장소의 변경 내용 가져오기
git clone 저장소주소 # 원격 저장소 복제처음 커밋하기 전에 설정할 내용
Git으로 처음 커밋하기 전에는 커밋 작성자의 이름과 이메일을 설정해야 한다.
git config --global user.name "이름"
git config --global user.email "이메일"설정된 내용은 다음 명령어로 확인할 수 있다.
git config --global user.name
git config --global user.email커밋은 다음 순서로 진행한다.
git add 파일명
git commit -m "커밋 메시지"전체 변경 사항을 한 번에 추가하려면 다음과 같이 입력한다.
git add .
git commit -m "커밋 메시지"Git은 git add로 커밋할 대상을 선택한 뒤, git commit으로 변경 이력을 저장하는 방식으로 동작한다.
Git의 3가지 작업 영역
Git은 크게 세 가지 작업 영역을 기준으로 파일을 관리한다.
1. Working Directory
내가 실제로 파일을 생성하거나 수정하는 작업 공간이다.
아직 커밋할 대상으로 선택하지 않은 변경 사항도 Working Directory에 존재한다.
2. Staging Area
git add로 커밋할 파일을 올려두는 공간이다.
커밋을 실행하면 Working Directory의 모든 파일이 아니라, Staging Area에 올라온 내용만 커밋된다.
3. Repository
git commit을 통해 변경 이력이 저장되는 공간이다.
커밋을 할 때마다 Staging Area의 상태가 하나의 버전으로 기록된다.
작업 흐름을 정리하면 다음과 같다.
Working Directory
│
git add
▼
Staging Area
│
git commit
▼
RepositoryStaging Area가 필요한 이유
Working Directory에서 여러 파일을 수정했다고 해서 모든 변경 사항을 하나의 커밋에 넣어야 하는 것은 아니다.
예를 들어 로그인 기능, 문서 수정, 테스트 중인 코드가 동시에 존재한다면 이번 커밋에 필요한 파일만 골라서 저장할 수 있다.
git add 파일명
git commit -m "로그인 오류 수정"Staging Area가 없다면 작업 중인 파일이나 서로 관련 없는 변경 사항까지 한 번에 커밋될 수 있다.
따라서 Staging Area는 여러 변경 사항 중에서 이번 커밋에 포함할 내용만 선택하기 위한 중간 단계다.
git add 사용법
git add는 변경된 파일을 Staging Area에 올리는 명령어다.
특정 파일 추가
git add <파일명>원하는 파일만 커밋 대상에 포함한다.
디렉터리 추가
git add <디렉터리명>/해당 디렉터리와 하위 파일을 모두 추가한다.
모든 변경 사항 추가
git add .현재 디렉터리 안의 변경 사항을 한 번에 추가한다.
다만 git add .를 습관적으로 사용하면 원하지 않는 파일이 포함될 수 있다. 커밋하기 전에는 git status나 git diff --staged로 내용을 확인하는 것이 좋다.
git status
git diff --stagedGit이 관리하는 파일의 4가지 상태
Git에서 파일은 크게 Untracked와 Tracked 상태로 구분된다.
Tracked 파일은 다시 Modified, Staged, Unmodified 상태로 나뉜다.
| Untracked | Git이 아직 관리하지 않는 파일 |
| Modified | 커밋 이후 수정했지만 아직 git add하지 않은 상태 |
| Staged | 다음 커밋에 포함되도록 선택된 상태 |
| Unmodified | 최신 커밋과 내용이 같은 상태 |
대표적인 상태 변화는 다음과 같다.
새 파일 생성
│
▼
Untracked
│ git add
▼
Staged
│ git commit
▼
Unmodified
│ 파일 수정
▼
Modified
│ git add
▼
Stagedgit status를 실행하면 현재 파일이 어떤 상태인지 확인할 수 있다.
git statusgit push와 git pull
로컬 저장소에서 커밋했다고 해서 GitHub에 자동으로 반영되는 것은 아니다.
로컬과 원격 저장소 사이의 변경 사항을 주고받기 위해 git push와 git pull을 사용한다.
git push
로컬 저장소의 커밋을 원격 저장소에 업로드한다.
git push처음 브랜치를 원격 저장소에 올릴 때는 다음 명령어를 사용할 수 있다.
git push -u origin main-u 옵션을 사용하면 로컬 브랜치와 원격 브랜치의 연결이 설정된다. 이후부터는 git push만 입력해도 같은 브랜치로 업로드된다.
git pull
원격 저장소의 최신 변경 사항을 로컬 저장소로 가져온다.
git pull여러 명이 같은 프로젝트에서 작업한다면 작업을 시작하기 전에 git pull로 최신 내용을 가져오는 것이 좋다.
git push : 로컬 저장소 → 원격 저장소
git pull : 원격 저장소 → 로컬 저장소README.md의 역할
GitHub에서는 프로젝트 루트에 있는 README.md 파일을 기본 소개 문서로 표시한다.
README에는 보통 다음 내용을 작성한다.
- 프로젝트 소개
- 주요 기능
- 설치 방법
- 실행 방법
- 사용 기술
- 폴더 구조
- 참여자 정보
README는 코드를 실행하지 않아도 프로젝트의 목적과 사용법을 파악할 수 있게 해주는 문서다.
커밋 히스토리 확인하기
Git은 지금까지 생성한 커밋을 순서대로 기록한다.
전체 커밋 기록 확인
git log다음 정보를 확인할 수 있다.
- 커밋 ID
- 작성자
- 작성 날짜
- 커밋 메시지
한 줄로 확인
git log --oneline또는 다음 명령어를 사용할 수도 있다.
git log --pretty=oneline--oneline이 더 짧아서 자주 사용한다.
커밋 ID란?
각 커밋에는 고유한 커밋 ID가 부여된다.
커밋 ID는 해시 값으로 구성되어 있으며, 특정 커밋을 조회하거나 비교하고 이전 상태로 이동할 때 사용한다.
전체 커밋 ID를 전부 입력할 필요는 없다. 다른 커밋과 구분된다면 앞부분 몇 자리만 사용해도 된다.
git show 커밋IDgit show와 git diff
git show
특정 커밋에서 어떤 내용이 변경됐는지 확인한다.
git show 커밋ID최근 커밋을 확인할 때는 커밋 ID 없이 입력할 수도 있다.
git showgit diff
두 커밋 사이의 차이를 비교한다.
git diff 이전커밋ID 이후커밋ID출력 결과는 다음과 같이 읽는다.
- 삭제된 내용
+ 추가된 내용정리하면 다음과 같다.
git show : 특정 커밋에서 발생한 변경 내용 확인
git diff : 두 커밋 사이의 차이 비교커밋 메시지 작성 방법
짧은 메시지는 -m 옵션을 사용해 작성한다.
git commit -m "로그인 오류 수정"내용을 자세히 남기고 싶다면 git commit만 입력한다.
git commit기본 텍스트 에디터가 열리면 제목과 본문을 여러 줄로 작성할 수 있다.
로그인 실패 안내 문구 추가
로그인에 실패해도 원인이 표시되지 않는 문제가 있었다.
입력값 오류와 서버 오류를 구분하여 안내하도록 수정했다.Vim에서 커밋 메시지 작성하기
입력 모드로 전환한다.
i메시지를 작성한 뒤 저장하고 종료한다.
Esc
:wq저장하지 않고 종료하려면 다음과 같이 입력한다.
Esc
:q!커밋 메시지 작성 시 알아둘 점
커밋 메시지만 읽어도 어떤 작업을 했는지 알 수 있어야 한다.
좋지 않은 예시는 다음과 같다.
수정
최종 수정
작업 완료
에러 해결변경 대상과 내용을 포함하면 더 이해하기 쉽다.
로그인 실패 시 안내 메시지 추가
중복된 사용자 조회 조건 제거
README에 로컬 실행 방법 추가커밋을 남길 때는 다음 기준을 지키는 것이 좋다.
- 제목과 본문 사이에 한 줄을 비운다.
- 하나의 커밋에는 하나의 작업만 담는다.
- 커밋하기 전에 코드가 정상적으로 실행되는지 확인한다.
- 무엇을 바꿨는지보다 왜 바꿨는지가 필요한 경우 본문에 작성한다.
- 팀이나 회사의 커밋 규칙이 있다면 해당 규칙을 따른다.
최신 커밋 수정하기
가장 최근 커밋의 메시지를 수정하거나 빠뜨린 파일을 추가하려면 --amend 옵션을 사용한다.
커밋 메시지 수정
git commit --amend -m "수정한 커밋 메시지"파일을 빠뜨린 경우
git add 빠뜨린파일
git commit --amend기존 커밋에 파일이 추가된 것처럼 보이지만, 실제로는 새로운 커밋으로 교체된다. 따라서 커밋 ID가 변경된다.
이미 원격 저장소에 올리고 다른 사람과 공유한 커밋이라면 --amend 사용에 주의해야 한다.
Git alias 설정하기
자주 사용하는 긴 명령어에는 별명을 지정할 수 있다.
다음 명령어는 git log --pretty=oneline을 git history로 실행할 수 있게 만든다.
git config alias.history "log --pretty=oneline"이후에는 다음과 같이 입력한다.
git history모든 Git 저장소에서 사용하려면 --global 옵션을 추가한다.
git config --global alias.history "log --pretty=oneline"history는 Git의 기본 명령어가 아니라 사용자가 직접 등록한 alias다.
HEAD란?
HEAD는 현재 작업 중인 브랜치나 커밋의 위치를 나타내는 포인터다.
일반적으로 현재 브랜치의 가장 최근 커밋을 가리킨다.
커밋 A → 커밋 B → 커밋 C
↑
HEAD새로운 커밋을 만들면 HEAD도 새로운 커밋으로 이동한다.
다른 커밋을 체크아웃하거나 reset하면 HEAD가 가리키는 위치도 바뀐다.
git reset이란?
git reset은 현재 브랜치와 HEAD를 지정한 커밋으로 이동하는 명령어다.
옵션에 따라 Staging Area와 Working Directory까지 되돌릴지 결정된다.
git reset [옵션] 커밋ID옵션별 차이
| --soft | 이동 | 유지 | 유지 |
| --mixed | 이동 | 초기화 | 유지 |
| --hard | 이동 | 초기화 | 초기화 |
git reset --soft
커밋만 취소하고 변경 내용은 Staging Area에 남긴다.
git reset --soft HEAD~1방금 만든 커밋을 취소한 뒤 커밋 메시지나 내용을 다시 정리하고 싶을 때 사용할 수 있다.
git reset --mixed
커밋과 git add를 취소하지만 수정한 파일은 Working Directory에 남긴다.
git reset --mixed HEAD~1--mixed는 기본 옵션이기 때문에 생략할 수 있다.
git reset HEAD~1git reset --hard
커밋, Staging Area, Working Directory를 모두 지정한 커밋 상태로 되돌린다.
git reset --hard HEAD~1커밋하지 않은 작업 내용까지 사라질 수 있으므로 가장 주의해서 사용해야 한다.
실행하기 전에는 현재 상태를 확인하는 것이 좋다.
git statusHEAD를 기준으로 이전 커밋 지정하기
git reset을 사용할 때 매번 커밋 ID를 찾지 않고 HEAD를 기준으로 위치를 지정할 수 있다.
git reset --hard HEAD^HEAD^는 현재 커밋의 바로 이전 커밋을 의미한다.
git reset --hard HEAD~2HEAD~2는 현재 커밋에서 두 단계 이전 커밋을 의미한다.
표기 방법은 다음과 같다.
HEAD : 현재 커밋
HEAD^ : 한 단계 이전 커밋
HEAD~1 : 한 단계 이전 커밋
HEAD~2 : 두 단계 이전 커밋
HEAD~3 : 세 단계 이전 커밋restore와 reset의 차이
둘 다 되돌리는 기능이 있지만 대상이 다르다.
git restore : 파일의 수정 내용이나 Staging 상태를 되돌림
git reset : HEAD와 커밋 위치를 이동커밋하지 않은 파일 수정을 취소하려면 다음 명령어를 사용한다.
git restore 파일명git add만 취소하려면 다음 명령어를 사용한다.
git restore --staged 파일명최근 커밋 자체를 되돌리려면 git reset을 사용한다.
Git 태그란?
Git 태그는 특정 커밋에 이름을 붙이는 기능이다.
보통 프로젝트의 주요 버전이나 배포 시점을 표시할 때 사용한다.
v1.0
v1.1
v2.0특정 커밋에 태그 생성
git tag 태그이름 커밋ID현재 커밋에 태그 생성
git tag v1.0태그 목록 확인
git tag태그가 가리키는 커밋 확인
git show 태그이름태그를 사용하면 커밋 ID를 직접 찾지 않아도 중요한 버전의 위치를 쉽게 확인할 수 있다.
전체 흐름 정리
Git의 기본 작업 흐름은 다음과 같다.
파일 생성 및 수정
│
▼
Working Directory
│
git add
▼
Staging Area
│
git commit
▼
Local Repository
│
git push
▼
Remote Repository자주 사용하는 명령어를 순서대로 정리하면 다음과 같다.
git status
git add .
git diff --staged
git commit -m "커밋 메시지"
git push원격 저장소의 최신 내용을 먼저 가져와야 한다면 다음과 같이 진행한다.
git pull
git status
git add .
git commit -m "커밋 메시지"
git push마무리
Git 명령어를 하나씩 따로 외우면 비슷한 명령어가 많아서 헷갈리기 쉽다.
Working Directory → Staging Area → Repository → Remote Repository의 흐름을 먼저 이해하면 add, commit, push의 역할도 자연스럽게 구분된다.
특히 git reset --hard처럼 작업 내용을 삭제할 수 있는 명령어는 결과를 정확히 알고 사용해야 한다. 처음에는 git status와 git diff로 현재 상태를 확인하는 습관을 들이는 것이 중요하다.
출처
- 코드잇 Git 강의
- Git의 3가지 작업 영역
- Git이 보는 파일의 4가지 상태
- git add 더 자세히 알아보기
- 최신 커밋 수정하기
- 두 커밋 간의 차이 보기
- git reset의 3가지 옵션
- HEAD를 기준으로 git reset하기
- 커밋에 tag 달기
'AI & 개발 > 개발' 카테고리의 다른 글
| [Git] HEAD와 reset, checkout, merge 동작 원리 정리 (0) | 2026.07.06 |
|---|---|
| [Git] 브랜치 기본 명령어와 Merge Conflict 해결 방법 정리 (0) | 2026.07.06 |
| [Git] 기본 브랜치가 master에서 main으로 바뀐 이유 (0) | 2026.07.03 |
| [Git] 커밋 메시지 작성법: 좋은 커밋을 만드는 가이드라인 정리 (0) | 2026.07.03 |
| [Markdown] 문법 총정리 | GitHub에서 가장 많이 사용하는 마크다운 문법 (0) | 2026.07.02 |