[Git] Github-Flow [깃 브랜치 전략]

Github Flow

Github Flow는 Git Flow가 Github에서는 사용하기 복잡하다고 하여 나온 전략
여러 전략 중 가장 간단한 전략

커밋 그래프

 

위 커밋 그래프처럼 단순한 형태를 띄기 때문에 사용법도 단순함.

 

하나의 기능 구현 Feature 브랜치가 완료될 때 마다 Pull Request를 진행하기 때문에 수시로 배포가 발생.

→ CI / CD 환경을 구축하여 자동화가 되어있는 환경에서 사용하기 적합함.

 

 

 

 

---

장점

- 위 이미지처럼 Git Flow에 비해 간단하고 직관적인 구조를 가지고 있음.

- 단순한 구조 및 빠른 배포주기로 인해 소규모 및 단기간 프로젝트에서 사용하기 좋음.

 

---

단점

- Git Flow에 비해 브랜치를 세분화하지 않기 때문에 브랜치 네이밍 및 커밋 메시지에 신경 쓰지 않으면 전체적인 개발 흐름을 쫒기 힘듦.

- release 브랜치를 통해 별도로 테스트를 진행하지 않기 때문에 배포 위험성 및 관리의 어려움이 있음.

- 위 단점으로 인해 CI/CD 자동화 환경 구축이 강요됨.

 

---

정리

master 브랜치는 항상 배포 가능한 상태를 유지

Git Flow처럼 develop, hotfix, release 브랜치가 없기 때문에 feature 브랜치 생성 시 이름을 명확히 하고, 커밋 메시지를 정확하게 해야함.


한 브랜치에서 기능 구현이 완료되어 코드리뷰가 필요한 시점에는 master 브랜치로 PR을 통해 진행

 

단기간 진행하는 소규모 프로젝트이며, CI/CD 환경이 구축되어 있는 환경이라면 Github Flow 전략을

둘 중 하나라도 해당되지 않다면 Git Flow를 사용하여 협업 및 형상관리를 진행하는게 좋아보임.