Version Control
버전 관리
코드 변경 이력 추적. Git이 표준. 협업의 기반.
버전 관리
코드 변경 이력 추적. Git이 표준. 협업의 기반.
버전 관리(Version Control)는 파일의 변경 이력을 추적하고 관리하는 시스템입니다. 1972년 SCCS(Source Code Control System)에서 시작되어, CVS, Subversion을 거쳐 현재는 Git이 사실상 표준입니다. 2005년 리누스 토발즈가 Linux 커널 개발을 위해 Git을 만들었습니다.
버전 관리의 핵심 개념은 커밋(Commit), 브랜치(Branch), 머지(Merge)입니다. 커밋은 특정 시점의 스냅샷이고, 브랜치는 독립적인 개발 라인입니다. 브랜치를 사용해 새 기능을 격리된 환경에서 개발하고, 완료되면 메인 브랜치에 머지합니다.
분산 버전 관리(DVCS)인 Git은 모든 개발자가 전체 히스토리를 로컬에 가집니다. 네트워크 없이도 커밋, 브랜치 생성, 히스토리 조회가 가능하고, 중앙 서버 장애에도 복구가 쉽습니다. GitHub, GitLab, Bitbucket이 Git 호스팅과 협업 기능을 제공합니다.
실무에서는 Git Flow, GitHub Flow, Trunk Based Development 등의 브랜칭 전략을 사용합니다. Pull Request(Merge Request)로 코드 리뷰를 수행하고, CI/CD와 연동해 자동 테스트와 배포를 실행합니다. 의미 있는 커밋 메시지와 atomic commit이 협업의 핵심입니다.
# Git 기본 워크플로우
# 저장소 초기화/클론
git init
git clone https://github.com/org/repo.git
# 상태 확인
git status
git log --oneline --graph -10
# 기능 브랜치 생성 및 작업
git checkout -b feature/user-auth
git checkout -b feat/JIRA-123-login-api # JIRA 연동 시
# 변경사항 스테이징 및 커밋
git add -p # 변경사항 부분 선택
git add src/auth/
git commit -m "feat: implement JWT authentication
- Add JWT token generation and validation
- Configure token expiration to 24 hours
- Add refresh token rotation
Closes #123"
# 원격 저장소와 동기화
git fetch origin
git rebase origin/main # 최신 main 위에 rebase
git push origin feature/user-auth
# Pull Request 생성 후 머지
# (GitHub/GitLab UI에서 리뷰 및 승인)
git checkout main
git pull origin main
git branch -d feature/user-auth # 로컬 브랜치 삭제
# 유용한 명령어들
git stash # 임시 저장
git stash pop # 복원
git cherry-pick abc123 # 특정 커밋만 가져오기
git revert abc123 # 커밋 되돌리기 (히스토리 유지)
git reset --soft HEAD~1 # 직전 커밋 취소 (변경사항 유지)
# 브랜치 전략 예시 (GitHub Flow)
# main: 항상 배포 가능한 상태
# feature/*: 기능 개발
# hotfix/*: 긴급 버그 수정
# .gitignore 예시
cat << 'EOF' > .gitignore
# Dependencies
node_modules/
vendor/
# Build output
dist/
build/
*.pyc
# Environment
.env
.env.local
*.local
# IDE
.idea/
.vscode/
*.swp
# OS
.DS_Store
Thumbs.db
# Logs
*.log
logs/
# Test coverage
coverage/
.nyc_output/
EOF
# Conventional Commits 형식
# feat: 새 기능
# fix: 버그 수정
# docs: 문서 변경
# style: 코드 포맷팅
# refactor: 리팩토링
# test: 테스트 추가/수정
# chore: 빌드/설정 변경
시니어: "feature 브랜치가 너무 오래 살아있으면 충돌 해결하기 힘들어요. 작은 단위로 자주 머지하는 게 나아요."
주니어: "아직 기능이 완성 안 됐는데 머지해도 되나요?"
시니어: "Feature Flag 쓰면 돼요. 코드는 main에 있지만 플래그로 비활성화하면 유저한테 안 보여요."
면접관: "Git 충돌 해결 경험을 설명해주세요."
지원자: "git rebase 중 충돌이 발생하면 충돌 파일을 열어 두 변경사항의 의도를 파악합니다. 단순 텍스트 충돌은 직접 수정하고, 로직 충돌은 해당 코드 작성자와 논의합니다. VSCode의 3-way merge 뷰어나 git mergetool을 사용하면 시각적으로 해결하기 편합니다."
리뷰어: "커밋 메시지가 'fix bug'만 있네요. 뭘 왜 수정했는지 적어주세요."
개발자: "fix: prevent duplicate user registration 으로 수정하고, body에 원인과 해결 방법 적겠습니다."