"Git은 단순한 버전 관리 도구가 아닙니다. 현대 소프트웨어 개발의 핵심 인프라이자, 개발자들의 협업을 가능하게 하는 시간 여행 기계입니다."
🌿 브랜치 전략과 워크플로우
브랜치는 Git의 꽃입니다. 격리된 환경에서 기능을 개발하고, 코드 리뷰를 거쳐 안전하게 통합하는 전체 프로세스를 가능하게 합니다. 2025년 현재, GitHub Flow와 GitLab Flow가 가장 널리 사용되는 전략입니다.
브랜치 기본 명령어
branch, checkout, switch
# 브랜치 목록
git branch # 로컬 브랜치
git branch -r # 원격 브랜치
git branch -a # 모든 브랜치
git branch -vv # upstream 정보와 함께
# 브랜치 생성
git branch feature-login # 생성만
git checkout -b feature-login # 생성 + 전환 (구문법)
git switch -c feature-login # 생성 + 전환 (신문법, Git 2.23+)
# 브랜치 전환
git checkout main # 구문법
git switch main # 신문법 (더 명확함)
# 브랜치 삭제
git branch -d feature-login # 병합된 브랜치 삭제
git branch -D feature-login # 강제 삭제 (병합 여부 무시)
# 브랜치 이름 변경
git branch -m old-name new-name
인기 브랜치 전략 비교
| 전략 | 특징 | 적합한 팀 | 난이도 |
|---|---|---|---|
| Git Flow | main, develop, feature, release, hotfix 브랜치 | 버전 관리가 중요한 대형 프로젝트 | ⭐⭐⭐ |
| GitHub Flow | main + feature 브랜치 단순 구조 | 지속적 배포(CD) 환경 | ⭐ |
| GitLab Flow | 환경별 브랜치(production, staging) | 여러 배포 환경이 있는 팀 | ⭐⭐ |
| Trunk-Based | main에 직접 커밋, 짧은 lived feature branch | 고수준 자동화된 대규모 팀 | ⭐⭐⭐⭐ |
🎯 GitHub 커뮤니티의 조언
GitHub Discussion의 한 개발자는 "Git Flow는 과거의 유산이고, 현대에는 GitHub Flow나 Trunk-Based Development가 더 적합하다"고 주장했습니다. 특히 "feature 브랜치의 수명은 하루를 넘지 않게 하라"는 규칙을 강조하며, 장기간 살아있는 브랜치는 merge conflict의 지뢰밭이 된다고 경고했습니다.
Pull Request 워크플로우 완벽 가이드
최신 코드 동기화
git pull origin main
브랜치 생성 전 항상 최신 main을 가져와 conflict를 예방합니다.
기능 브랜치 생성
git switch -c feature/user-auth
명확한 네이밍 컨벤션으로 브랜치를 생성합니다.
개발 및 커밋
git add . && git commit -m "feat: 사용자 인증 구현"
의미 있는 단위로 자주 커밋합니다.
원격에 푸시
git push -u origin feature/user-auth
원격 저장소에 브랜치를 게시합니다.
Pull Request 생성
GitHub/GitLab에서 PR을 생성하고 코드 리뷰를 요청합니다.
리뷰 후 병합
Approve 후 squash merge 또는 rebase merge를 수행합니다.
🔀 고급 명령어: Rebase vs Merge 심층 분석
Git 사용자들 사이에서 가장 치열한 논쟁거리 중 하나가 바로 "rebase를 쓸 것인가, merge를 쓸 것인가"입니다. 이 선택은 팀의 코드 히스토리 철학을 반영하며, 각각 명확한 장단점이 있습니다.
Merge: 안전한 통합
Merge는 두 브랜치의 히스토리를 보존하며 통합합니다. Non-fast-forward merge는 명시적인 merge commit을 생성하여 "언제, 어떤 기능이 통합되었는지"를 기록합니다.
merge 명령어
# 기본 merge (fast-forward 가능하면 수행)
git merge feature-branch
# non-fast-forward 강제 (merge commit 생성)
git merge --no-ff feature-branch
# merge 취소
git merge --abort
# 특정 전략으로 merge
git merge -X ours feature-branch # conflict 시 현재 브랜치 우선
git merge -X theirs feature-branch # conflict 시 대상 브랜치 우선
Rebase: 깔끔한 역사
Rebase는 "현재 브랜치의 커밋들을 대상 브랜치 위로 재배치"합니다. 결과적으로 선형적인 히스토리를 만들어 git log를 읽기 쉽게 만듭니다.
rebase 명령어
# 현재 브랜치를 main 위로 rebase
git rebase main
# interactive rebase (강력함!)
git rebase -i HEAD~5
# rebase 중 conflict 해결 후 계속
git rebase --continue
# rebase 중단 (원래 상태로 복구)
git rebase --abort
# 특정 커밋까지 rebase
git rebase --onto newbase oldbase branch
Interactive Rebase: 커밋 히스토리 조각보
git rebase -i는 Git의 가장 강력한 기능 중 하나입니다. 커밋 순서 변경, 합치기(squash), 분할, 메시지 수정 등이 가능합니다.
# 최근 5개 커밋 수정
git rebase -i HEAD~5
# 나타나는 옵션들:
# p, pick = use commit (그대로 사용)
# r, reword = use commit, but edit the commit message (메시지 수정)
# e, edit = use commit, but stop for amending (수정을 위해 중지)
# s, squash = use commit, but meld into previous commit (이전 커밋과 합치기)
# f, fixup = like "squash", but discard this commit's log message (메시지 없이 합치기)
# x, exec = run command (the rest of the line) using shell (명령어 실행)
# d, drop = remove commit (커밋 삭제)
| 상황 | 권장 방법 | 이유 |
|---|---|---|
| 로컬 feature 브랜치 정리 | git rebase -i |
깔끔한 커밋 히스토리 유지 |
| 공유된 브랜치 업데이트 | git merge |
히스토리 재작성 위험 방지 |
| main에 기능 통합 | PR Merge (Squash or Merge) | 팀 정책 따르기 |
| hotfix 적용 | git cherry-pick |
특정 커밋만 선택적 적용 |
⚠️ Hacker News에서의 논쟁
한 Hacker News 사용자는 "rebase를 사용하다가 한 달치 작업이 날아갔습니다"라는 경험을 공유하며 주의를 당부했습니다. 그는 "rebase는 로컬 브랜치에서만, 그리고 push하기 전에만 사용하라"고 강조했습니다. 반면 다른 사용자는 "merge commit이 쌓이면 git bisect가 어려워진다"며 rebase의 유용성을 주장했습니다.
🛠️ Stash, Cherry-pick, Reflog 실전 활용
숙련된 Git 사용자는 위기 상황에서도 당황하지 않습니다. Stash로 작업을 임시 저장하고, Cherry-pick으로 필요한 커밋만 골라 적용하며, Reflog로 실수를 복구하기 때문입니다.
Git Stash: 임시 저장소의 마법
긴급한 버그 수정을 위해 현재 작업을 잠시 접어두어야 할 때, Stash는 완벽한 해결책입니다. 작업 디렉토리의 변경사항을 안전하게 보관하고 나중에 복구할 수 있습니다.
stash 명령어 모음
# 현재 변경사항 stash
git stash
git stash push -m "WIP: 로그인 기능 구현 중"
# stash 목록 확인
git stash list
# stash@{0}: On main: WIP: 로그인 기능 구현 중
# stash@{1}: On feature-branch: 임시 수정사항
# stash 적용 (목록에서 제거하지 않음)
git stash apply
git stash apply stash@{1}
# stash 적용 및 제거 (pop)
git stash pop
git stash pop stash@{0}
# 특정 파일만 stash
git stash push -m "부분 stash" path/to/file.txt
# untracked 파일도 포함
git stash push -u -m "untracked 포함"
git stash push --all # ignored 파일까지 포함
# stash에서 특정 파일만 꺼내기
git checkout stash@{0} -- filename.txt
# stash 삭제
git stash drop stash@{1}
# 모든 stash 삭제
git stash clear
# stash를 새 브랜치로 변환
git stash branch new-branch-name stash@{0}
💡 Stash 고급 활용
git stash push -p (또는 --patch)는 대화형 모드로, 변경사항의 일부만 선택적으로 stash할 수 있게 합니다. 디버그 코드는 제거하고 기능 코드만 stash하고 싶을 때 유용합니다.
Cherry-pick: 커밋 수확하기
다른 브랜치의 특정 커밋만 필요할 때, 전체 merge 없이 원하는 커밋만 "따올" 수 있습니다.
cherry-pick 활용법
# 단일 커밋 cherry-pick
git cherry-pick abc1234
# 여러 커밋 cherry-pick
git cherry-pick abc1234 def5678
# 커밋 범위 cherry-pick (older..newer)
git cherry-pick abc1234^..def5678
# merge commit cherry-pick
git cherry-pick -m 1 abc1234
# 커밋 내용만 적용 (커밋 생성 없이)
git cherry-pick -n abc1234
# cherry-pick 중 conflict 발생 시
git cherry-pick --continue
git cherry-pick --abort
git cherry-pick --skip
Reflog: Git의 타임머신
git reflog는 Git의 "안전망"입니다. git reset --hard로 날려버린 커밋, 삭제한 브랜치, 잘못된 rebase도 reflog로 복구할 수 있습니다.
reflog로 모든 것을 복구하기
# reflog 확인
git reflog
git reflog --date=relative # 상대 시간으로 표시
# 특정 시점으로 복구
git reset --hard HEAD@{2}
git reset --hard abc1234
# 삭제된 브랜치 복구
git reflog | grep "checkout: moving from"
git branch recovered-branch HEAD@{5}
# ORIG_HEAD 활용 (마지막 위험한 작업 전)
git reset --hard ORIG_HEAD
# 특정 브랜치의 reflog
git reflog show feature-branch
# unreachable 객체 찾기
git fsck --unreachable --no-reflogs | grep commit
🚨 실제 복구 시나리오
한 개발자는 git reset --hard HEAD~3으로 3일치 작업을 날려버렸습니다. 하지만 git reflog에서 reset 직전의 커밋 해시를 찾아 git reset --hard HEAD@{1}로 완벽하게 복구했습니다. reflog는 로컬에서 90일간 유지되므로, 실수 후에도 충분한 시간이 있습니다.
핵심 포인트: Git 실수 복구 체크리스트
- 실수했을 때: 당황하지 말고
git reflog를 확인하세요 - 작업 중단 시:
git stash로 안전하게 보관하세요 - 특정 커밋 필요 시:
git cherry-pick으로 선택적으로 적용하세요 - 복구 전: 현재 상태를
git branch backup로 백업하세요
🤖 Git Hooks로 자동화 구축하기
Git Hooks는 특정 Git 이벤트 발생 시 자동으로 실행되는 스크립트입니다. 코드 품질 검사, 테스트 실행, 커밋 메시지 검증 등을 자동화하여 휴먼 에러를 방지할 수 있습니다.
주요 Git Hooks 종류
| Hook | 트리거 시점 | 용도 |
|---|---|---|
pre-commit |
커밋 생성 전 | 린트, 포맷팅, 간단한 테스트 |
prepare-commit-msg |
커밋 메시지 편집기 열기 전 | 기본 메시지 템플릿 삽입 |
commit-msg |
커밋 메시지 저장 후 | 커밋 메시지 규칙 검증 |
post-commit |
커밋 생성 후 | 알림, 로깅 |
pre-push |
push 전 | 전체 테스트, 빌드 검증 |
post-merge |
merge 완료 후 | 의존성 설치 |
실전 Hook 예시
pre-commit: ESLint + Prettier
#!/bin/bash
# .git/hooks/pre-commit
echo "🔍 Pre-commit checks running..."
# Staged 파일 목록
STAGED_FILES=$(git diff --cached --name-only --diff-filter=ACM | grep -E '\.(js|jsx|ts|tsx)$')
if [ -n "$STAGED_FILES" ]; then
echo "Running ESLint..."
npx eslint $STAGED_FILES --fix
if [ $? -ne 0 ]; then
echo "❌ ESLint failed. Commit aborted."
exit 1
fi
# 수정된 파일 다시 stage
echo "$STAGED_FILES" | xargs git add
fi
# 디버그 코드 검사
if git diff --cached | grep -E "console\.log|debugger|TODO|FIXME"; then
echo "⚠️ Warning: Debug code or TODOs found in staged changes"
# exit 1 # 강제 차단하려면 주석 해제
fi
echo "✅ Pre-commit checks passed!"
exit 0
commit-msg: Conventional Commits 검증
#!/bin/bash
# .git/hooks/commit-msg
COMMIT_MSG_FILE=$1
COMMIT_MSG=$(cat "$COMMIT_MSG_FILE")
# Conventional Commits 패턴 검사
PATTERN="^(feat|fix|docs|style|refactor|test|chore|ci|build|perf)(\(.+\))?: .{1,100}"
if ! echo "$COMMIT_MSG" | grep -qE "$PATTERN"; then
echo "❌ Invalid commit message format!"
echo ""
echo "Expected format: (): "
echo ""
echo "Types: feat, fix, docs, style, refactor, test, chore, ci, build, perf"
echo "Example: feat(auth): add JWT token validation"
echo ""
exit 1
fi
echo "✅ Commit message format valid!"
exit 0
Husky + lint-staged 현대적 설정
2025년 현재, Husky와 lint-staged 조합이 가장 널리 사용되는 Hook 관리 방식입니다.
// package.json
{
"husky": {
"hooks": {
"pre-commit": "lint-staged",
"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
}
},
"lint-staged": {
"*.{js,jsx,ts,tsx}": [
"eslint --fix",
"prettier --write",
"git add"
],
"*.{json,md}": [
"prettier --write",
"git add"
]
}
}
🌳 Git Worktree와 Sparse Checkout
대형 프로젝트나 동시에 여러 브랜치를 작업해야 할 때, Git Worktree와 Sparse Checkout은 생산성을 극대화하는 강력한 도구입니다.
Git Worktree: 여러 브랜치 동시 체크아웃
기존에는 한 저장소에서 하나의 브랜치만 작업할 수 있었습니다. Worktree를 사용하면 여러 디렉토리에서 서로 다른 브랜치를 동시에 작업할 수 있습니다.
worktree 명령어
# 새 worktree 생성 (브랜치 자동 생성)
git worktree add ../project-feature feature-branch
# 기존 브랜치를 worktree로
git worktree add ../project-hotfix hotfix-branch
# worktree 목록
git worktree list
# worktree 제거
git worktree remove ../project-feature
# 정리되지 않은 worktree 제거
git worktree prune
# detached HEAD로 worktree 생성
git worktree add --detach ../project-temp
# main worktree로 이동
cd $(git rev-parse --show-toplevel)
🚀 AI 코딩 에이전트와 Worktree
최근 Reddit r/webdev에서 "AI 코딩 에이전트(Claude Code, Cursor 등)와 Worktree를 함께 사용하면 효율이 극대화된다"는 팁이 화제가 되었습니다. 각 AI 세션마다 별도의 worktree를 할당하여 컨텍스트를 완전히 분리하고, stash 충돌이나 WIP 커밋 없이 깔끔하게 작업할 수 있습니다.
Sparse Checkout: 대형 저장소 효율적 관리
모노레포(Monorepo)에서 전체를 클론하지 않고 필요한 디렉토리만 선택적으로 체크아웃할 수 있습니다.
sparse-checkout 설정
# Sparse checkout 활성화
git sparse-checkout init
# 포함할 디렉토리 설정
git sparse-checkout set frontend/app
git sparse-checkout set frontend/app backend/api
# 여러 패턴 추가
git sparse-checkout add shared/utils
git sparse-checkout add docs/
# 현재 설정 확인
git sparse-checkout list
# 비활성화 (전체 체크아웃)
git sparse-checkout disable
# cone mode (더 빠른 성능)
git sparse-checkout init --cone
git sparse-checkout set frontend backend
Partial Clone과 결합
# Blob 없이 클론 (매우 빠름)
git clone --filter=blob:none --no-checkout https://github.com/large/repo.git
# Sparse checkout와 함께 사용
cd repo
git sparse-checkout init --cone
git sparse-checkout set frontend/app
git checkout main
📦 Git LFS로 대용량 파일 관리
Git은 텍스트 파일 버전 관리에 최적화되어 있습니다. 100MB 이상의 바이너리 파일(이미지, 영상, 데이터셋)을 직접 저장하면 저장소가 비대해지고 clone/pull이 느려집니다. Git LFS(Large File Storage)는 이 문제를 우아하게 해결합니다.
Git LFS 작동 원리
Git LFS는 실제 파일 대신 "포인터 파일"을 저장소에 저장하고, 실제 파일 내용은 별도의 LFS 서버에 보관합니다. Clone 시에는 포인터만 받고, 필요할 때 실제 파일을 다운로드합니다.
LFS 설치 및 설정
# macOS
brew install git-lfs
git lfs install
# Ubuntu/Debian
curl -s https://packagecloud.io/install/repositories/github/git-lfs/script.deb.sh | sudo bash
sudo apt-get install git-lfs
git lfs install
# Windows
winget install GitHub.GitLFS
git lfs install
# 저장소별 설정
git lfs install --local
LFS 파일 추적
# 파일 패턴 추적
git lfs track "*.psd"
git lfs track "*.zip"
git lfs track "*.mp4"
git lfs track "assets/videos/**"
git lfs track "data/*.csv"
# .gitattributes 자동 생성됨
cat .gitattributes
# *.psd filter=lfs diff=lfs merge=lfs -text
# .gitattributes 반드시 커밋
git add .gitattributes
git commit -m "Configure Git LFS"
# 대용량 파일 추가
git add design/mockup.psd
git commit -m "Add mockup design"
git push
LFS 관리 명령어
# LFS 파일 목록
git lfs ls-files
git lfs ls-files -s # 크기와 함께
# LFS 객체 가져오기
git lfs fetch
git lfs fetch --all # 모든 브랜치
git lfs pull # fetch + checkout
# 특정 파일만 제외하고 가져오기
git lfs fetch --exclude="*.psd"
# LFS 상태 확인
git lfs status
git lfs env
# 기존 파일 LFS로 마이그레이션
git lfs migrate import --include="*.zip"
git lfs migrate import --above=10MB # 10MB 이상만
# 히스토리 전체 재작성 (주의!)
git lfs migrate import --include="*.zip" --everything
# 이후 force push 필요
⚠️ 주의사항
GitHub는 LFS 파일당 5GB, 저장소당 2GB의 무료 스토리지를 제공합니다. 초과 시 비용이 발생하므로, 100KB 이하의 작은 이미지는 일반 Git으로 관리하는 것이 효율적입니다. 또한 LFS는 GitHub, GitLab, Bitbucket 등 호스팅 서비스의 지원이 필요합니다.
🔐 커밋 서명과 보안
오픈소스 프로젝트에서 커밋 위조는 심각한 보안 위협입니다. GPG 또는 SSH 키로 커밋에 서명하여 "이 커밋이 정말 내가 한 것"임을 증명할 수 있습니다.
SSH 키로 커밋 서명 (권장)
Git 2.34부터 SSH 키를 사용한 커밋 서명이 가능해졌습니다. GPG보다 설정이 간단하고, 이미 SSH 키를 가지고 있다면 추가 생성이 필요 없습니다.
SSH 서명 설정
# SSH 키 생성 (Ed25519 권장)
ssh-keygen -t ed25519 -C "your@email.com" -f ~/.ssh/git_signing_key
# Git 설정
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/git_signing_key.pub
git config --global commit.gpgsign true # 모든 커밋 자동 서명
# 또는 특정 저장소만
git config commit.gpgsign true
# allowed_signers 파일 설정 (서명 검증용)
echo "$(git config user.email) namespaces=\"git\" $(cat ~/.ssh/git_signing_key.pub)" > ~/.ssh/allowed_signers
git config --global gpg.ssh.allowedSignersFile ~/.ssh/allowed_signers
GPG 서명 (전통적 방법)
# GPG 키 생성
gpg --full-generate-key
# 키 ID 확인
gpg --list-secret-keys --keyid-format LONG
# Git 설정
git config --global user.signingkey YOUR_KEY_ID
git config --global commit.gpgsign true
# 특정 커밋만 서명
git commit -S -m "feat: important feature"
# 서명된 커밋 푸시
git push
# 서명 검증
git log --show-signature -1
🔍 GitHub에서 서명 확인
서명된 커밋은 GitHub에서 "Verified" 배지로 표시됩니다. Settings → SSH and GPG keys에서 공개 키를 등록해야 합니다. SSH 서명의 경우 Key type을 "Signing key"로 선택하세요.
⚡ 생산성을 높이는 Git Alias
자주 사용하는 긴 명령어를 짧은 별칭으로 등록하면 타이핑 시간을 크게 줄일 수 있습니다. 팀마다 고유한 alias 문화가 있을 정도로, 이는 개발자의 개성을 드러내는 영역이기도 합니다.
필수 Alias 모음
.gitconfig 추천 설정
# ~/.gitconfig
[alias]
# 기본 단축
st = status
co = checkout
sw = switch
br = branch
ci = commit
cm = commit -m
# 강력한 단축
amend = commit --amend --no-edit
unstage = restore --staged
last = log -1 HEAD
visual = !gitk
# 로그 예쁘게 보기
lg = log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit
lol = log --graph --decorate --oneline --all
# add + commit + push 한번에
acp = "!f() { git add -A && git commit -m \"$1\" && git push; }; f"
amod = "!f() { git add -u && git commit -m \"$1\" && git push; }; f"
# 안전한 업데이트
up = "!git fetch --prune && git rebase origin/$(git rev-parse --abbrev-ref HEAD)"
sync = "!git fetch --all --prune"
# 위험하지만 유용한 것들
nuke = reset --hard
undo = reset --soft HEAD~1
# stash 단축
ss = stash
sp = stash pop
sl = stash list
# 현재 브랜치 관련
current = rev-parse --abbrev-ref HEAD
upstream = rev-parse --abbrev-ref --symbolic-full-name @{u}
팀별 Alias 공유
팀 전체가 동일한 alias를 사용하면 커뮤니케이션이 원활해집니다. 프로젝트 루트에 .gitconfig를 포함시키고 다음과 같이 설정할 수 있습니다:
# 프로젝트별 alias 포함
git config --local include.path ../.gitconfig
# 또는 직접 설정
git config --local alias.st status
git config --local alias.co checkout
🎯 zsh/bash alias와의 차이
쉘 alias(alias g='git')는 Git alias보다 더 유연합니다. g st, g commit 등 모든 git 명령어에 접두사를 붙일 수 있습니다. 둘을 조합해 사용하는 것이 최선입니다.
🚑 실전 문제 해결 가이드
Git을 사용하다 보면 다양한 문제에 직면합니다. 여기서는 실제 개발 현장에서 자주 발생하는 문제와 그 해결책을 정리했습니다.
문제 1: 잘못된 브랜치에 커밋했을 때
해결 방법
# 상황: feature-A 브랜치에서 작업해야 했는데 main에 커밋함
# 1. 커밋을 임시 저장
git reset --soft HEAD~1
# 2. 올바른 브랜치로 이동 (또는 생성)
git switch -c feature-A
# 3. 커밋 재생성
git commit -m "feat: A 기능 구현"
# 또는 cherry-pick 사용
git switch -c feature-A
git cherry-pick main # main의 마지막 커밋
git switch main
git reset --hard HEAD~1 # main의 커밋 제거
문제 2: 민감한 정보를 커밋했을 때
API 키, 비밀번호 노출 시
# 방법 1: 마지막 커밋만 수정 (아직 push 안 한 경우)
git reset --soft HEAD~1
# 파일 수정 후
git add .
git commit -m "fixed: remove sensitive data"
# 방법 2: 히스토리 전체 재작성 (이미 push한 경우 - 주의!)
git filter-repo --path config/secrets.json --invert-paths
# 또는
git filter-branch --force --index-filter \
"git rm --cached --ignore-unmatch config/secrets.json" \
--prune-empty --tag-name-filter cat -- --all
# 방법 3: BFG Repo-Cleaner (대형 저장소용)
bfg --delete-files secrets.json
git reflog expire --expire=now --all
git gc --prune=now --aggressive
중요: 이미 push한 커밋을 수정하면 팀원들과 충돌이 발생합니다. 반드시 팀에 공유하고 force push 후 모두가 저장소를 재클론하거나 rebase해야 합니다.
문제 3: Merge Conflict 해결
Conflict 해결 워크플로우
# 1. Conflict 발생 확인
git status
# Unmerged paths: both modified: src/app.js
# 2. Conflict 표시 확인
cat src/app.js
# <<<<<<< HEAD
# 내 코드
# =======
# 상대방 코드
# >>>>>>> feature-branch
# 3. 수동으로 수정 또는 도구 사용
git mergetool # vimdiff, vscode 등 설정된 도구 실행
# 4. 해결 후 표시
git add src/app.js
# 5. 병합 완료
git commit # 자동으로 merge commit 생성
# 또는 rebase 중이면
git rebase --continue
# 병합 취소
git merge --abort
git rebase --abort
문제 4: Detached HEAD 상태
HEAD가 분리되었을 때
# 상황: 특정 커밋을 checkout해서 HEAD가 분리됨
# HEAD is now at abc1234...
# 변경사항이 없는 경우: 그냥 브랜치로 돌아가기
git switch main
# 변경사항이 있는 경우
# 방법 1: 새 브랜치 생성 (권장)
git switch -c new-branch-name
# 방법 2: 기존 브랜치에 합치기
git switch main
git merge $(git rev-parse HEAD)
git branch -d temp-branch
문제 5: Git이 느려질 때
# 저장소 최적화
git gc # 가비지 컬렉션
git gc --aggressive # 깊은 최적화 (시간 소요)
# 큰 파일 찾기
git rev-list --objects --all | git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' | awk '/^blob/ {print $3 " " $4}' | sort -rn | head -20
# LFS로 마이그레이션 고려
git lfs migrate import --include="*.psd" --everything
# shallow clone으로 히스토리 제한
git clone --depth 1 https://github.com/large/repo.git
🔮 2026년 Git 트렌드와 전망
Git은 20년이 넘은 도구지만 여전히 진화하고 있습니다. 2025-2026년에 주목해야 할 트렌드와 새로운 기능들을 정리했습니다.
1. Scalar: 대형 저장소를 위한 Git
Microsoft가 개발한 Scalar는 수십 GB 이상의 대형 저장소를 효율적으로 관리하기 위한 Git 확장입니다. GVFS(Git Virtual File System)의 후속으로, 파일 시스템 가상화 없이 Git 명령어 호환성을 유지하면서 성능을 극대화합니다.
# Scalar 설치 (Windows)
winget install Microsoft.Scalar
# Scalar로 클론
scalar clone https://github.com/large/repo.git
# 내부적으로는 다음을 수행
# - blobless clone
# - sparse-checkout
# - 파일 시스템 모니터링
# - 백그라운드 유지보수
2. GitHub Codespaces와의 통합
클라우드 개발 환경이 표준이 되면서 Git 워크플로우도 변화하고 있습니다. 브라우저에서 VS Code를 통해 완전한 개발 환경에 접근하고, prebuilds로 초기 설정 시간을 단축할 수 있습니다.
3. AI와 Git의 결합
GitHub Copilot, Claude Code, Cursor 등 AI 코딩 도구들이 Git 명령어 실행을 자동화하고 있습니다. "이 변경사항을 커밋하고 PR을 만들어줘"와 같은 자연어 명령이 가능해지고 있습니다.
🤖 AI 시대의 Git 전략
AI가 코드를 생성하는 시대에서 Git의 역할은 더욱 중요해졌습니다. AI가 생성한 코드의 출처 추적, 라이선스 준수 확인, 점진적 통합을 위한 feature branch 전략이 필수적입니다. Conventional Commits와 상세한 커밋 메시지는 AI가 코드 히스토리를 이해하는 데 도움을 줍니다.
4. Git 2.47+ 새로운 기능
- reftable: 대형 저장소에서 refs 접근 성능 향상
- merge-ort: 새로운 merge 전략, 더 빠르고 정확한 conflict 처리
- sparse-index: sparse-checkout 저장소의 인덱스 성능 최적화
- commit-graph: 대형 저장소의 로그 성능 향상
5. 보안 강화 트렌드
2025년 기준, 주요 오픈소스 프로젝트들은 서명된 커밋을 필수로 요구하는 추세입니다. GitHub의 "Vigilant Mode"는 모든 커밋의 서명 상태를 명확히 표시하며, unsigned 커밋에 경고를 표시합니다.