[조사 미션 수행] Git Flow & Github Flow

[SeonHwan-Kim]

Git Flow

• feature > develop > release > hotfix > master
• 왼쪽으로 갈수록 포괄적인 가지, master branch를 병합할 경우 그 왼쪽에 있는 가지들에 있는 커밋들도 병합되도록 한다.

구조 및 흐름

• 가장 많이 사용되는 가지는 develop, master이다.
• 나머지는 사용하지 않을 경우 브랜치를 삭제해 깔끔하게 유지하고 필요할 때 다시 만들어준다.
• 대부분의 작업은 develop에서 취합하고, 확실하게 변동사항이 없을 때 master로 병합한다.
• master가 아닌 가지들은 항상 master의 변동사항을 주시해야한다.

Feature branch

• 가지가 뻗어나오는 곳 : develop
• 뻗어나간 가지가 다시 합쳐지는 곳 : develop
• 이름 설정 : master, develop, release-*, hotfix-*를 제외하면 자유로움
• 새로운 기능을 추가할 때 사용
• origin에는 반영하지 않고 주로 개발자의 repo에만 존재

Release branch

• 가지가 뻗어나오는 곳 : develop
• 뻗어나간 가지가 다시 합쳐지는 곳 : develop, master
• 이름 설정 : release-*
• 새로운 제품을 배포하고자 할 때 사용하는 가지
• 여태까지 개발한 기능들을 develop 가지에서 종합해 release 가지를 생성하고 develop에서는 다음번 배포를 위한 새로운 기능 개발에 주력하도록 만들 수 있다.
• release는 디버그에 대한 부분만 커밋하도록 하며, 완전히 배포에 대한 준비가 완료되었다고 판단되었을 때 master로의 병합을 진행한다.
• 병합을 끝내고 난 뒤에는 tag명령을 통해 배포 버전에 대한 기록을 남긴다. (추가적으로 병합한 사람에 대한 정보를 남기고자 할 때는 tag명령에 더해 -s, -u 옵션을 추가한다.)
• master로의 병합이 완료되었다면 develop로의 병합도 수행하며 이 때는 release에서 수정된 내용들이 develop에 반영된다.

Hotfix branch

• 가지가 뻗어나오는 곳 : master
• 뻗어나간 가지가 다시 합쳐지는 곳 : develop, master
• 이름 설정 : hotfix-*
• 제품에서 버그가 발생했을 경우에는 처리를 위해 이 가지로 해당 정보들을 모아준다. 버그에 대한 수정이 완료된 후에는 develop, master에 곧장 반영해주며 tag를 통해 관련 정보를 기록해둔다.
• release 가지가 생성되어 관리되고 있는 상태라면 해당 가지에 hotfix정보를 병합시켜 다음번 배포 시 반영이 정상적으로 이루어질 수 있도록 해준다.
• Hotfix는 보통 다급하게 버그를 고치기 위해 생성되는 가지이기 때문에 버그를 해결하면 보통 제거하는 일회성 가지다.

장점

• 명령어가 명료하게 나와있음
• 거의 모든 에디터들과 IDE들에 플러그인으로서 이미 존재하고 있다.

단점

• branch가 뻗어나가는 구조가 복잡하여 관리의 어려움이 있다.
• 몇몇 branch는 쓰이지 않을 경우가 있으며 또한 애매한 위치의 branch가 존재

---

Github Flow

• Git Flow 도 좋은 방식이지만 Github에 적용하기에는 복잡하여 새로 만들어진 깃 관리 방식
• 자동화 개념이 들어가 있다는 특징
• Git flow에 비해 흐름이 단순해짐에 따라 그 규칙도 단순해짐
• 기본적으로 master branch에 대한 규칙만 정확하게 정립되어 있으면 다른 가지들에 대해 특별히 관여하지 않고 pull request 사용을 권장

특징

• release branch가 명확하게 구분되지 않은 시스템에서의 사용이 유용하다.
• Github 자체의 서비스 특성상 배포의 개념이 없는 시스템으로 되어있기 때문에 이 flow가 유용
• 웹 서비스들에 배포의 개념이 없어지고 있는 추세이기 때문에 앞으로도 Git flow에 비해 사용하기에 더 수월할 것이다.
• hotfix와 가장 작은 기능을 구분하지 않는다. 대신 구분하는 것은 우선 순위가 어떤 것이 더 높은지에 대한 것이다.

사용법

1. master branch는 언제든지 배포 가능
   • master branch는 항상 최신의 상태를 유지하며 stable 상태로 product에 배포
   • 엄격하게 규칙 지정하여 사용
2. 새로운 일을 시작하고자 가지를 master에서 분화하면 무슨 일을 수행하는지 명확히 작성
   • feature나 develop 가지가 존재하지 않는다.
   • 브랜치 이름은 자세히 어떤 일을 맡고있는지에 대해 작성하는 것 권장
3. 원격 서버에 수시로 push 해준다.
   • Git Flow와 가장 차별화된 방식, 원격서버에 자신이 하고 있는 일들을 지속적으로 업로드 해 팀원들이 수월하게 확인 가능하도록 만든다.
   • 작업하던 내용이 다 날아가도 다시 작업내용 백업해 프로젝트 진행 가능
4. 피드백이나 도움이 필요할 때 PR을 생성한다.
   • PR은 코드 리뷰를 도와주는 시스템
   • PR을 통해 자신의 코드를 공유하고 피드백을 받을 수 있고, 병합 준비가 완료되면 master branch로 작업 내용을 반영하도록 할 수 있다.
5. 기능에 대한 리뷰와 결재가 끝난 후 master로 병합한다.
   • 모든 작업이 끝나고 product에 바로 반영이 되므로 프로젝트를 하는 사람들과 충분한 논의를 한 후 master branch에 반영한다.
6. master로 병합 후 push되었을 때는 즉시 배포 작업을 수행한다.
   • master branch로 병합이 일어나면 hubot을 이용해 자동으로 배포가 이루어지도록 설정해야한다.

장점

• branch 구성 전략이 단순하다.
• 처음 git에 대해 접근하는 사람에게 좋은 시스템이 되어준다.
• Github 사이트에서 제공해주는 기능을 모두 사용해 작업을 진행하게 도와준다.
• 코드리뷰를 자연스럽게 할 수 있다.
• CI가 필수적이며 또한 배포를 자동으로 진행할 수 있다.

단점

• CI와 배포 자동화가 되어있지 않은 시스템에서는 사람이 해당 업무를 진행해야한다.
• 프로젝트 규모가 커지면 관리하기 어려워진다.

출처
Git Flow와 GitHub Flow의 이해