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
merge와 rebase는 히스토리 모양의 선택입니다
merge
브랜치가 갈라졌다 합쳐진 기록을 남깁니다. 팀 협업에서 기본으로 쓰기 안전합니다.
rebase
내 커밋을 최신 기준선 위에 다시 얹어 히스토리를 일직선으로 정리합니다. 공유 전 로컬 브랜치 정리에 적합합니다.
git merge feature/login현재 브랜치에 feature/login 변경 병합git rebase main현재 브랜치 커밋을 main 최신 커밋 뒤로 재배치git rebase --abortrebase 중 문제가 커지면 시작 전으로 되돌리기금지선
main, develop처럼 팀이 함께 쓰는 브랜치를 rebase하지 마세요. 이미 공유된 히스토리를 다시 쓰면 팀원의 로컬 이력과 충돌합니다.
체크