Git 브랜치 전략

실무와 최대한 유사한 환경에서 개발을 해보는 것이 도움이 많이 될 것이기 때문에 git 전략에 대해 알아보게 되었다.(팀 프로젝트시 활용해봐야 겠다)

Git을 활용하는 것만 잘하면 되는 줄 알았지만, 실제 현업에서는 정해진 전략에 의해 Git을 사용한다고 한다.

만약 Git 전략이 특별히 없다면 어떤 브랜치가 무슨 기능을 하는지 헷갈리고 브랜치들이 규칙없이 난잡해지기 때문에 불필요하게 복잡해지게 된다.

알아보니 실무에서 활용되는 깃 전략은 크게 2가지가 있다.

 

 

Git-Flow 전략

 

5가지의 브랜치를 이용하는 전략으로 주기적으로 배포하는 서비스에 적합.

2개의 메인 브랜치, 3개의 보조 브랜치로 이루어진다. 여기서 보조 브랜치는 역할을 다하게 되면 삭제하는 게 원칙!

 

메인브랜치

• master : 실제 배포에 사용하는 브랜치
• develop : 다음 버전을 개발하는 브랜치

보조 브랜치

• feature : 기능 개발 브랜치 , 완료하면 develop에 mege한다.  ( ex feature/comment_fe )
• release : 이번 출시 버전 준비 브랜치 , develop 브랜치를 release 브랜치로 옮긴 후, QA, 테스트 진행하고 master에 merge한다.
• hotfix : 배포된 서비스에서 발견된 버그 수정 브랜치 ( 버그 수정이 완료되면 master와 develop에 merge)

진행 과정

1. develop 브랜치에서 기능을 개발하기 위한 feature 브랜치 생성
2. 기능이 완성되면 develop 브랜치에 merge 후 feature 브랜치 삭제
3. 이번 버전 기능이 모두 완료되면 QA(품질보증)을 위해 release 브랜치 생성
4. 오류 발생시 수정. QA 완료 시, 해당 버전을 배포하기 위해 master 브랜치로 merge 후 release 브랜치 삭제(이 때 수정사항이 있다면 develop 브랜치에도 merge)
5. master 브랜치에서 버그 발생 시, hotfix 브랜치 생성
6. 오류를 수정하고 master와 develop 브랜치에 merge 후 hotfix 브랜치 삭제

Github-Flow 전략

master 브랜치와 pr을 이용하는 전략, CI / CD 가 자연스럽게 이루어진다.

제품이 릴리즈되는 master 브랜치만 존재

 

진행 과정

1. 기능 개발, 오류 수정 등의 이유로 브랜치 생성. 이름은 의도를 드러낼 수 있게 짓기
2. 각 브랜치에서 개발.
3. pull request 보내기
4. 보낸 pr에 대한 충분한 리뷰과정
5. 실제 서버 or 테스트 환경에 배포
6. 이상이 없다면 master 브랜치로 merge 하고 배포(배포 자동화)