[Git] Git 브랜칭 전략(2) Github-flow

📌 이번 글은

Git 브랜칭 전략 2탄 Github-flow 정리입니다.

Git 브랜칭 전략 1탄 보러 가기

[Git] Git 브랜칭 전략(1) Git-flow

 

Github-flow

• Git-flow 전략보다 단순한 브랜치 전략.
• master 브랜치 하나만을 가지고 진행하는 방식.

Github-flow 한눈에 보기

master 브랜치

• master 브랜치는 기능 구현, 오류 수정 사항 모두 master에 머지되어 항상 최신 상태를 유지합니다.

 

Github-flow 프로세스

1. 기능 구현이나 버그가 발생하면 issue 생성.
2. issue 담당자는 작업을 위해 master 브랜치에서 feature/{구현기능} 브랜치를 생성하여 작업.
   - feature 브랜치는 보통 개발자 저장소에만 있고, origin에는 push 하지 않습니다.
   - merge 된 후에 해당 브랜치는 삭제합니다.
3. 개발 완료 후에는 commit log 작성.
   - commit 메시지는 명확하게 작성합니다.
4. merge 준비가 완료되면 담당자는 pull request 생성.
5. pull request를 통해 팀원들과 코드 리뷰와 피드백 진행.
   - 이 과정이 꼼꼼히 진행되어야 합니다.
6. 리뷰가 완료되면, merge 하기 전에 배포를 통해 최종 테스트 진행.
7. 테스트까지 진행되면 master 브랜치에 merge.

 

Github-flow 특징

• 브랜치 전략이 단순해 master 브랜치 pull -> 기능 구현 -> merge 과정의 반복입니다.
• 하지만 pull request에서 팀원 간의 충분한 리뷰와 피드백 진행되지 않으면 배포 코드에 버그가 발생할 수 있으므로 주의해야 합니다.

 

 

🙋🏻‍♀️ 참고

git 브랜치 전략에 대해서

Git 브랜칭 전략 : Git-flow와 Github-flow