Git-flow

1. Git-flow?

• Git으로 형상관리를 할 때 브랜치를 효율적으로 관리하기 위해 사용하는 브랜치 관리 전략

2. 사용이유?

• 프로젝트의 규모가 커져서 팀원이 늘어났을 경우 누군가는 하루 종일 conflict를 해결해야하며, 이슈가 발생 했을 때 개발한 코드를 다시 되돌리고 이러한 과정에서 개발을 멈춰야하는 불편함을 최소화 하고 형상관리를 효율적으로 해결하기 위해!

3. Git Repository 구성

• Upstream Repository는 개발자들이 공유하는 저장소로 최신 소스코드가 저장되어 있는 원격 저장소입니다. Origin Repository는 Upstream Repository를 Fork한 원격 개인 저장소입니다. Local Repository는 내 컴퓨터에 저장되어 있는 개인 저장소입니다.
• 이런 워크플로우를 두는 데에는 한 가지 이유가 있었습니다. 그 이유는 개발자들의 실험정신(?)을 펼치기 위해서였습니다. 모두가 공유하고 있는 Repository에서 실험하기에는 위험이 있다고 생각했고, Forked한 Repository를 두면 부담 없이 원하는 실험들을 해볼 수 있다고 생각했습니다.

4. Git-flow 종류 & 전략

[항상 유지되는 메인 브랜치]

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

[일정 기간 동안만 유지되는 보조 브랜치]

• feature: 기능을 개발하는 브랜치
• 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 브랜치에서 버전 태그를 추가합니다.

5. Q&A

Q. 배포가 끝난 후에 작업 하며 생성한 feature 브랜치와 fork repository의 관련 브랜치들은 어떻게 관리하시나요?
A. fork repository의 작업 브랜치들은 Pull Request를 요청 후 merge와 함께 삭제합니다.
feature 브랜치 역시 develop 브랜치에 merge 되면 바로 삭제하고 있습니다.

Q. Pull Request 할때, 하나의 클래스를 몇명이서 수정하게되면 겹치게된다면 어떻게 되는가?
A. 저희는 되도록 코드 충돌이 발생하지 않도록 작업을 나누어서 진행을 합니다.
그래서 하나의 클래스를 여러 명이서 건들지 않도록 하고 있습니다.
작업을 나눌 때 같은 코드를 여려 명이 건드려야 한다면 작업자들끼리 이야기를 한 후 한 명이 먼저 작업을 처리 합니다.
그렇게 하더라도 간혹 코드 충돌이 발생하게 되는데요. 대부분 이 사실은 오전 티타임을 할 때나 코드리뷰를 할 때 알게됩니다.
코드 충돌 해결은 전적으로 뒤에 코드 병합을 하는 사람이 책임을 지게됩니다.
코드 충돌이 작으면 스스로 처리하지만, 코드 충돌 범위가 크면 작업 코드가 겹친 개발자와 함께 충돌 해결을 하고 있습니다.

Q. 버그 수정할 버그 티켓마다 꼭 브랜치를 생성해야하는지, 그리고 그로인한 장점?
A. 우아한 형제들은 티켓마다 브랜치를 생성한 후 하나의 작업만을 수행한다. 이는 몇가지 장점이 존재

• 첫째, 하나의 티켓에 하나의 작업만 진행하기 때문에 코드의 변경이 무분별하게 일어나지 않습니다.
• 둘째, 리뷰어들이 코드 리뷰를 할 때 의도를 파악하기 쉽습니다.
• 셋째, 불가피하게 작업 전환을 해야할 때 쉽게 작업을 전환할 수 있고, 시간이 어느정도 지난 후 다시 원래 작업으로 되돌아가도 작업을 이어가기가 좀 더 수월
• 넷째, 티켓과 작업을 연결되어 어떤 버전에 작업이 포함됐는지 파악하기 쉽고, 그 당시 히스토리를 추척하는데 도움이 된다.

활용해보기

• https://danielkummer.github.io/git-flow-cheatsheet/index.ko_KR.html

출처

• https://techblog.woowahan.com/2553/