CS/Git

[GIT] GIT을 통해 버젼관리를 하는 방법 (2026 개정판)

Joonfluence 2026. 2. 27.

📋 주요 변경사항

항목	2022년	2026년 개정
기본 브랜치명	`master`	`main` (2020년 GitHub 기본값 변경)
브랜치 전환	`git checkout`	`git switch` / `git restore` (Git 2.23+)
Unstage 방법	`git reset HEAD [file]`	`git restore --staged [file]`
인증 방식	HTTPS 비밀번호	PAT(Personal Access Token) 또는 SSH 키
최신 Git 버전	2.38	2.51 (2025년 기준)

1. 버전관리의 구조: Git의 세 가지 영역

Git의 Local Repository는 세 가지 영역(Three Trees) 으로 구성됩니다.

Working Directory  →  Staging Area (Index)  →  Repository (HEAD)
    (작업 공간)        (git add 한 파일들)       (git commit 된 스냅샷)

Working Directory는 실제 파일을 편집하는 작업 공간입니다. Git이 추적 중인 파일의 변경사항이 자동으로 감지되는 곳이기도 합니다.

Staging Area (Index) 는 다음 커밋에 포함시킬 변경사항을 선별하여 올려두는 준비 공간입니다. git add 명령으로 파일을 이곳에 등록합니다.

Repository (.git) 는 커밋된 스냅샷이 저장되는 곳입니다. git commit을 실행하면 Staging Area의 내용이 하나의 스냅샷으로 기록됩니다.

원본 오류 정정: 원본에서 "working directory에 변경사항이 기록된다"고 표현했는데, 보다 정확히는 working directory는 파일 편집이 일어나는 공간이고 Git이 변경사항을 감지(추적) 하는 곳입니다.

2. 초기 설정

Git 설치 후 최초 설정

# 사용자 정보 설정 (커밋 기록에 포함됨)
git config --global user.name "이름"
git config --global user.email "이메일"

# 기본 브랜치명을 main으로 설정
git config --global init.defaultBranch main

# 설정 확인
git config --list

GitHub 인증 설정 (2021년 8월 이후 필수)

GitHub는 2021년 8월 13일부터 비밀번호를 통한 Git 인증을 완전 차단했습니다. 반드시 아래 방식 중 하나를 사용해야 합니다.

방법 1: SSH 키 (권장)

# SSH 키 생성
ssh-keygen -t ed25519 -C "your_email@example.com"

# SSH 에이전트에 키 추가
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

# 공개키를 GitHub → Settings → SSH and GPG keys에 등록
cat ~/.ssh/id_ed25519.pub

방법 2: Personal Access Token (PAT)

GitHub → Settings → Developer settings → Personal access tokens → Generate new token
→ 필요한 scope 선택 (최소 repo) → 생성된 토큰을 비밀번호 대신 사용

# Credential Manager로 토큰 캐싱 (매번 입력하지 않도록)
git config --global credential.helper store    # Linux (평문 저장, 주의)
git config --global credential.helper osxkeychain  # macOS
# Windows는 Git 설치 시 Git Credential Manager가 기본 포함됨

3. 기본 사용법

저장소 초기화 및 첫 커밋

# 현재 디렉토리를 Git 저장소로 초기화
git init

# 특정 파일을 Staging Area에 추가
git add [파일명]

# 현재 디렉토리의 모든 변경사항을 Staging Area에 추가
git add .

# 커밋 (스냅샷 저장)
git commit -m "커밋 메시지"

# 트래킹 중인 파일의 add + commit을 한 번에 처리 (신규 파일은 제외)
git commit -am "커밋 메시지"

원격 저장소 연결 및 Push

# 원격 저장소 등록
git remote add origin [repository URL]

# 최초 Push (-u 옵션으로 upstream 설정)
git push -u origin main

# 이후 Push
git push

프로젝트 다운로드 (Clone)

# HTTPS (PAT 인증 필요)
git clone https://github.com/username/repository.git

