[Git] Github식 Branch 관리법

  서론

많은 개발자들이 자신의 소스코드를 보관하기 위해 깃을 사용한다.

그 중에서도 특히나 많은 개발자들이 이용하는 깃허브는 안정된 서비스와 여러 편의 기능으로 인해 개인 개발자 뿐 아니라 많은 회사들이 사내 프로젝트를 저장하기 위하여 사용하기도 한다.

그런 깃허브가 제안한 브랜치 관리 방법이 있는데, 나도 기억에 남길겸 이 곳에 정리하기로 한다.

통상적으로 사용되던 Git Flow는 다음과 같았다.

척 보기에도 굉장히 어지럽다. 현재 많은 깃 프로그램이 그래프 시스템을 지원하는 이유이다.

master 브랜치는 실서버에 배포작업을 진행할 브랜치, hotfix는 실서버에서 문제가 생겼을 때 급하게 작업하기 위한 브랜치, feature 브랜치는 이슈 수정 및 추가 개발에 사용되며 실제로는 푸쉬하지 않을 브랜치, release는 실서버에 푸쉬하면서 최종적으로 이슈를 해결할 브랜치... 등등 정말 세분화를 잘 시켜줬지만, Git에 익숙하지 않은 나같은 개발자는 진입 장벽이 거대하기만하다. 소스코드 저장좀 간편하게 해보겠다고 지켜야 할 양식이 너무 많다.

물론 익숙해지면 좋기야 하겠지만 나같은 개발자에게는 좀 더 단순한 구조가 필요하다.

다행스럽게도 우리 회사는 Git Flow가 아닌 Github Flow를 채택했기 때문에 이에 대해 알아보도록 하겠다.

  본론

Github Flow는 위 사진과 같이 정말로 단순하다.

Release나 Feature같은 개념이 없이 구성되기 때문이다. 그렇기 때문에 Github에서 제공하는 Git 클라이언트인 Github Desktop에서는 그래프가 존재하지 않는다.

매우 간단한 Github Flow를 이해하기 위해서는 몇가지 전제조건을 기억해야 한다.

  전제 조건

1. master 브랜치는 언제나 실서버에 배포가 가능한 상태여야 한다.

2. master 브랜치에서 파생한 브랜치에서 작업한다.

이 두가지 전제조건만 지키면 된다.

  개발 방식

1. master 브랜치에서 파생된 브랜치를 만든다.

브랜치의 이름은 현재 본인이 작업하고 있는 작업의 내용을 바로 파악할 수 있도록 작명한다. 예를 들어, 회원 가입 페이지의 텍스트를 수정하고 있다면, join-page-text-editing과 같이 짓는다.

2. 파생 브랜치에서 이루어지는 작업은 수시로 push가 이루어져야 한다.

이는 같이 작업하는 팀원이 브랜치 상태만 봐도 작업 내용이 어디까지 이루어졌는지 파악할 수 있게 하기 위함이라고 한다.

3. 파생 브랜치의 작업이 끝나거나, 코드 리뷰가 필요할 때는 pull request를 한다.

pull request는 팀원이 코드를 리뷰하기 가장 적절한 수단이며, 리뷰가 끝나면 마스터 브랜치로 병합하기도 간단하다.

4. master 브랜치는 hubot을 이용하여 자동으로 실서버에 배포하도록 구성한다.

master 브랜치에 새로운 커밋이 올라온다는 것은 실서버에 푸쉬할 변경사항이 제작되었다는 의미이기 때문에 master 브랜치의 변화를 감지하여 실서버에 자동으로 배포해주는 hubot을 이용한다.

  마치며

아직 Github Flow를 제대로 사용해본 적이 없기 때문에 무엇이 문제가 있는지 자세히 알지 못한다.

앞으로 Github Flow를 준수하며 작업해보고, 느낀 점이 있다면 글로 작성해야겠다.