Git Branch 관리 전략

1. Git Flow

Git Flow는 가장 널리 알려진 Git 브랜치 전략 중 하나로, Vincent Driessen에 의해 제안되었습니다. 이 전략은 명확한 브랜칭 모델을 제공하여, 대규모 프로젝트 관리에 유리합니다.

 

메인 브랜치

• master: 최종 제품의 코드를 포함하며, 항상 배포 가능한 상태여야 합니다.
• develop: 다음 출시 버전을 준비하는 브랜치로, 여기서 새로운 기능이 통합됩니다.

보조 브랜치

• feature: 새로운 기능을 개발하는 브랜치로, develop 브랜치에서 파생되어 완료되면 다시 develop 브랜치에 병합됩니다.
• release: 출시 준비를 위한 브랜치로, develop 브랜치에서 파생되며 최종 테스트 및 버그 수정을 거친 후 main 브랜치와 develop 브랜치에 병합됩니다.
• hotfix: 배포된 제품의 긴급 수정이 필요한 경우 사용하는 브랜치로, main 브랜치에서 파생되어 수정 후 main과 develop 브랜치에 병합됩니다.

워크 플로우

1. master브랜치에서 develop브랜치가 파생됨
2. 이 후 개발될 기능들이 delvelop브랜치로 부터 파생
3. 기능들이 개발되면 develop브랜치로 병합되고
4. develop브랜치가 다 합쳐지면 release브랜치를 생성하고 테스트 진행
5. 버그가 없으면 master로 병합, 버그가 있으면 다시 develop 브랜치를 생성함
6. 이후 release브랜치가 master로 병합되고, 배포를 진행함

 2. GitHub Flow

GitHub Flow는 GitHub에서 제안한 간단하고 직관적인 브랜치 전략으로, 지속적인 배포와 빠른 피드백을 중시하는 프로젝트에 적합합니다.

메인 브랜치

• master or main: 항상 배포 가능한 상태의 코드를 포함합니다.

보조 브랜치

• feater: 특정한 기능을 개발하기 위해 main에서 파생된 브랜치입니다.

브랜치 워크플로우

1. feature: 새로운 기능이나 버그 수정을 위해 main 브랜치에서 파생됩니다.
2. Pull Request(PR): feature 브랜치가 준비되면 PR을 통해 코드 리뷰와 테스트를 거칩니다.
3. 병합: PR이 승인되면 main 브랜치에 병합되어 즉시 배포됩니다.

 3. GitLab Flow

GitLab Flow는 GitLab에서 제안한 전략으로, 다양한 워크플로우를 지원하며 프로젝트의 배포 방식에 맞게 브랜치를 설정할 수 있습니다.

메인 브랜치

• master: 항상 배포 가능한 상태의 코드를 포함합니다.

환경별 브랜치

• production: 실제 운영 환경에 배포되는 코드를 관리합니다.
• pre-production: 사전 배포 환경으로, 배포 전 최종 테스트를 수행합니다.
• development: 개발 환경으로, 새로운 기능과 버그 수정을 통합합니다.

브랜치 워크플로우

• feature: main 또는 development 브랜치에서 파생되어 개발이 완료되면 대상 브랜치에 병합됩니다.
• release: 특정 버전을 출시하기 위해 사용하는 브랜치로, 일정 기간 동안 안정화 작업을 수행합니다.