Github 브랜치 전략 이거 하나만 알고 있으면 된다.

안녕하세요.

 

깃 플로우, Git flow에 대해 이야기 해보려 합니다.

 

각자 개발할때 형상관리는 어떻게, 어떤 브랜치 전략 어떻게 사용하고 계신가요?

 

가장 기본이 되는 개념에 대해 공부하고, 정리한 내용을 바탕으로 작성해보려 합니다.

 

우선 저희는 실무에서 각 파트에서 혼자 개발하고 있는 경우가 많아서, 깃 플로우 정책이 필요없지만 그래도 개념은 중요하니깐요? ㅋㅋㅋ

 

출처 : Git Flow

 

짜잔.

 

브랜치 유형은 크게 5가지가 있습니다.

 

 

1. 브랜치 유형:

• 기능 브랜치 (핑크):
  • 다음 릴리스를 위한 새 기능을 개발하는 브랜치.
  • develop 브랜치에서 파생되며 작업 완료 시 develop에 다시 병합됩니다.
• 개발 브랜치 (노랑):
  • 새로운 기능을 통합하는 메인 브랜치.
  • 최신 개발 상태를 반영하지만 불안정할 수 있습니다.
  • 버그 수정 및 기능 브랜치들이 이곳에 병합됩니다.
• 릴리스 브랜치 (초록):
  • 다가오는 릴리스를 준비하는 브랜치.
  • 새 릴리스를 시작할 준비가 되면 develop에서 파생됩니다.
  • 릴리스를 안정화하며 버그 수정만 받습니다.
  • 완료되면 develop과 master에 다시 병합합니다.
• 핫픽스 브랜치 (빨강):
  • 프로덕션에 즉각적인 버그 수정을 제공하는 브랜치.
  • master에서 파생되어 develop과 master에 모두 병합됩니다.
• 마스터 브랜치 (파랑) => 메인 브랜치(파랑):
  • 프로덕션 준비가 완료된 코드를 포함하는 브랜치.
  • 태그를 사용하여 안정적인 버전을 반영합니다.
  • 현재는 마스터라는 이름을 쓰지 않죠, 마스터-슬레이브 편견이 있는 단어라고 해서, 현재는 메인 브랜치라고 생각하시면 됩니다. 자료가 옛날꺼라..ㅎ

 

메인 브랜치가 있는 이유는 실제 사용자들에게 서비스를 하는 시장에서는 중요할 것 같은데, 굳이 릴리스랑 메인 브랜치가 2개 공존이 필요할까 하는 생각이 드네요.

 

Develop Branch인 개발 브랜치(노랑)에 피쳐 브랜치랑 열심히 붙이는 작업이 좀 많습니다.

 

핫픽스 같은 경우는 메인 브랜치에서 각 버전에 따라 사용자들에게 실제로 서비스를 하다가, QA에서 발견하지 못했던 버그 같은게 툭툭 튀어나오면 당황스럽죠??

 

그때 급하게 최소한의 수정만 필요한 경우에 사용합니다!

 

제가 좋아하는 깃허브의 창립자인 Chris Wanstrath가 이런 말을 했습니다.

 

 

I think that’s how you get to technological breakthroughs -- by focusing on real issues

 

 

그렇다면 진짜 문제를 해결하기 위해 가장 중요한 것은 바로 협업입니다.

 

그렇기에 각 팀에서는 프로젝트를 진행하기 전에 먼저 어떻게 협업을 할지, 브랜치 전략을 짜야할지 고민을 충분히 해야합니다.

 

 

그럼 이만.