# SSH (권장)
git clone git@github.com:username/repository.git

4. 상태 확인 (읽기)

# Working Directory의 변경사항 확인
git status

# 간략한 상태 보기
git status -s

# 커밋 히스토리 확인
git log

# 한 줄로 간결하게 보기
git log --oneline

# 커밋 간 변경 내용 확인
git log -p

# 파일별 변경 통계 확인
git log --stat

# 브랜치 그래프 시각화
git log --oneline --graph --all

# Staging Area와 Working Directory의 차이 확인
git diff

# Staging Area와 마지막 커밋의 차이 확인
git diff --staged

5. 브랜치 전환: `git switch` (⚠️ `checkout` 대체)

Git 2.23(2019년)에서 도입된 git switch와 git restore는 기존 git checkout의 두 가지 역할(브랜치 전환 + 파일 복원)을 명확히 분리한 명령어입니다. 2026년 현재, 공식 문서와 커뮤니티 모두 이 새로운 명령어 사용을 권장합니다.

# 브랜치 전환
git switch [브랜치명]       # 기존: git checkout [브랜치명]

# 새 브랜치 생성 후 전환
git switch -c [브랜치명]    # 기존: git checkout -b [브랜치명]

# 특정 커밋으로 이동 (Detached HEAD, 읽기 전용 탐색)
git switch --detach [commit-id]  # 기존: git checkout [commit-id]

# 직전 브랜치로 돌아가기
git switch -

# 최신 main 브랜치로 돌아가기
git switch main             # 기존: git checkout master

git checkout이 사라지는 건 아닙니다. 여전히 작동하지만, 의도 파악이 모호한 경우가 있어 switch/restore를 쓰는 것이 안전합니다. 예를 들어, test라는 파일과 test라는 브랜치가 모두 있을 때 git checkout test는 혼란을 일으킬 수 있습니다.

6. 파일 복원: `git restore` (⚠️ `checkout`/`reset` 대체)

# Working Directory의 변경사항 취소 (마지막 Staged 상태로 복원)
git restore [파일명]        # 기존: git checkout -- [파일명]

# Staging Area에서 제거 (Unstage), 파일 내용은 유지
git restore --staged [파일명]  # 기존: git reset HEAD [파일명]

# 특정 커밋의 상태로 파일 복원
git restore --source=[commit-id] [파일명]

# Staging Area와 Working Directory 모두 특정 커밋으로 복원
git restore --source=[commit-id] --staged --worktree [파일명]

7. 커밋 되돌리기

git reset: 히스토리 자체를 변경

git reset은 HEAD가 가리키는 위치를 이동시켜 커밋 히스토리를 변경합니다. 원격에 Push된 커밋에는 사용하지 마세요.

# 바로 이전 커밋 취소
git reset HEAD~1
# 또는
git reset HEAD^

옵션	Staging Area	Working Directory	설명
`--soft`	유지 (staged 상태)	유지	커밋만 취소, 변경사항은 staged 상태로 보존
`--mixed` (기본값)	초기화 (unstaged)	유지	커밋 + add 취소, 파일 내용은 보존
`--hard`	초기화 (unstaged)	삭제	모든 변경사항 완전 삭제 (⚠️ 주의!)

# 실사용 예시
git reset --soft HEAD~1   # "커밋은 취소하되, 수정사항은 staged 상태로 유지"
git reset --mixed HEAD~1  # "커밋과 add를 취소하되, 파일은 보존"
git reset --hard HEAD~1   # "완전히 이전 상태로 되돌리기" (복구 불가!)

--hard를 "index 취소, 파일 삭제"로만 설명하는 경우가 있는데, 보다 정확히는 Working Directory의 변경사항까지 완전히 삭제하여 해당 커밋 시점의 상태로 되돌린다는 의미입니다.

git revert: 히스토리를 유지하면서 되돌리기

git revert는 지정한 커밋의 변경사항을 취소하는 새로운 커밋을 생성합니다. 히스토리가 보존되므로 원격에 Push된 커밋도 안전하게 되돌릴 수 있습니다.

