1. Workflow 필요성
팀원들과 프로젝트를 진행하면 필연적으로 git을 사용합니다. 협업을 위해서 브랜치 규칙을 정해야하고, 이를 'git branch strategy'라고 합니다. 만약 규칙을 정하지 않았다면 "어느 브랜치에 푸시히야되지?", "버그가 있어 수정해야되는 어느 브랜치에서 pull해야 되지?", "배포 최신 버전이 어디지?"와 같은 고민이 생깁니다.
즉 여러명이서 git을 '효율적으로' 사용하고 싶어 다양한 'work flow'가 존재합니다. 'git-flow', 'github-flow', 'gitlab-flow' 등이 있습니다.
2. git flow
항상 유지되는 메인 브랜치 (master, develop)와 일정 기간 유지되는 보조 브랜치 (feature, release, hotfix)가 있습니다. 구조가 복잡하지만 주기적으로 배포하는 서비스에 유용합니다.
[1] git-flow branch 종류
- master :언제나 실행 가능한 상태로 있어야하며, 버전별 배포된 커밋들이 존재합니다.
- develop : 실질적인 개발이 이루어지는 브랜치입니다. 특정 기능을 개발할 때마다 feature 브랜치를 만들어 진행하고, 그 외에 버그와 같은 특정 기능에 속하지 않는 것들은 develop 브랜치 내에서 브랜치 없이 처리합니다. 주어진 기능이 모두 완성되면 즉, 배포할 시점이 되면 release 브랜치를 생성하여 QA를 진행합니다.
- feature : 특정 기능을 개발하는 브랜치입니다. 기능 개발이 완성되면 develop 브랜치에 병합합니다.
- release : 출시를 준비하는 브랜치입니다. release 브랜치를 만들고 발생하는 QA 버그, 문서 수정 등은 release 브랜치 내에서 처리합니다. 수정 후 바로바로 develop 브랜치에 병합하는데 나중에 몰아서 병합할 경우 많은 충돌을 방지하기 위해서입니다. 이후 QA 등 모든 작업이 끝나면 master, develop 브랜치에 각각 병합하고 이때 tag 기능으로 버전을 기록합니다.
- hotfix : 출시 버전에서 발생한 긴급 버그를 수정하는 브랜치입니다. 출시 버전에서 긴급하게 수정할 버그는 hotfix 브랜치에서 수정 후 master, develop 브랜치에 각각 병합합니다.
[2] git-flow 이미지
[3] git-flow scenario
- 처음에 master 브랜치에서 develop branch를 생성합니다. 앞으로 master, develop 브래치는 항상 유지합니다.
- develop 브랜치에서 상시로 버그를 수정한 커밋들을 추가됩니다.
- 새로운 기능 추가 작업은 항상 develop 브랜치에서 feature 브랜치를 생성 후 처리합니다. 기능 추가 작업이 feature 브랜치에서 완료되면 develop 브랜치로 merge합니다.
- develop 브랜치에 이전 버전에 포함되는 모든 기능이 merge되면 QA를 위해 develop 브랜치에서부터 release 브랜치를 생성합니다. QA과정에서 발생하는 버그 등을 release 브랜치에서 처리합니다. 수정할때마다 develop 브랜치에 merge합니다.
- QA 과정이 완성되면 releaes 브랜치를 master와 develop 브랜치로 merge 합니다.
- 이후, master 브랜치에서 version tag를 추가합니다. 만약, 버그 발생시 hotfix 브랜치에서 처리 후 master, develop 브랜치로 각각 merge합니다.
[4] 장단점
- 브랜치로 프로젝트의 전반적 흐름을 알 수 있습니다. 마스터 브랜치에 있는 버전 태그로 배포된 버전을 쉽게 파악 할 수 있고, develop 브랜치로 개발 중인 코드를 쉽게 파악할 수 있습니다. 즉, 브랜치별로 역할을 나누어 빠르게 파악이 가능합니다.
- 웬만한 에디터, IDE에 플러그인이 존재합니다.
- 브랜치가 많아 복잡합니다. git에 익숙치 않는 팀원은 git-flow를 사용하는데 어려움이 있을 수도 있습니다.
- 안 쓰는 브랜치가 생길 수 있기 때문에 보조 브랜치의 역할을 다하면 삭제 해줘야합니다. 이때, 커밋 기록을 확인하기 위해서 branch간 fast-forward merge시 --no--ff (no fast-fowrd)옵션을 이용하여 git 기록을 남기는것을 권장합니다.
3. github flow
master 브랜치와 PR을 활용한 단순 브랜치 전략입니다.
master 브랜치에서 기능 추가, 버그가 생길 때마다 Feature 브랜치를 따서 개발합니다. 기능 개발이 완료되면 PR을 올리고, 리뷰를 받고, QA를 거친 후 최종적으로 배포 가능 상태가 완료되면 master 브랜치로 병합합니다.
[1] github-flow 특징
마스터 브랜치는 언제나 배포가 가능한 상태입니다.
master 브랜치는 항상 최신 상태이며 product에 배포되는 브랜치입니다. 따라서, 새로운 branch에서 master 브랜치로 merge 하기 전에 충분한 테스트를 거칩니다.
마스터 브랜치에서 새로운 기능을 개발한다면 이름이 명확해야합니다.
새로운 기능을 추가하거나, 버그를 해결하기 위한 브랜치 이름은 자세하게, 그리고 커밋 메시지 역시 명확하게 작성해야합니다. git-flow와 다르게 브랜치를 좀 더 상세히 구분하지 않기 때문입니다.
원격 브랜치에 수시로 push 해야 합니다.
git-flow와 가장 상반되는 방식입니다. 항상 원격 서버에 자신이 하고 있는 일들을 올려 다른 사람들도 확인할 수 있도록 해야합니다. 이유는 브랜치의 역할을 상세히 구분하지 않기 때문입니다.
pull & request를 적극 활용합니다.
기능 개발 중 피드백이 필요할 때, 그리고 merge 준비가 완료될 때 pull & request를 생성합니다. 마스터 브랜치에 merge되면 곧장 product로 반영이 될 기능이므로, 팀원간 충분한 소통이 필요합니다. 물론 QA 과정 역시 통과 되어야 합니다.
[2] github flow scenario
- 신규 기능 개발시 Feature 브랜치를 생성하고 작업합니다.
- 궁금한 점, 논의할 점, 개발이 완료될 때 PR을 날리고 리뷰를 받아 master 브랜치에 merge 합니다.
- 단, master 브랜치에 merge할 때 충분한 QA 과정을 거치고 병합하며, 사용했던 브랜치는 삭제합니다.
- master 브랜치에 병합할 때 '자동화', CI/CD 사용을 권장합니다.
[3] 장단점
- 브랜치 전략이 단순하여, 처음 git을 접하는 개발자에게 유용합니다.
- pull & request 때문에 코드 리뷰를 자연스럽게 사용할 수 있습니다.
- CI(지속적 통합)이 필수적이며 CD(지속적 배포)에도 유용합니다. 다만 배포가 자동화 되있지 않다면 수동으로 해야합니다.
- 큰 규모 서비스, 즉, 주기적으로 배포하는 서비스에는 적합하지 않습니다.
[4] github flow 이미지
