반응형
Git flow
흐름
- develop을 base로 feature를 생성하고 작업을 진행한다.
- feature 작업이 완료되면 develop에 merge 한다.
- develop에서 목표로 하던 작업이 끝나면 release를 생성한다.
- release를 기준으로 QA & bugfix를 진행한다.
- release를 master로 merge 한다. (release에 수정 사항이 있었다면 develop에도 merge 한다.)
- master에 급하게 수정해야 할 이슈가 발생했다면 hotfix 생성 후 작업한다.
(작업 후 master, develop에 각각 merge 한다.)
특징
- master & develop은 항상 유지되고, 나머지 branch들은 필요에 의해 만들어졌다가 사라지길 반복한다.
- master와 develop은 항상 sync 상태로 유지한다.
- 가장 작업이 활발하게 이루어지는 branch는 develop이다.
- 여러 버전을 서비스하는 시스템에 유리하다.
- 병합 지옥을 비교적 효과적으로 컨트롤할 수 있다.
Ref
Github flow
흐름
- master에서 feature 생성 후 작업한다.
- feature는 master와 분리되어있어 안전하게 작업할 수 있다.
- 작업 시 중간중간 remote로 commit을 push 해준다.
- 작업 완료 후 PR을 요청한다.
- PR 요청 시엔 요약, 변경 사항 등을 포함한다.
- 피드백 적용 후 master merge 전 테스트를 진행한다.
- PR을 master에 merge 한다. (merge 후 feature는 삭제한다.)
특징
- master의 모든 commit은 배포 가능해야 한다.
- 체계적인 branch 분류가 없기 때문에 Feature branch naming에 보다 신경 써야 한다.
- Feature들과 진행 중인 작업 리스트가 거의 일치함 (즉, Feature를 보고 진행중인 작업 상황을 파악할 수 있다)
- local commit을 remote에 지속적으로 push 하기 때문에 다른 개발자들이 remote에서 서로의 진행 상태를 파악할 수 있다.
- 배포가 잦은 시스템에 적합한 워크플로우 이므로 master merge 후 자동 배포되도록 CI 세팅이 중요하다.
- feature가 너무 오랫동안 열려있는 것 같다면 중간에 master를 feature 병합하고 이어서 작업 권장한다.
Ref
- https://docs.github.com/en/get-started/quickstart/github-flow
- https://scottchacon.com/2011/08/31/github-flow.html
정리
- 배포가 많다 : github flow
- 배포가 적다 : git flow
- 소규모 팀 : github flow
- 대규모 팀 : git flow
- 단일 버전 시스템 : github flow
- 복합 버전 시스템 : git flow
마치며
git flow는 지난 10년간 일종에 표준처럼 취급되기 시작했다.
만병통치약은 존재하지 않는다.
특징을 이해하고 적절한 채택을 해야 한다.
..라고 Vincent Driessen이 말했습니다.
git flow는 "release"를 중심으로 설계되어 있다.
github에서는 git flow를 사용하지 않는다.
github flow는 단순해 워크플로우상 실수로 인한 취소가 거의 없다.
..라고 SCOTT CHACON이 말했습니다.
반응형
