Github로 협업하는 과정에서 사용한 우리 팀의 Git-Branch 전략

Github Repository

• 메인 브랜치: master, develop
• 보조 브랜치: feature, release, hotfix

실제 개발 기간이 짧았기 때문에 대부분의 작업은 develop과 feature에서 일어났다.

구조 자체는 전형적인 Git Flow 이다.

모든 작업은 이슈 생성에서 출발했고, GitHub Issue 템플릿을 만들어 두어서 담당자(Assignee)와 라벨을 지정할 수 있도록 했다. 이슈에 할 일을 체크리스트로 적어두면 나중에 PR에서 자동으로 연결된다.

이슈가 만들어지면 feature/<이슈번호-핵심> 형식으로 브랜치를 생성했다. GitHub의 "Create a branch" 버튼을 이용하면 UI에서 바로 만들 수 있다.

커밋 메시지에 #이슈번호를 붙이면 GitHub가 자동으로 이슈와 연결해 준다. 체크리스트에 맞춰 작업을 진행하고 완료한 항목은 바로 체크하도록 했다. 이렇게 해서 진행 상황을 팀 전체가 파악할 수 있었다.

작업이 끝나면 PR을 만들고, close #이슈번호 문구를 넣어 병합 시 이슈가 자동으로 닫히도록 했다. 라벨을 붙여놔서 어떤 종류의 변경인지 리뷰할 수 있도록 했다.

모든 기능이 모이면 실제 배포용 태그를 생성한다.

1. GitHub Releases에서 태그와 릴리스 노트를 작성
2. 포함된 이슈와 담당 멤버를 정리

• 추가로, Jenkins의 Branch Specifier를 tags/v1.0.0처럼 태그를 바라보도록 변경해서 릴리즈 배포를 진행했다.