Git 브랜치 전략?

깃을 효과, 효율적으로 사용하기 위한 깃 컨벤션!!!

왜?

• 브랜치를 어디다 생성하지?
• 브랜치는 어디서 나온거지?
• 어떤 브랜치가 배포된거지?
• …

이런 의문점이 생긴다면 이미 프로젝트는 엉망!

따라서 규칙이 필요!!!

가장 유명한 규칙인 Git Flow, Github Flow에 대해 설명

Git Flow

크게 세가지 브랜치로 나뉜다.

Main

실제 사용가능한 버전들의 코드를 모아두는 브랜치

실제로 배포된 각 버전을 tag로 이용해 표시해둔다!

Develop

다음 버전 개발을 위해 코드를 모아두는 것!!!

개발이 완료 되면 Main 브랜치로 머지 된다

Supporting

여기서 세가지로 나뉜다.

• Feature 브랜치 기능을 개발하기 위한 브랜치로 develop에서 분기된 브랜치이다. (기능개발이 되면 develop에 머지!)
  
• Release 브랜치 소프트웨어 배포를 위한 브랜치 배포가능한 버전들을 따로 릴리즈 브랜치에서 관리한다.
  
• Hotfix 브랜치 이미 배포된 버전에 문제가 발생하면 이 핫픽스 브랜치에서 수정한다! (수정시 Main, Develop 머지)
  

뭔가 좀 이상한데…?

내가 가장많이 개발하는 웹 어플리케이션은 저렇게 많은 배포 버전이 필요없다…

사용자들은 거의 최신버전만 사용가능하다…

이런 hotfix, release 브랜치들은 왜 존재하지? 굳이…?

위 git flow를 제안한 사람은 웹이아닌 다른 소프트웨어 개발자로

(예를들면 모바일어플, 오픈소스라이브러리, 프레임워크 등)

의 프로젝트에 적합한 전략이라고 설명을 나중에 덧 붙혔다.

즉! 웹에서는 너무 복잡한 전략!

Github Flow 전략

웹에서 사용되는 굉장히 간단한 구조로

보통

• Main
• Develop
• Topic 브랜치

• Topic 브랜치를 Main 브랜치로부터 생성한다.
• Git Flow의 Feature 브랜치와 동일한 역할을 한다.
• 또한 별도로 Hotfix 브랜치를 관리하지 않으며, 버그 수정도 Topic 브랜치에서 진행한다.

하지만 나는 feature를 못버린다...

내가 추구하는 전략

• 기능을 개발할때 develop에서 feature/기능이름 또는 이슈 번호 브랜치를 만들어 기능을 개발하고
• 개발 완료된 feature브랜치를 develop에 PR(풀 리퀘스트) 한다.
• 머지된 브랜치는 CICD툴에 의해 자동으로 테스트 되며 테스트가 통과된 브랜치 만이 develop에 머지된다.
• develop에 충분한 기능이 포함되었다면 main 브랜치로 PR하여 CICD툴을 이용해 배포를 자동으로 한다.

참고

https://hudi.blog/git-branch-strategy/