# 특정 커밋 되돌리기
git revert [commit-id]

# 여러 커밋을 연속으로 되돌리기 (역순으로)
git revert [newest-commit-id]..[oldest-commit-id]

# 커밋 메시지 에디터를 건너뛰고 자동 커밋
git revert --no-edit [commit-id]

reset vs revert 선택 기준

상황	권장 명령어
아직 Push 안 한 로컬 커밋	`git reset`
이미 Push한 커밋	`git revert`
협업 중인 공유 브랜치	`git revert` (히스토리 보존)
개인 브랜치에서 정리	`git reset` 가능

8. 작업 임시 저장: git stash

브랜치를 전환하기 전에 현재 작업 중인 변경사항을 임시로 저장할 때 사용합니다.

# 현재 변경사항 임시 저장
git stash

# 메시지와 함께 저장 (식별이 쉬움)
git stash push -m "작업 설명"

# 임시 저장 목록 확인
git stash list

# 가장 최근 stash 복원 (stash 목록에서 제거)
git stash pop

# 가장 최근 stash 복원 (stash 목록에 유지)
git stash apply

# 특정 stash 복원
git stash apply stash@{2}

# 가장 최근 stash 삭제
git stash drop

# 모든 stash 삭제
git stash clear

원본 보완: 원본에서는 save 서브커맨드를 사용했는데, Git 2.16부터 git stash push -m이 공식 권장 방법입니다. save는 deprecated 상태입니다.

9. Git Rebase vs Merge

브랜치를 합치는 두 가지 방법의 핵심 차이를 이해하는 것이 중요합니다.

구분	git merge	git rebase
이력 관리	분기점을 유지하며 병합 커밋 생성	커밋을 선형으로 재배치
커밋 해시	기존 커밋 해시 유지	새로운 해시로 변경됨
충돌 처리	병합 시점에서 한 번에 처리	각 커밋마다 순차적으로 처리
적합한 상황	공유 브랜치 병합	개인 브랜치 히스토리 정리

Merge 사용 예시 — 팀원과 공동 작업하는 브랜치 병합:

git switch dev
git merge feature/login

Rebase 사용 예시 — PR 전 개인 브랜치 히스토리 정리:

git switch feature/login
git fetch origin
git rebase origin/main

⚠️ Rebase 황금 규칙: 다른 사람과 공유 중인 브랜치에는 절대 rebase하지 마세요. rebase는 커밋 해시를 변경하므로, 공유 브랜치에 사용하면 다른 사람의 히스토리와 충돌이 발생합니다. rebase 후에는 git push --force-with-lease(force보다 안전)를 사용해야 합니다.

Interactive Rebase로 커밋 정리하기

PR 제출 전, 지저분한 커밋 히스토리를 깔끔하게 정리할 수 있습니다.

# 최근 3개 커밋을 대화형으로 수정
git rebase -i HEAD~3

에디터가 열리면 각 커밋 앞의 명령어를 변경합니다:

pick — 커밋 유지
squash (s) — 이전 커밋과 합치기
reword (r) — 커밋 메시지 수정
drop (d) — 커밋 삭제

10. Git Fetch vs Pull

구분	git fetch	git pull
동작	원격 변경사항만 다운로드	fetch + merge를 한 번에 실행
로컬 브랜치 영향	변경 없음	자동 병합됨
충돌 가능성	없음 (조회만)	있음 (자동 merge 시)
제어 수준	높음 (검토 후 직접 병합)	낮음 (자동 처리)

안전한 업데이트 흐름 (권장):

git fetch origin
git log HEAD..origin/main --oneline   # 원격의 새 커밋 확인
git diff HEAD..origin/main            # 구체적인 변경사항 검토
git merge origin/main                 # 확인 후 병합

빠른 업데이트 (혼자 작업 시):

git pull origin main

