[효율적인 협업] git/github branch 관리 방법론 : GitFlow 방식

영상 참고 : https://www.youtube.com/watch?v=EV3FZ3cWBp8

---

• 예전에 팀 프로젝트 할 때 시험삼아 도입해봤던 방식.
• 당시에는 중요성을 잘 모르기도 했고 때문에 이런 비중이 크다고 생각하지 않아서 물 흐르듯이 넘어가버렸던 기억이 았다.
• 스탭업을 위해서는 반드시 알아야 할 지식이라고 본다.

---

• GitFlow 방식.
  • 보통 아래 다섯 가지의 브런치로 구성된다.
    • main(master)
      • 말 그대로 프로젝트의 메인 브랜치.
      • release에서 최종 검수가 끝나면 배포를 위해 main에 머지시킨다.
      • 최종 검수가 끝난 부분을 develop에도 반영해야 한다.
    • develop
      • 개발용 브랜치. 근데 여기서 바로 개발하는건 아니다.
      • 개발자간에 여러 개발중인 기능들이 있을 때, 그 각각의 개발자들이 만든 모든 "정상 작동" 하는 기능들을 머지시키기 위해 사용되는 브랜치이다.
    • feature
      • 실제 기능 개발중인 브랜치이고 develop 브랜치로 통합되지 않은 상태.
      • 보통 "feature/{기능이름}" 과 같은 방식으로 명명됨.
        • feature/guild
        • feature/friend ...
    • release
      • 릴리즈용 브랜치. 테스트, qa 같은것들을 진행.
      • develop으로부터 완성된 기능들을 통합한 다음 실제 테스트를 하기 위해 release 브랜치로 다시 머지해서 실사용 테스트를 거친다.
      • 메인으로 바로 머지하지 않고 혹시모를 이슈를 대비해서 release로 완충시키는 것으로 이해했음.
    • hotfix
      • 말 그대로 핫픽스용 브랜치.
      • 메인에서 긴급한 이슈가 생겼을 때 메인에서 바로 브랜치를 따서 수정함.
      • 이 역시 변경사항을 develop에 반영시켜야 한다.
      • release에는 반영하지 않고 버전 표기시 patch 버전으로 취급한다.

---

• 장점 : 안정적으로 버전관리가 가능하다.
• 단점 : CI/CD에는 적합하지 않다.