Git,GitHub
실무에서 바로 쓰는 Git·GitHub 협업 전략과 워크플로우 가이드
로기221
2025. 5. 29. 09:58
728x90
반응형
개발 도구 및 협업 툴 활용법 실무 가이드
1. Git, GitHub 브랜치 전략
대표적인 브랜치 전략
- GitHub Flow:
- main 브랜치에 항상 배포 가능한 코드를 유지.
- 새로운 기능이나 버그 수정은 feature/기능명처럼 별도 브랜치에서 작업.
- 작업 완료 후 Pull Request(PR)로 코드 리뷰를 받고, 승인 후 main에 병합 및 즉시 배포.
- 장점: 간단하고 CI/CD에 적합.
- 단점: 여러 버전 동시 지원에는 부적합.
- Git Flow:
- main, develop, feature/*, release/*, hotfix/* 등 다양한 브랜치로 역할 분리.
- 복잡한 프로젝트나 여러 버전 관리에 적합.
- GitLab Flow:
- GitHub Flow와 유사하지만, 환경별 브랜치(예: production, pre-production)나 release 브랜치 추가로 배포 관리 강화.
실무 브랜치 운영 팁
- 작업 전 항상 main(또는 develop) 브랜치에서 새로운 기능 브랜치를 생성.
- 브랜치 명명 규칙을 통일(예: feature/login, bugfix/payment-error 등).
- 기능별로 브랜치를 나누면 히스토리 관리와 코드 리뷰가 쉬워짐.
2. 협업 시 유용한 워크플로우
기본 협업 절차
- 저장소 Fork 및 Clone (필요시)
- main 또는 develop에서 작업 브랜치 생성
- 코드 작성 및 커밋
- 원격 저장소로 푸시
- Pull Request(PR) 생성 및 코드 리뷰 요청
- 리뷰 후 피드백 반영
- 승인되면 main(또는 develop)에 병합
- 병합 후 작업 브랜치 삭제 및 로컬/원격 동기화
실무 워크플로우 팁
- 작업 중간에 git pull로 최신 코드 반영
- 충돌 발생 시 신속히 해결 후 커밋
- PR에는 작업 내용, 의도, 참고 이슈를 명확히 작성
- 병합 후 작업 브랜치 정리(삭제)
3. 이슈 관리
- 이슈 생성 시: 명확한 제목과 설명, 라벨(예: bug, feature), 담당자 지정
- 이슈 할당: 팀원별로 역할 분담, 공개 저장소의 경우 주기적 이슈 리뷰 필요
- 이슈 자동 종료: 커밋 메시지나 PR 설명에 Closes #이슈번호 사용 시 병합과 동시에 자동 종료
- 이슈 정기 점검: 완료된 이슈는 즉시 닫아 관리 효율화
4. 코드 리뷰 실무 가이드
- PR 리뷰 시 체크리스트:
- 코드가 의도대로 동작하는지, 기존 코드와 잘 통합되는지 확인
- 복잡성, 네이밍, 주석, 테스트 코드, 문서화 등 점검
- 피드백은 구체적이고 건설적으로 작성
- 완벽만을 강요하지 말고, 개선과 배포 가능성의 균형 유지
- 리뷰어가 부족할 땐: 해당 분야 전문가를 초대해 리뷰 품질 확보
5. 커밋 메시지 작성법
- 기본 규칙:
- 제목(헤더)과 본문(옵션), 푸터(옵션)로 구성
- 제목은 50~72자 이내, 첫 글자 대문자, 마침표 금지, 명령문 사용
- 본문에는 변경 이유와 상세 설명, 관련 이슈 번호 등 추가
- 예시:
feat(login): Add OAuth2 login support Implemented Google and Kakao login using OAuth2. Closes #42
- 커밋 메시지 스타일:
- feat: 새로운 기능
- fix: 버그 수정
- docs: 문서 변경
- refactor, test, chore 등 유형 명시
6. 추가 실무 팁
- Pull Request 활용:
- PR마다 명확한 설명, 리뷰어 지정, 라벨 활용
- CI(자동 테스트) 연동으로 코드 품질 보장
- 정기적 코드/문서 정리:
- README, 개발 가이드 등 최신화
- 코드 일관성 유지 위한 코딩 컨벤션 공유
- 긍정적 피드백과 소통:
- 팀원 간 칭찬과 감사 표현, 열린 피드백 문화 조성
이상의 원칙과 팁을 적용하면, Git과 GitHub를 활용한 협업에서 효율적이고 체계적인 개발 문화를 구축할 수 있습니다.
728x90
반응형