테마
실무 팁과 전략
git stash - 커밋하지 않은 작업 잠시 치우기
git stash는 아직 커밋하지 않은 변경사항을 잠시 치워 두는 로컬 도구입니다.
예를 들면 이런 상황에서 유용합니다.
- 기능 작업 중인데 긴급 버그 수정 브랜치로 잠깐 이동해야 할 때
- 아직 커밋 메시지를 정리하지 못했지만 워킹 디렉토리를 깨끗하게 만들고 싶을 때
- 일부 변경만 잠시 숨기고 다른 실험을 해 보고 싶을 때
stash와 08장의 차이
git stash는 히스토리를 고치는 도구가 아니라 아직 커밋되지 않은 작업을 치우는 도구입니다.reset, reflog, rebase -i처럼 커밋 이력을 다루는 내용은 08. 되돌리기와 복구에서 함께 보는 편이 더 자연스럽습니다.
언제 stash를 쓰고, 언제 임시 커밋을 쓸까?
| 선택 | 잘 맞는 상황 |
|---|---|
git stash | 정말 잠깐 치워두고 바로 돌아올 작업 |
| 임시 WIP 커밋 | 컨텍스트 전환이 길어질 수 있고 기록을 남기고 싶은 작업 |
stash가 만능은 아닙니다.
팀에 따라서는 WIP: 임시 커밋을 남기고 나중에 rebase -i나 reset --soft로 정리하는 쪽을 더 선호하기도 합니다.
기본 명령어
bash
# 현재 변경사항 보관
git stash push -m "login form WIP"
# 목록 보기
git stash list
# 내용 요약 보기
git stash show stash@{0}
# patch 형태로 자세히 보기
git stash show -p stash@{0}
# 적용만 하고 stash는 남기기
git stash apply stash@{0}
# 적용 후 목록에서 제거
git stash pop
# 특정 stash 삭제
git stash drop stash@{0}실무에서 자주 쓰는 옵션
| 명령어 | 의미 |
|---|---|
git stash push -m "설명" | 이름 있는 stash 생성 |
git stash push -u | untracked 파일까지 포함 |
git stash push --all | ignored 파일까지 포함 |
git stash push --staged | 스테이징된 변경만 stash |
git stash push --patch | 일부 hunk만 선택적으로 stash |
git stash branch recover stash@{0} | stash 생성 시점 기반 새 브랜치 생성 후 적용 |
추적되지 않은 파일까지 같이 치우고 싶을 때 -u를 빼먹는 경우가 흔합니다.
bash
git stash push -u -m "bugfix 전에 잠시 보관"추천 워크플로우
pop보다 apply가 안전할 때
- 오래된 stash를 다시 적용할 때
- 현재 브랜치가 많이 바뀌어 충돌 가능성이 높을 때
- 적용 결과를 먼저 확인한 뒤 버릴지 말지 결정하고 싶을 때
pop은 적용과 삭제를 한 번에 시도합니다.
충돌 가능성이 걱정되면 apply로 먼저 확인하고, 괜찮을 때 drop하는 습관이 더 안전합니다.
stash branch는 생각보다 강력하다
bash
git stash branch recover-login stash@{0}이 명령은 stash가 만들어졌던 시점을 기반으로 새 브랜치를 만들고, 그 stash를 적용합니다.
현재 브랜치에 바로 pop했다가 충돌이 심할 것 같을 때 특히 유용합니다.
흔한 안티패턴
| 안티패턴 | 문제점 | 더 나은 방식 |
|---|---|---|
| stash를 이름 없이 계속 쌓기 | 나중에 무엇인지 기억하기 어려움 | push -m 사용 |
untracked 파일이 있는데 그냥 git stash만 사용 | 일부 파일이 남아서 작업이 덜 치워짐 | 필요하면 -u 사용 |
오래된 stash를 바로 pop | 충돌 + 삭제가 동시에 얽힘 | apply 후 검토 |
| stash를 장기 보관소처럼 사용 | 맥락을 잃기 쉬움 | 장기 보관은 브랜치 또는 WIP 커밋 |
stash도 로컬 전용이다
reflog처럼 stash도 기본적으로 로컬 저장소 안에서만 관리됩니다. 다른 사람과 공유되는 작업 단위로 볼 수 없습니다.
.gitignore - 추적 제외 파일 설정
프로젝트에서 Git으로 관리할 필요가 없는 파일이나 폴더를 지정하는 설정 파일입니다.
왜 필요한가?
| 종류 | 예시 | 이유 |
|---|---|---|
| 빌드 결과물 | build/, dist/ | 소스코드만 있으면 재생성 가능 |
| IDE 설정 | .idea/, .vscode/ | 개인 환경 설정, 공유 불필요 |
| 의존성 | node_modules/ | npm install로 재설치 가능 |
| 환경 변수 | .env | 비밀번호, API 키 등 보안 위험 |
| 캐시 | .gradle/, __pycache__/ | 로컬 최적화 파일 |
.gitignore 작성법
프로젝트 루트에 .gitignore 파일을 생성합니다:
bash
# .gitignore 파일 예시
# 빌드 결과물
build/
dist/
# 의존성
node_modules/
# IDE 설정
.idea/
.vscode/
# 환경 변수
.env
.env.local
# OS 파일
.DS_Store
Thumbs.db
# 캐시
*.log.gitignore 자동 생성 서비스
toptal.com/developers/gitignore에서 프로젝트 기술 스택을 입력하면 자동으로 .gitignore를 생성해줍니다.
bash
# 예: Java + Gradle 프로젝트
# → java, gradle 입력 → 생성된 내용을 .gitignore에 복사Git Hooks - 자동화 스크립트
Git의 특정 이벤트(커밋, 푸시 등) 발생 시 자동으로 스크립트를 실행하는 기능입니다.
주요 Hook 종류
| Hook | 실행 시점 | 활용 예시 |
|---|---|---|
pre-commit | 커밋 직전 | 코드 린트, 테스트 실행 |
commit-msg | 커밋 메시지 작성 후 | 메시지 형식 검증 |
pre-push | 푸시 직전 | 전체 테스트 실행 |
post-commit | 커밋 직후 | 슬랙 알림 전송 |
pre-commit Hook 설정
bash
# .git/hooks/pre-commit 파일 생성
vim .git/hooks/pre-commit
# 내용 작성 (예: echo로 테스트)
# #!/bin/sh
# echo "커밋 전 검사를 실행합니다..."
# npm test
# 실행 권한 부여
chmod +x .git/hooks/pre-commitHook 공유 시 주의
.git/hooks/ 경로는 Git이 추적하지 않으므로 다른 사람과 공유되지 않습니다. 팀에서 동일한 Hook을 사용하려면:
- Hook 경로를 변경하는 설정을 적용하거나
- 예:
git config core.hooksPath .githooks - Husky 같은 라이브러리를 사용하거나
- README에 설정 방법을 문서화
Git Flow - 브랜치 관리 전략
팀에서 브랜치를 체계적으로 관리하기 위한 규칙(약속)입니다.
Git Flow 브랜치 구조
브랜치별 역할
| 브랜치 | 역할 | 수명 | 병합 대상 |
|---|---|---|---|
| master (main) | 실제 배포되는 안정 버전 | 영구 | - |
| develop | 다음 버전 개발 통합 | 영구 | - |
| feature/* | 개별 기능 개발 | 임시 | develop |
| release/* | 배포 전 최종 점검 | 임시 | master + develop |
| hotfix/* | 운영 중 긴급 버그 수정 | 임시 | master + develop |
개발자의 일반적인 작업 흐름
Git Flow는 정답이 아니다
Git Flow는 여러 브랜치 전략 중 하나입니다. GitHub Flow, GitLab Flow 등 다른 전략도 있으며, 각 팀의 개발 환경과 배포 주기에 맞게 선택하거나 변형하여 사용합니다.