65. GitHub Flow (깃허브 플로우) 브랜치 전략

⚠️ 이 문서는 한 달에 한 번 배포하는 무거운 Git Flow 전략을 버리고, **오직 영구적인 main 브랜치 하나와 새로운 기능을 만드는 feature 브랜치만 사용하여 코드를 작성하자마자 즉시 운영 서버에 배포(Continuous Deployment)해버리는 현대적이고 극단적으로 단순한 소스코드 형상 관리 모델인 'GitHub Flow'**를 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: develop이나 release 같은 복잡한 대기실(브랜치)을 싹 다 없앴다. "Main 브랜치에 있는 코드는 언제든, 무조건, 지금 당장 라이브(운영) 서버에 배포될 수 있어야 한다"는 단 하나의 절대 원칙만 존재한다.
  2. 가치: 코드의 병합(Merge) 충돌을 해결하느라 며칠을 허비하는 'Merge Hell'을 원천 차단하며, 하루에도 수십 번씩 새로운 기능을 넷플릭스나 페이스북처럼 시장에 즉각 출시하는 애자일(Agile) 조직의 속도전을 가능케 한다.
  3. 기술 체계: 뼈대(main)에서 가지(feature)를 따서 개발한 뒤, 깃허브의 핵심 기능인 **풀 리퀘스트(Pull Request, PR)**를 올려 동료들의 코드 리뷰를 받고, 통과되는 즉시 main에 병합하며(CI 자동화), 곧바로 운영에 배포(CD)된다.

Ⅰ. Git Flow의 무거움과 GitHub Flow의 탄생 배경

과거의 훌륭한 5단계 규칙은 클라우드 시대의 족쇄가 되었다.

  1. 릴리스(Release)의 지연:
    • 전통적인 Git Flow는 feature -> develop -> release -> master를 거치느라, 개발자가 짠 코드가 실제 고객의 손에 닿기까지 최소 2주~한 달의 지연(Lead Time)이 발생했다.
    • 이는 웹 서비스(SaaS)처럼 버그를 10분 만에 고치고 바로 덮어써 버릴 수 있는 클라우드 환경에서는 너무나도 쓸데없는 관료주의였다.
  2. GitHub Flow의 제안 (단순성의 미학):
    • 깃허브(GitHub)의 창립자 스콧 샤콘(Scott Chacon)이 "웹 기반 환경에서는 릴리스(버전)라는 개념 자체가 필요 없다. 그냥 Main과 Feature 두 개면 완벽하다"라며 제안한 모델이다.

📢 섹션 요약 비유: Git Flow가 1년에 두 번 계절이 바뀔 때만 수만 벌의 옷을 도매상에 넘겨(Release) 백화점에 진열하는 무거운 전통 패션업계의 방식이라면, GitHub Flow는 디자이너가 옷을 한 벌 스케치하자마자 바로 재봉틀로 꿰매어 그날 오후 인스타그램 쇼핑몰(운영 서버)에 즉각 올려버리는 극강의 SPA(패스트 패션) 브랜드 방식입니다.

Ⅱ. GitHub Flow의 완벽한 6단계 규칙

규칙이 단순할수록 팀원들이 따르기 쉽고 실수가 없다.

  1. 규칙 1: main 브랜치는 신성하다:
    • main 브랜치에 올라온 코드는 버그가 없으며 언제든 즉각 배포(Deploy) 가능해야 한다. 절대 망가진 코드가 들어가면 안 된다.
  2. 규칙 2: 가지 치기 (Create a Branch):
    • 새로운 기능이나 버그 픽스를 할 때는 무조건 main에서 새로운 브랜치를 딴다. 이름은 목적을 알기 쉽게 짓는다 (예: feature/login-btn).
  3. 규칙 3: 커밋과 푸시 (Commit & Push):
    • 로컬에서 코드를 짜면서 지속적으로 자신의 브랜치에 Commit하고 원격 저장소에 Push하여 안전하게 백업한다.
  4. 규칙 4: 풀 리퀘스트 (Pull Request, PR) 생성:
    • ★ 이 전략의 꽃이다. 코드가 완성되면 (또는 도움을 받고 싶을 때) main에 합쳐달라고 깃허브 화면에서 PR 버튼을 누른다.
  5. 규칙 5: 코드 리뷰와 피드백 (Discuss & Review):
    • PR이 올라오면 다른 팀원들이 코드를 꼼꼼히 리뷰하고 댓글을 단다. 자동화된 CI 서버(Jenkins, GitHub Actions)가 튀어나와 "이 코드는 테스트 100개를 모두 통과했습니다"라고 초록색 체크 마크를 달아준다.
  6. 규칙 6: 병합과 즉시 배포 (Merge & Deploy):
    • 리뷰와 테스트가 통과되면 마침내 main에 합쳐지고(Merge), **합쳐진 코드는 즉시, 숨 쉴 틈도 없이 운영 서버로 자동 배포(CD)**된다.

📢 섹션 요약 비유: 기자가 기사를 쓸 때, 각자 복사본 종이(feature)에 기사를 씁니다. 완성되면 편집장 책상 위에 올리고(Pull Request), 다른 기자들과 편집장이 돌려보며 오타를 잡아냅니다(코드 리뷰). 오케이가 떨어지면 그 기사는 메인 신문판(main)에 풀칠되어 붙고, 1초의 망설임 없이 윤전기가 돌아가 전국의 독자들에게 배포(Deploy)되는 일직선 시스템입니다.

Ⅲ. 치명적 전제 조건: "CI/CD 자동화가 없으면 지옥"

단순한 브랜치는 강력한 로봇(자동화)의 뒷받침을 요구한다.

  1. 테스트 자동화의 강제성 (Test Automation):
    • develop이나 release 같은 테스트용 대기실이 없기 때문에, main에 합쳐진 코드가 버그를 품고 있다면 운영 서버(아마존, 쿠팡 등)가 즉시 멈춰버리는 대형 사고가 터진다.
    • 따라서, PR이 올라왔을 때 수천 개의 단위 테스트(Unit Test)를 1분 만에 기계적으로 검사하여 빨간불/초록불을 띄워주는 강력한 CI(지속적 통합) 서버의 존재가 100% 필수 조건이다. (사람의 수동 클릭 테스트로는 이 속도를 감당할 수 없다.)
  2. 언제 써야 하는가? (적용처):
    • 웹 서비스, SaaS, 스타트업 프로젝트에 압도적으로 유리하다.
    • 반면 아이폰 앱(App Store 심사 필요), 패키지 소프트웨어(v1.0 다운로드 설치형)처럼 고객이 마음대로 버전을 통제하는 환경에서는 롤백이 어려우므로 여전히 Git Flow나 Trunk-Based Development의 변형이 안전하다.

📢 섹션 요약 비유: 서커스에서 그물망(release 브랜치) 없이 공중그네를 뛰는 것과 같습니다. 동작이 엄청나게 빠르고 우아해지지만, 그물망이 없으므로 선수의 손목을 잡아주는 완벽하고 기계적인 하네스 장치(CI/CD 테스트 자동화)가 없다면 단 한 번의 실수로 회사가 추락사하는 무시무시한 전제 조건이 깔려 있습니다.