[Git] Git - Branch 전략

Git Branch 전략

• Git Branch에 전략, 즉 규칙을 부여하는 것
• Git Branch를 효과적으로 관리하기 위한 워크플로우
• 각 Branch에 규칙을 정해놓고, 해당 규칙을 팀원들이 지켜가며 개발을 진행하는 것

종류

• Git-Flow
• GitHub-Flow

Branch를 사용해야 하는 이유?

• Main Branch는 일반적으로 출시되고 배포된 코드를 위한 브랜치
• 이곳에 기능을 하나씩 커밋을 진행하다 보면, 기능이 완성되기 전까지 Main Branch의 소스코드는 불완전상태로 존재
• 하나의 Branch로 개발을 진행하다 보면, 작업 중인 파일을 누군가 건드려 충돌이 발생 우려
• 독립적 개발을 위해 필요한 기능

---

Branch를 나누는 방법

1. main(master) : 서비스를 직접 배포하는 역할을 하는 브랜치
2. feature(기능) : 각 기능별 개발 브랜치
3. develop(개발) : feature에서 개발된 내용이 저장되는 브랜치
4. release(배포) : 배포를 하기 전 내용을 QA(품질검사) 하기 위한 브랜치
5. hotfix(빨리 고치기) : main 브랜치로 배포를 하고 나서 버그가 생겼을 때, 빨리 고치기 위한 브랜치

→ main, develop은 필수 브랜치이지만, 나머지 브랜치는 유지보수를 목적으로 하는 선택적 브랜치
→  feature 브랜치는 주로 'feat/{기능 이름}'으로 명명 (e.g feature/login, feature/logout)

---

Git-Flow

장점

• 브랜치별로 책임을 명확히 하는 규칙성
• 매우 디테일한 버전 정보 제공
• main에 있는 코드는 매우 깔끔한 상태 유지 (테스트되고 최종 수정된 것만 반영)
• 브랜치별로 역할이 있으므로 문제가 있더라도 문제 발생 시 각 브랜치를 대기시킬 필요가 없음

단점

• 많은 브랜치 때문에 생기는 복잡한 규칙
• release로 인한 많은 동기화 작업
• 애자일의 반복적인 접근법과 Git-Flow의 엄격하고 구체적인 규칙과 충돌

---

GitHub-Flow

장점

• 깔끔하고 간단한 협력 규칙
• 지속적인 총합과 개발의 편리함
• 빠른 피드백과 이슈 발행 및 변화를 독려
• feature 개발 이후, develop, release까지 전달할 필요가 없음

단점

• Git-Flow에 비해 체계적이지 않음
• 전반적인 개발 프로세스 관리가 더 힘들어질 수 있음
• 짧은 주기가 아닌 큰 주기의 release의 환경에는 맞지 않음
• 운영과 개발 브랜치 모두를 감당하는 master 브랜치는 코드가 지저분할 수 있음
• release 준비와 버그 수정이 모두 master 브랜치에 있으므로 특별한 주의가 더 필요함

---

어떤 전략을 사용해야 하나?

• Git-Flow 
  →  1개월 이상의 긴 호흡으로 개발하여 주기적으로 배포, QA 및 테스트, hotfix 등 수행할 수 있는 여력이 있는 팀이라면 적합
  → 소프트웨어 버전관리가 필요한 APP, 솔루션, API에 적합
  
  
• GitHub-Flow 
  →  수시로 릴리즈 되어야 할 필요가 있는 서비스를 지속적으로 테스트하고 배포하는 팀에 적합
  →  상시 배포가 가능하고, 그렇게 수행하는 프로젝트에 적합. 즉, CI/CD 자동화가 되어 있는 것이 바람직
  →  웹 애플리케이션에 적합