GitHub-flow
Github Flow는 깃허브(GitHub)를 기반으로 한 간단하고 유연한 개발 워크플로우로 주요 목표는 신속한 배포와 효율적인 협업을 지원하는 것 입니다. Github Flow는 Git Flow와 달리 단일 브랜치를 사용하여 개발하는데, 이는 하나의 버전이 만들어지면 바로 배포될 수 있다는 의미입니다.
수시로 배포가 일어나며, CI와 배포가 자동화되어있는 프로젝트에 유용합니다.
GitHub-flow 브랜치 구조
1. Master 브랜치 (main 브랜치)
- github-flow의 master 브랜치 역할은 git flow의 master 브랜치와 동일합니다.
- 테스트가 끝난 기능에 대해 배포를 하기 위한 브랜치입니다.
- 항상 Stable한 상태여야 합니다.
2. Feature 브랜치
- 특정한 기능(단위 기능)을 구현하는 브랜치입니다.
- 기능 추가, 버그 수정 등 모든 작업은 feature 브랜치에서 작업합니다.
- master 브랜치에서 새로운 브랜치를 만들어서, master 브랜치로 merge되는 단순한 사이클을 가지고 있습니다.
GitHub-flow 주요 단계
1. 주요 브랜치
- GitHub Flow에서는 기본적으로 하나의 주요 브랜치를 사용합니다. 대개 "master" 또는 "main" 브랜치로 불리며, 여기에는 항상 배포 가능한 상태의 코드가 있어야 합니다.
2. 새로운 브랜치 생성
- 새로운 기능이나 버그 수정과 같은 작업을 시작할 때는 주요 브랜치에서 새로운 브랜치를 생성합니다.
- 브랜치 이름은 일반적으로 간단한 설명과 함께 이슈 번호를 포함합니다.
3. 커밋과 푸시
- 작업이 완료되면 변경 사항을 커밋하고, 해당 브랜치를 원격 저장소에 푸시합니다.
4. 풀 리퀘스트(Pull Request, PR) 생성
- 작업이 완료되면 메인 브랜치에 머지되기 전에 풀 리퀘스트를 생성합니다. 이를 통해 변경 내용을 리뷰하고 토론할 수 있습니다.
5. 토론과 리뷰
- 다른 개발자들은 풀 리퀘스트를 리뷰하고, 변경 사항에 대해 논의합니다.
- 필요한 경우 추가적인 수정이 이루어집니다.
6. 머지
- 리뷰가 완료되면, 풀 리퀘스트를 메인 브랜치에 머지합니다.
7. 배포
- 메인 브랜치에 변경사항이 머지되면, CI/CD 파이프라인을 통해 자동으로 배포됩니다.
GitHub-flow 장단점
1. 장점
- GitHub-flow는 Git-flow에 비해 단순합니다.
- 지속적인 통합과 같은 개념을 통해 안정적인 코드베이스를 유지하면서 효율적인 협업을 가능하게 합니다.
2. 단점
- GitHub Flow는 작은 규모의 프로젝트나 빠른 개발 주기를 필요로 하는 경우에 적합하며, 대규모 프로젝트에는 부적합할 수 있습니다.
- 히스토리가 간소하게 유지되기 때문에, 복잡한 이력 추적이 필요한 경우 부적절할 수 있습니다.