# 또는 rebase 방식으로 pull (merge commit 없이 선형 히스토리 유지)
git pull --rebase origin main

11. 2024~2026 최신 Git 기능

Sparse Checkout (대규모 모노레포 부분 클론)

대규모 저장소에서 필요한 디렉토리만 체크아웃할 수 있습니다.

git clone --filter=blob:none --sparse https://github.com/org/monorepo.git
cd monorepo
git sparse-checkout set packages/my-app

git maintenance (백그라운드 최적화)

저장소 성능을 자동으로 최적화하는 스케줄링 기능입니다.

git maintenance start              # 자동 최적화 스케줄 시작
git maintenance run --task=gc      # 수동으로 가비지 컬렉션 실행

git worktree (동시에 여러 브랜치 작업)

하나의 저장소에서 여러 브랜치를 각각 다른 디렉토리에 체크아웃할 수 있습니다.

git worktree add ../hotfix-branch hotfix/urgent-bug
# ../hotfix-branch 디렉토리에서 hotfix 작업 후
git worktree remove ../hotfix-branch

--update-refs (rebase 시 의존 브랜치 자동 업데이트)

git rebase main feature/auth --update-refs
# 의존 브랜치들도 함께 업데이트됨

git bisect (버그 도입 시점 이진 탐색)

git bisect start
git bisect bad                    # 현재 커밋에 버그가 있음
git bisect good [commit-id]       # 이 커밋에는 버그가 없었음
# Git이 중간 커밋을 체크아웃 → good/bad 반복 → 버그 커밋 특정
git bisect reset                  # 원래 브랜치로 복귀

12. 실전 워크플로우 정리

혼자 작업할 때

# 1. 저장소 클론 또는 초기화
git clone git@github.com:username/project.git
# 또는
git init && git remote add origin git@github.com:username/project.git

# 2. 기능 브랜치 생성
git switch -c feature/new-page

# 3. 작업 → add → commit 반복
git add .
git commit -m "feat: 새 페이지 레이아웃 추가"

# 4. main에 병합
git switch main
git pull origin main
git merge feature/new-page

# 5. Push
git push origin main

# 6. 기능 브랜치 삭제
git branch -d feature/new-page

협업할 때

# 1. 최신 main 기반으로 기능 브랜치 생성
git switch main
git pull origin main
git switch -c feature/login

# 2. 작업 완료 후, PR 전에 히스토리 정리
git fetch origin
git rebase origin/main
# 충돌 발생 시: 수정 → git add . → git rebase --continue

# 3. Push 후 PR 생성
git push --force-with-lease origin feature/login
# GitHub에서 Pull Request 생성 → 코드 리뷰 → Merge

커밋 메시지 컨벤션 (Conventional Commits)

feat: 새로운 기능 추가
fix: 버그 수정
docs: 문서 변경
style: 코드 포맷팅 (기능 변경 없음)
refactor: 리팩토링
test: 테스트 추가/수정
chore: 빌드 설정, 패키지 매니저 등

13. 자주 하는 실수와 해결법

실수로 git add .로 모든 파일을 올렸을 때:

git restore --staged .           # 전체 unstage
git restore --staged [파일명]    # 특정 파일만 unstage

마지막 커밋 메시지를 수정하고 싶을 때:

git commit --amend -m "수정된 메시지"

마지막 커밋에 파일을 빠뜨렸을 때:

git add [빠뜨린 파일]
git commit --amend --no-edit     # 메시지 변경 없이 커밋에 추가

Push 후 커밋을 되돌리고 싶을 때:

git revert [commit-id]           # 안전하게 새 커밋으로 되돌리기
git push origin main

git reset --hard를 잘못 실행했을 때:

git reflog                       # 모든 HEAD 이동 기록 확인
git reset --hard [reflog-id]     # 원하는 시점으로 복구

14. 유용한 .gitignore 설정

프로젝트 루트에 .gitignore 파일을 생성하여 불필요한 파일의 추적을 방지합니다.

# 의존성
node_modules/
vendor/

