git-flow 전략으로 한 이유가 뭘까요?

• 함께 작업하지만 독립적인 개발 환경을 보장할 수 있어요
• CI/CD를 원하는 작업들만 골라 진행할 수 있어요
• 많은 규칙을 두어 Git 사용에 익숙해지고 싶었어요

우리 입맛의 git-flow 전략

이번 프로젝트에서 이 전략의 어떤 점을 조심해야 할까요?

• 선형적(단계적) 기능 개발에 있어 Branch 전략이 걸림돌일 수 있어요
• rebase 사용이 거의 없을 것을 인지하고 분기 추적을 할 수 있어야 해요

main (release)

• 실제 출시(프로그램이 버그 없이 돌아갈 수 있는) 상태인 Branch
• push 시 자동 배포될 수 있도록 합니다.
• develop branch에서만 PR을 보내서 Merge할 수 있다.
  • Approve 가 있어야 Merge가 가능하다. (버그 및 실수 확인)

develop

• feature branch에서만 PR을 보내서 Merge할 수 있다.
  • Merge 시 Conflict 해소
  • Approve 가 있어야 Merge가 가능하다.
    • Code Review 를 진행해야 합니다.
      • 적극적으로
      • 칭찬 + 비판
      • 근거있는 주장
    • 페어프로그래밍으로 했을 때는 살펴보기만 한다.
• 코드를 합쳐서 작동하는지 확인합시다.

feature

• 실제 기능을 개발하는 branch
• 이슈(기능) 단위별로 나누어서 생성합니다.
  • feature/이슈번호

hotfix

• main branch에서 분기합니다.
• 긴급하게 고칠 코드가 있으면 이 branch에서 작업 후 main으로 PR을 보냅니다.
  • Approve 가 있어야 Merge 할 수 있습니다.