Git 사용 규칙 - Git 브랜치

Git을 이용하여 소프트웨어 개발을 시작한지도 몇 년이 되었다. 

그 동안 Git을 사용해 오면서 Git 커밋 이나 브랜치 규칙(여기서 브랜치 규칙이란 개인적으로 Git-flow, Github-flow 등과 같은 개념을 의미한다)은 이것저것 도입해 사용해 보았으나, 명시적으로(문서 상으로) 규칙을 정해 놓지 않은 관계로, 상황이나 시간의 변화에 따라 때로는 일관된 규칙을 적용하지 못하였다.

곧 시작할 새로운 중요 개발 프로젝트를 본격적으로 시작하기 전에 Git을 어떻게 잘 사용할지에 대해 다시 한번 정리해 보고자 한다. 

그 중에서도 본 글에서는 브랜치를 어떻게 관리할 것인지에 대한 브랜치 규칙에 대해 정리한다. 

개발 환경

회사의 특성 상, 내 개발 환경은 다음과 같은 특징을 가진다.

• 대부분의 프로젝트를 혼자서 진행한다.
• 아주 가끔 나를 포함해서 2명이서 개발을 진행한다.
• 소프트웨어 개발에 대한 프로젝트 관리도 내가 직접 한다.
• 별도의 QA는 없다.
• 결국, 프로젝트 관리, 사양 설계, 개발, 테스트, 기술지원을 모두 혼자 수행한다. (때로는 기획까지도)
• 항상 구동/운영 되어야 하는 서비스를 개발하지는 않는다.
• 개발된 소프트웨어는 B2B 타겟이며, 해당 소프트웨어를 도입한 기업은 이를 이용하여 자체적인 제품 생산이나 서비스를 제공한다.
• 소프트웨어 개발 진행 중에 주기적으로 또는 주요 기능 추가 시, 기업으로 배포한다.
• 소프트웨어 버그나 기능추가 등의 피드백은 대부분 소프트웨어 도입 기업으로부터 받는다.

고려 사항

브랜치 규칙을 결정하기 위해 다음과 같은 사항을 고려한다.

• 기본적으로 일반적인 개발(기능 추가, 버그 수정 등)은 항목별로 브랜치를 생성해서 작업해야 한다.
• 유닛테스트는 각 개발 브랜치에서 수행해야 한다. 즉, 유닛테스트가 완료된 후에 주 브랜치로 병합을 수행한다.
• 배포 전 인수테스트(컴포넌트 테스트 또는 시스템 테스트)를 별도의 브랜치에서 수행한다. 인수테스트에서 발생한 수정사항은 해당 브랜치에서 작업한다.
• 배포 버전은 Tag로 관리하며, 배포 버전용 브랜치를 유지한다. 해당 브랜치에는 배포된 버전의 커밋만 존재한다.
• 배포 버전에 대한 피드백(긴급한 버그 수정 등)은 별도의 브랜치에서 작업 후 재배포한다. 작업 시 전체 유닛테스트와 인수테스트가 수행되어야 한다.
• 배포버전은 모든 유닛테스트와 인수테스트를 통과해야 한다.

고려사항을 적어 놓고 보니, 혼자서 일하기는 하지만 결국 Git-flow를 적용해야 할 것으로 보인다.

(그래서 결정한) 브랜치 규칙 (결국 Git-flow)

브랜치 규칙은 기본적으로 Git-flow를 따르며, 필요에 따라 temp/* 브랜치를 추가하였다.

아래 각 브랜치에 대한 설명은 작업 흐름에 맞는 순서로 정리하였다.

• develop 
• 개발 이력을 기록하는 주요 브랜치
• dev/*, release, hotfix 브랜치에서 작업된 결과는 모두 이 브랜치로 병합(merge)된다.
• 각 항목별 개발(기능 추가/수정/삭제, 버그 수정 등) 진행을 위해 본 브랜치에서 dev/* 브랜치로 분기된다.
• 배포를 위해 본 브랜치에서 release 브랜치로 분기된다.

• dev/{Description} 
• 각 항목별 개발(기능 추가/수정/삭제, 버그 수정 등) 진행 시, develop 브랜치로부터 분기하여 작업한다. 
• {Description} : 개발 항목을 잘 식별할 수 있는 문구
• 유닛테스트까지 완료 후 develop 브랜치로 병합(merge)한다.
• 작업 중 develop 브랜치에 변경사항이 있으면, develop 브랜치를 먼저 병합(merge) 후 작업한다.

• release
• 주요 기능의 추가나 버그 수정이 완료되어 배포하고자 할 때, develop 브랜치로부터 분기한다.
• 본 브랜치에서는 인수테스트를 수행하고, 그 결과에 의한 버그 수정을 수행한다.
• 인수테스트 완료 후, develop 브랜치와 master 브랜치로 각각 병합(merge)한다.
• 작업 중, 기존 배포버전에서 hotfix가 발생하면 hotfix 먼저 작업 후, hotfix 브랜치를 본 브랜치에 병합하여 다시 작업한다. 모든 유닛테스트와 인수테스트를 처음부터 재수행한다.

• master
• 배포될 소프트웨어가 기록되는 브랜치
• 인수테스트가 완료된 release 브랜치가 본 브랜치로 병합(merge)된다.
• Tag로 버전을 부여하고 Release note 작성 후(Github 및 로컬 디렉터리), 배포한다. 
• 배포 버전에 대한 피드백(긴급한 버그 수정)이 들어오면, 본 브랜치의 해당 버전에서 hotfix 브랜치로 분기하여 작업 후 다시 병합(merge)된다 -> 새로운 버전으로 재배포된다.
• (참고) 배포 버전에 대한 피드백이 들어올 당시, develop 브랜치의 최신상태가 배포버전과 동일하면 hotfix가 아닌 develop 브랜치에서 dev/* 브랜치로 분기하여 피드백을 적용한다.

• hotfix
• 배포 버전에 대한 피드백(긴급한 버그 수정 등)에 대한 작업을 수행하기 위해 master 브랜치로부터 분기되는 브랜치
• 본 브랜치에서 피드백 적용 후 모든 유닛테스트와 인수테스트를 재실행한다.
• 테스트 완료 후, master 브랜치 및 develop 브랜치에 병합(merge)된다.

• temp/{Description}
• 임시로 기능을 추가하거나, 1회성 수정 등을 적용하고자 할 경우, develop 브랜치로부터 분기하여 작업한다.
• {Description} : 개발 항목을 잘 식별할 수 있는 문구
• 본 브랜치에서 작업된 내용은 다시 develop 브랜치로 병합(merge)되지 않는다. 
• 배포버전에 포함되어야 하는 개발항목은 본 브랜치에서 작업할 수 없다.
• 유닛테스트 수행 여부는 상황에 따라 결정한다.

• 브랜치는 삭제하지 않는다. 

• 브랜치 병합 시 rebase 대신 merge를 수행한다. (브랜치 트리구조가 남아 있도록)

다음은 일반적인 Git-flow를 설명하는 그림이다. 

(출처: 구글검색 또는 https://lucamezzalira.com/2014/03/10/git-flow-vs-github-flow/)

그림 중 "feature" 브랜치를 "dev/*" 브랜치로 이름만 대체하고, "temp/*" 브랜치를 추가하면 된다. (제대로 된 그림은 나중에 업데이트..)