GitHub Flow

GitHub Flow는 GitHub가 제안한, 단순하고 명확한 브랜치 전략입니다. 핵심은 하나입니다.

main(또는 master) 브랜치는 항상 배포 가능한 상태를 유지한다.

Feature 브랜치

새로운 기능이나 수정 사항마다 별도의 브랜치를 파서 작업하고, 끝나면 메인 브랜치로 머지하는 개념입니다. 여러 기능을 독립적으로 개발할 수 있고, 여러 명이 동시에 작업해도 충돌이 최소화됩니다.

작업 흐름

1. 메인 브랜치에서 새 브랜치 생성
2. 브랜치에서 작업
3. Pull Request 생성
4. 코드 리뷰
5. 머지

"항상 배포 가능"은 어떻게 보장할까?

두 가지 장치가 필요합니다.

1. 코드 리뷰: 머지 전에 사람이 눈으로 오류를 걸러냅니다. 다만 사람이 하는 일이라 놓치는 부분이 생길 수밖에 없습니다.
2. 테스트 (자동화된 CI): 브랜치를 체크아웃해 빌드하고 테스트를 자동으로 돌려서, 리뷰 전에 이미 "배포 가능함"이 확인된 상태로 만듭니다.

현실에서 부딪히는 고민들

프로젝트 초기라 구조가 계속 바뀔 때: 아직 팀의 디자인 패턴이 정립되지 않은 상태에서 다들 다른 방식으로 코드를 짜면, 방법론 충돌이 곧 코드 충돌로 이어집니다. 이럴 땐 먼저 모여서 방향성과 규칙을 정하거나, 한 명이 빠르게 프로토타입으로 구조를 검증한 뒤 GitHub Flow를 도입하는 게 낫습니다.

Feature의 크기가 애매할 때: "무엇을 하나의 Feature로 볼지"는 회사·프로젝트·사람마다 다릅니다. 다음 기준이 도움이 됩니다.

• 구체적으로 정의할 것 (예: "UI 개선" 대신 "로그인 버튼 디자인 변경")
• 독립적으로 배포 가능할 것
• 배포 시점에 다른 코드와 충돌 없이 호환될 것
• 너무 크지도 작지도 않은 적절한 크기일 것

출처: Codyssey-B1/B2-2