[git] branch 전략 - git flow

프로젝트 때 사용한 branch 전략

• 톡딱 팀 서버파트에서 사용한 branch 전략은 잘 알려진 git flow보다는 간략하게 구성했습니다.
  

  

• master : 제품으로 출시될 수 있는 브랜치
• develop : 다음 출시 버전을 개발하는 브랜치
• feature : 기능을 개발하는 브랜치

각자 feature 브랜치를 추가하여 기능 개발 후 develop에서 merge하여 push하는 방식으로 진행했습니다.

간략하게 구성한 이유는 저 포함하여 팀원 모두가 협업은 처음이었기 때문입니다.

pull request 사용에 미숙한 점도 있었고 그로 인한 충돌이 개발 시간을 많이 잡아먹을 것으로 판단하여 간략하게 구성해봤습니다.

문제점 : 커밋 그래프의 복잡함

• rebase를 해야 커밋 그래프를 단순화시킬 수 있다!
• rebase vs merge

---

우아한형제들에서 사용하는 git flow와 차이점

Upstream Repository를 Fork한 Orgin Repository가 추가되어있습니다.

Orgin Repository에서 pull request를 생성하고 코드리뷰를 거친 후 merge를 한다고 합니다.

이유는 다음과 같습니다.

• 모두가 공유하는 Repository에 실험하기에는 위험이 있다고 판단
• Fork한 Repository를 두면 부담없이 원하는 실험들을 해볼 수 있다고 판단

release와 hotfix 브랜치가 추가됩니다.

• release : 이번 출시 버전을 준비하는 브랜치

hotfix : 출시 버전에서 발생한 버그를 수정하는 브랜치

일반적인 개발 흐름

처음에는 master와 develop 브랜치가 존재합니다.

• develop 브랜치 : master에서부터 시작된 브랜치

develop 브랜치에서는 상시로 버그를 수정한 커밋들이 추가됩니다.

새로운 기능 추가 작업이 있는 경우 develop 브랜치에서 feature 브랜치를 생성합니다.

• feature 브랜치 : develop에서부터 시작된 브랜치

기능 추가 작업이 완료되었다면 feature 브랜치는 develop 브랜치로 merge됩니다.

develop에 이번 버전에 포함되는 모든 기능이 merge 되었다면 QA를 하기 위해 develop 브랜치서부터 release 브랜치를 생성합니다.

QA를 진행하면서 발생한 버그들은 release 브랜치에 수정됩니다.

QA를 무사히 통과했다면 release 브랜치를 master와 develop 브랜치로 merge합니다.

마지막으로 출시된 master 브랜치에서 버전 태그를 추가합니다.

팀원들과의 작업 간 약속은 다음과 같습니다.

1. 작업을 시작하기 전에 JIRA 티켓을 생성합니다.
2. 하나의 티켓은 되도록 하나의 커밋으로 합니다.
3. 커밋 그래프는 최대한 단순하게 가져갑니다.
4. 서로 공유하는 브랜치의 커밋 그래프는 함부로 변경하지 않습니다.
5. 리뷰어에게 꼭 리뷰를 받습니다.
6. 자신의 Pull Request는 스스로 merge 합니다.

 

출처

우아한 형제들 gt flow