Git Flow
- Main branch
- Feature branch
- Release branch
- (Hotfix branch
Master
최종 단계 메인 브랜치 , 배포 가능한 상태만을 관리
Tag를 통해 버전 관리를 한다. (1.0 -> 1.0.1 -> ....)
develop
모든 기능이 추가되고수정되어 배포 가능한상태라면 develop 브랜치를 master 브랜치에 병합
개발이 이루어지는 곳
feature
기능을 개발하는 브랜치 개발이 끝나면 develop 브랜치로 병합
- 새로운 기능 개발과 수정이 필요할 때마다 develop 브랜치에서 분기
- 보통 개발자 저장소에만 있는 브랜치고 origin에는 push 하지 않는다.
release
이번 출시 버전을 준비하는 브랜치
-
배포를 위한 최종적인 버그 수정 등의 개발을 수행
-
배포 가능한 상태가 되면 master 브랜치로 병합시키고, 출시된 master 브랜치에 버전 태그를 추가
hotfix
출시 버전에서 발생한 버그를 수정 하는 브랜치
-
버그를 수정하는 동안에도 다른 사람들은 develop 브랜치에서 개발이 가능
-
hotfix 브랜치에서의 변경 사항은 develop 브랜치에도 merge하여 문제가 되는 부분을 처리해 주어야함
장점
- 브랜치별로 책임을 명확히 하는 규칙성
- 매우 디테일하게 버전 정보 제공
- master에 있는 코드는 테스트되고 최종 수정된 것만 반영되기 때문에 깔끔하다.
- 브랜치별로 역할이 있으므로 문제가 있더라도 문제 발생시 각 브랜치를 대기 시킬 필요가 없음
단점
- 많은 브랜치 때문에 생기는 복잡한 규칙
- release 로 인한 많은 동기화 작업
Github Flow
Git-Flow와 달리, GitHub-Flow는 release 브랜치가 없다.
- 하나의 버전이 만들어졌으면, 배포될 수 있다는 개념
장점
- 깔끔하고 간단한 협력 규칙
- 지속적인 통합과 개발의 편리함
- 빠른 피드백과 이슈 발행 및 변화를 독려
- feature 개발 이후 dvelop, release까지 전달할 필요가 없음
단점
- Git-Flow에 비해 체계적이지 않음. 자유분방한 코드 관리
- 전체적인 개발 프로세스 관리가 더 힘들어질 수 있음
- 짧은 주기가 아닌 큰 주기의 배포 환경에는 맞지 않음
- 운영과 개발 브랜치 모두를 감당하는 master 브랜치는 코드가 지저분 할 수 있음
- release 준비와 버그 수정이 모두 master 브랜치에 있으므로 특별한 주의가 더 필요함
remind