# 빌드 결과물
dist/
build/
*.min.js

# 환경 설정 (민감정보)
.env
.env.local

# OS 파일
.DS_Store
Thumbs.db

# IDE 설정
.idea/
.vscode/
*.swp

💡 gitignore.io — 프로젝트 환경에 맞는 .gitignore를 자동 생성해주는 서비스

참고 사이트

'CS > Git' 카테고리의 다른 글

GitHub config 변경 방법 (0)	2025.04.24
[GIT] .gitignore가 작동하지 않을 때 대처 방법 (0)	2023.06.23

[GIT] GIT을 통해 버젼관리를 하는 방법 (2026 개정판)

📋 주요 변경사항

1. 버전관리의 구조: Git의 세 가지 영역

2. 초기 설정

Git 설치 후 최초 설정

GitHub 인증 설정 (2021년 8월 이후 필수)

3. 기본 사용법

저장소 초기화 및 첫 커밋

원격 저장소 연결 및 Push

프로젝트 다운로드 (Clone)

4. 상태 확인 (읽기)

5. 브랜치 전환: `git switch` (⚠️ `checkout` 대체)

6. 파일 복원: `git restore` (⚠️ `checkout`/`reset` 대체)

7. 커밋 되돌리기

git reset: 히스토리 자체를 변경

git revert: 히스토리를 유지하면서 되돌리기

reset vs revert 선택 기준

8. 작업 임시 저장: git stash

9. Git Rebase vs Merge

Interactive Rebase로 커밋 정리하기

10. Git Fetch vs Pull

11. 2024~2026 최신 Git 기능

Sparse Checkout (대규모 모노레포 부분 클론)

git maintenance (백그라운드 최적화)

git worktree (동시에 여러 브랜치 작업)

--update-refs (rebase 시 의존 브랜치 자동 업데이트)

git bisect (버그 도입 시점 이진 탐색)

12. 실전 워크플로우 정리

혼자 작업할 때

협업할 때

커밋 메시지 컨벤션 (Conventional Commits)

13. 자주 하는 실수와 해결법

14. 유용한 .gitignore 설정

참고 사이트

'CS > Git' 카테고리의 다른 글

댓글

티스토리툴바

[GIT] GIT을 통해 버젼관리를 하는 방법 (2026 개정판)

📋 주요 변경사항

1. 버전관리의 구조: Git의 세 가지 영역

2. 초기 설정

Git 설치 후 최초 설정

GitHub 인증 설정 (2021년 8월 이후 필수)

3. 기본 사용법

저장소 초기화 및 첫 커밋

원격 저장소 연결 및 Push

프로젝트 다운로드 (Clone)

4. 상태 확인 (읽기)

5. 브랜치 전환: git switch (⚠️ checkout 대체)

6. 파일 복원: git restore (⚠️ checkout/reset 대체)

7. 커밋 되돌리기

git reset: 히스토리 자체를 변경

git revert: 히스토리를 유지하면서 되돌리기

reset vs revert 선택 기준

8. 작업 임시 저장: git stash

9. Git Rebase vs Merge

Interactive Rebase로 커밋 정리하기

10. Git Fetch vs Pull

11. 2024~2026 최신 Git 기능

Sparse Checkout (대규모 모노레포 부분 클론)

git maintenance (백그라운드 최적화)

git worktree (동시에 여러 브랜치 작업)

--update-refs (rebase 시 의존 브랜치 자동 업데이트)

git bisect (버그 도입 시점 이진 탐색)

12. 실전 워크플로우 정리

혼자 작업할 때

협업할 때

커밋 메시지 컨벤션 (Conventional Commits)

13. 자주 하는 실수와 해결법

14. 유용한 .gitignore 설정

참고 사이트

'CS > Git' 카테고리의 다른 글

댓글

티스토리툴바

5. 브랜치 전환: `git switch` (⚠️ `checkout` 대체)

6. 파일 복원: `git restore` (⚠️ `checkout`/`reset` 대체)