[GIT] git flow에 대하여 알아보자

오늘은 깃 플로우에 대해 알아보도록 합시다.
여러명의 개발자들이 한 프로젝트를 같이 하며 깃을 사용하고 한 브랜치에 머지를 하며 잦은 코드 충돌과 남이 내꺼를 덮어씌우고 버전관리가 안되게 되고 뒤죽박죽 형상이 엉키게 됩니다. 그래서 고민고민 끝에 사람들은 서로간의 약속을 하고 브랜치 전략을 세웠습니다.
그게 깃 플로우인데, 이해가 목적이기에 간단하게 정리하도록 합시다.

깃 플로우
사실 브랜치전략과 완전히 똑같이 협업이 되고 있다고 생각하진 않고, 회사나 프로젝트마다 조금씩 다를 수 있어요.
하지만 기본적인 국룰 이란게 존재하기에 알고 갑시다.

master : 제품으로 출시될 수 있는 브랜치
develop : 다음 출시 버전을 개발하는 브랜치
feature : 기능을 개발하는 브랜치
release : 이번 출시 버전을 준비하는 브랜치
hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치

일단 어디서 줏어왔어요.. 한글버전이 있길래

설명부터 들어가죠 master에는 언제나 제품에 출시되어 있는 완성본만 담고 있어야 합니다.
개발은 develop 브랜치를 생성하고 서로간에 기능단위로 업무를 배정해서 각자 develop브랜치에서 feature브랜치를 생성합니다.
커밋은 왠만하면 1개의 커밋에 끝내는게 제일 좋습니다. 그리고 의미 그대로 그 기능에 대한 개발만 하는거죠.
그래야 형상관리가 편리합니다. 개발이 다 되었다면 develop브랜치에 머지리퀘스트를 날립니다.
머지를 하기전 코드에 대한 리뷰를 받는 구조인데, 프로젝트 맴버들의 리뷰에서 통과가 되면 develop브랜치에 머지됩니다.
기능개발이 완료되면 QA단계를 위해 release브랜치로 머지합니다. QA를 진행하고 버그가 있다면 develop브랜치로 다시 back merge하고 이상이 없다면 master버전에 머지합니다.
출시버전에 버그가 있고, develop버전에는 이미 다른 개발이 진행중이라면 hotfix를 통해 버그를 수정한 후 master로 머지합니다.

저 그림의 내용을 브랜치별 말로 설명하면 그렇습니다.
소규모 프로젝트나 소수 인원으로 프로젝트를 진행해서 충돌이 없고, 버전관리를 안해도 뭐 상관없다는 마인드를 가지고 있다면.. 번거롭다 생각할 수 있고, 개발속도 안나온다고 생각할 수 있지만, 관리를 위해 조금 더 신경써서 개발하도록 합시다.