intro

버전관리에 대해 아무것도 모르는 아기새 5마리가 모여서 나름대로 브랜치전략을 짜서pr을 날리고 그것들을 pull을 받는순간.... 어마무시한 에러들이 발생했다.

조장님: 어,,,,이거 왜이래,,,왜이래
나: 왜요???
조장님: pull받아서 merge할라니까 conflict가 뭐어쩌고..저쩌고하는데요?
나: ...

❓why?

브랜치전략이 잘못 이해하고 있었던게 원인이였다.
서로 다른 브랜치에서 같은 곳을 바라보며 작업을 했으니...
하나로 합쳤을 땐 A가 작성한 코드가 맞는지, B가 작성한 코드가 맞는지를 판단할 수 없는 것 이였다.

그래서 이번엔 브랜치전략에 대해 회고하면서 글을 써보려고 한다.

❓GitFlow

Git-flow는 Git이 새롭게 활성화되기 시작하는 10년전 쯤에 Vincent Driessen이라는 사람의 블로그 글에 의해 널리 퍼지기 시작했고 현재는 Git으로 개발할 때 거의 표준과 같이 사용되는 방법론입니다.

말하자면 Git-flow는 기능이 아니고 서로간의 약속인 방법론이라는 점입니다. Vincent Driessen도 언급했듯이 Git-flow가 완벽한 방법론은 아니고 각자 개발 환경에 따라 수정하고 변형해서 사용하라고 언급했습니다.

Git-flow는 총 5가지의 브랜치를 사용해서 운영을 합니다.

• master : 기준이 되는 브랜치로 제품을 배포하는 브랜치 입니다.
• develop : 개발 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 합(Merge)칩니다.
  feature : 단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치에 합칩니다.
• release : 배포를 위해 master 브랜치로 보내기 전에 먼저 QA(품질검사)를 하기위한 브랜치 입니다.
• hotfix : master 브랜치로 배포를 했는데 버그가 생겼을 떄 긴급 수정하는 브랜치 입니다.

master와 develop가 중요한 매인 브랜치이고 나머지는 필요에 의해서 운영하는 브랜치라고 보시면 됩니다.

👉apply

위의 글을 토대로 이런 순으로 버전관리접근을 수정했다.

1. main 브랜치에서 develop이란 브랜치를 생성.
2. 각자 fork를 받은 후, develop를 토대로 컨벤션에 따른 각자의 브랜치를 생성. ( feat/#2 , refactoring/#80 같은!)
3. 각자 작업이 끝난 후, 개인 레포지토리(origin)으로 push.
4. github 홈페이지로 이동 후, 각자 develop 브랜치로 pr 후 merge.
5. 로컬 저장소로 돌아와 pull.

1 이후, 2->3->4->5의 반복순으로 작업했다.