브랜치 전략

• GitFlow 검토

  • GitFlow의 모든 기능을 사용하는 것은 현재 프로젝트의 규모에 맞지 않다고 판단.
  • master(배포), develop(개발), feature(기능), bugfix 정도의 브랜치를 사용
  • 각각의 PR 단위는 Issue 1개로 제약
  • PR시 연결된 Issue를 연결하도록 하여 쉽게 작업 관리를 하도록 함

• Work Flow 검토

  • Git flow
    • GitFlow의 모든 기능을 사용하는 것은 현재 프로젝트의 규모에 맞지 않다고 판단.
    • 복잡한 프로젝트의 경우 사용하는 것이 맞다고 판단
  • Github Flow
    • 지나치게 단순한 구조
    • 모바일 특성상, 심사를 받아야하기 때문에 master 브랜치만 운영하는 것은 옳지 않다고 판단
  • GitLab Flow
    • 모바일 특화된 Flow
    • 원하는 시점에 배포 가능
  • 결론
    • main repository(upstream)에는 master(배포), develop(개발) 브랜치 운영
    • Local repository에서 feature 브랜치를 develop 브랜치에서 switch하여 운영
    • main repository에 PR을 보내고 기능 개발이 완성된 경우 master에 배포하는 방식을 채택
    • PR 단위를 Issue 1개로 제약
    • PR시 연결된 Issue를 연결하도록 하여 쉬게 작업 관리를 하도록 함

• Repository 관리
  • Clone하여, 바로 작업 현황을 적용하는 방법
    • 장점
      • 직관적이다. 쉽다.
    • 단점
      • 같은 레포에 local한 작업의 branch를 원격에 push하고, 이를 merge하는 방식이기 때문에, 프로젝트의 브랜치가 굉장히 많아질 수 있다.
      • 실제 작업할 때 보이는 브랜치들이 모두 올라가게 되어 관리가 어려울 수 있다.
  • 팀원이 모두 fork하여 Origin, Upstream을 두고 관리하는 방법
    • 장점
      • 단계를 한단계 추가하여, 실제 프로젝트(upstream)를 관리하는데, 딱 필요한 것들만 적용시킬 수 있어 보다 깔끔한 작업 진행이 가능하다.
    • 단점
      • 팀원 모두가 git에 대한 이해가 부족할 경우, 진행속도가 더디거나 충돌이 많이 발생할 수 있다.