Git 브랜치 전략과 효과적인 코드 리뷰 방법

[Git 브랜치 전략의 종류]

# Git Flow

• master: 제품 출시용 브랜치
• develop: 개발 브랜치, 다음 출시 버전을 위한 코드가 여기 모임
• feature: 새 기능 개발용 브랜치, develop에서 분기해서 개발 후 다시 develop에 병합
• release: 출시 준비용 브랜치, develop에서 분기해서 출시 준비 후 master와 develop에 병합
• hotfix: 긴급 버그 수정용 브랜치, master에서 분기해서 수정 후 master와 develop에 병합

장점: 역할이 명확하게 구분됨, 대규모 프로젝트에 적합

단점: 브랜치 구조가 복잡함, 소규모 프로젝트에는 오버헤드 발생 가능

# GitHub Flow

• main(master): 항상 배포 가능한 상태 유지
• feature: 기능 개발용 브랜치, PR을 통해 main에 병합

장점: 단순한 구조, CI/CD에 적합

단점: 복잡한 버전 관리에는 부족

# GitLab Flow

• main(master): 개발 브랜치
• production: 배포 브랜치
• feature: 기능 개발용 브랜치
• 환경별 브랜치: staging, pre-production 등

장점: 환경별 브랜치로 배포 프로세스 세밀 제어 가능

단점: Git Flow보다는 단순하지만 여전히 복잡함

 # Trunk-Based Development

• trunk(main): 모든 개발이 이루어지는 메인 브랜치
• feature branches: 짧은 수명의 임시 브랜치, 빠르게 trunk에 병합

장점: 통합이 빈번해 병합 충돌 적음, CI/CD에 최적화 단점: trunk 품질 관리가 중요, 자동화된 테스트 필수

 

---

[브랜치 전략 선택 시 고려사항]

• 팀 규모와 구성
• 제품 출시 주기
• 버전 관리의 복잡성
• CI/CD 파이프라인 구성
• 팀의 경험과 선호도

---

[효과적인 코드 리뷰 방법]

리뷰 범위와 시간 관리

• 200-400줄 이하의 코드를 한 번에 리뷰
• 하루 60분 이상 리뷰하지 않기
• 기능적 측면과 구조적 측면 분리해서 리뷰

건설적인 피드백 제공

• "왜"와 "어떻게"에 초점
• 코드 자체에 대해 이야기하기
• 개선 방향 제시하기
• 긍정적인 부분도 언급하기

리뷰 체크리스트

• 요구사항 충족 여부
• 코드 이해도
• 테스트 포함 여부
• 성능과 보안
• 중복 코드
• 명확한 네이밍

---

[코드 작성 팁]

리뷰하기 좋은 PR 만들기

• PR 설명에 목적, 변경사항, 테스트 방법 기술
• 작은 단위로 PR 분리
• UI 변경사항은 스크린샷/GIF로 보여주기
• 관련 이슈 링크 포함

피드백 수용하기

• 열린 마음으로 수용
• 이해 안 되는 부분은 추가 설명 요청
• 의견 차이는 논리적으로 설명

★ 셀프 리뷰 습관화

• 불필요한 console.log, 주석 제거
• 코드 포맷팅 확인
• 변경된 파일 목록 확인
• diff 뷰로 재검토

 

[코드 리뷰 자동화 도구]

• ESLint, Prettier (린팅)
• SonarQube, CodeClimate (정적 분석)
• Codecov, Coveralls (코드 커버리지)
• GitHub Actions, Jenkins (CI/CD)