Working Directory
아직 커밋 후보가 아닌 실제 파일 변경입니다.
이 파트에서 다루는 내용
CH 08 Git 핵심 개념 - SVN과 1:1 비교CH 09 branch 전략CH 10 merge vs rebase
01
Git은 세 영역을 거칩니다
SVN에서 작업 파일을 수정하고 commit하면 바로 서버로 올라갔습니다. Git은 Working Directory, Staging Area, Local Repository를 거칩니다.
Staging Area가 있기 때문에 수정한 파일 중 일부만 골라 커밋할 수 있습니다. 이게 Git 커밋을 작고 명확하게 만드는 핵심입니다.
Staging Area
이번 커밋에 포함할 변경만 고르는 임시 영역입니다.
Local Repository
커밋이 저장되는 로컬 저장소입니다. push 전까지 원격에는 없습니다.
02
브랜치 전략은 팀 규모와 배포 방식에 맞춥니다
GitHub Flow
- main은 항상 배포 가능
- feature 브랜치에서 작업
- PR 리뷰 후 main에 merge
Git Flow
- main/develop 분리
- feature/release/hotfix 사용
- 정기 릴리즈가 있는 조직에 적합
Trunk-Based
- 작은 변경을 자주 main에 통합
- 자동 테스트가 강해야 안전
- 장기 브랜치를 피함
추천 시작점
소규모 팀이나 학습용 프로젝트는 GitHub Flow로 충분합니다. 규칙이 복잡하면 Git보다 규칙을 지키는 데 에너지를 쓰게 됩니다.
03
운영 담당자는 저장소 규칙을 먼저 고정합니다
팀 Git 저장소를 만든다는 것은 원격 저장소 URL만 공유하는 일이 아닙니다. 기본 브랜치, 보호 규칙, 리뷰 기준, 릴리스 태그, CI 필수 통과 여부를 먼저 정해야 팀원이 같은 기준으로 작업합니다.
특히 main이나 release 브랜치는 직접 push를 막고 PR 리뷰와 자동 검증을 거치게 두는 편이 안전합니다. 규칙은 GitHub, GitLab, Bitbucket 같은 플랫폼 설정과 팀 문서에 함께 남겨야 합니다.
기본 브랜치
main, develop, release 중 어떤 브랜치가 배포 기준인지 고정합니다. 팀원이 작업을 시작할 기준선이 흔들리면 충돌과 누락이 늘어납니다.
보호 규칙
직접 push 금지, 최소 리뷰 수, 필수 CI 통과, force push 금지 여부를 정합니다. 플랫폼 UI에서 설정하지만 팀 규칙으로도 문서화해야 합니다.
릴리스 태그
배포 버전은 태그 이름, 커밋 해시, 배포 일시, 산출물 위치가 연결되어야 장애 추적과 롤백 기준으로 쓸 수 있습니다.
git remote -v팀원이 바라보는 원격 저장소 URL 확인git branch -vv로컬 브랜치와 upstream 연결 상태 확인git ls-remote --heads origin원격 브랜치 목록을 로컬 checkout 없이 확인git tag -a v1.0.0 -m "release: v1.0.0"검증된 커밋에 릴리스 태그 생성git push origin v1.0.0릴리스 태그를 원격 저장소에 공유구축 기준
Git 운영 담당자의 일은 브랜치를 많이 만드는 것이 아니라, 팀원이 어느 브랜치에서 시작하고 어떤 검증을 통과해야 합쳐지는지 헷갈리지 않게 만드는 것입니다.
04
merge와 rebase는 히스토리 모양의 선택입니다
merge
브랜치가 갈라졌다 합쳐진 기록을 남깁니다. 팀 협업에서 기본으로 쓰기 안전합니다.
rebase
내 커밋을 최신 기준선 위에 다시 얹어 히스토리를 일직선으로 정리합니다. 공유 전 로컬 브랜치 정리에 적합합니다.
git merge feature/login현재 브랜치에 feature/login 변경 병합git rebase main현재 브랜치 커밋을 main 최신 커밋 뒤로 재배치git rebase --abortrebase 중 문제가 커지면 시작 전으로 되돌리기금지선
main, develop처럼 팀이 함께 쓰는 브랜치를 rebase하지 마세요. 이미 공유된 히스토리를 다시 쓰면 팀원의 로컬 이력과 충돌합니다.
체크