브랜치(branch)
버전 관리 중의 하나인 깃(git)에서의 브랜치(branch)는 복사본이라고 한마디로 표현이 가능합니다. git은 파일들의 변경점들에 대해 버전 관리를 한다면, branch는 원본 프로젝트를 복사해서 별도의 버전을 새로 생성하는 방식입니다. git을 생성해서, branch를 건들지 않았다면 master branch 1개만 존재합니다.
1개의 branch 상태에서 다른 사람과 협업을 하다가 오류가 나는 코드를 푸시했을때는 다른 사람의 코드도 오류가 나게 됩니다.
나만 사용하는 git이라고 하더라도, 에러없는 기능을 한 번에 만들기란 쉽지 않습니다.
상황을 예로 들자면,
'하나의 프로젝트 내에서 구현이나 서비스 계획이 불확실한 기능을 개발할 때'
'프로젝트에서 진행중인 개발 일정은 일정대로 진행하고, 사이드로 코드를 수정할 때'
'어떤 기능을 개발하다가, 긴급한 기능 개발 건이 있을 때'
에 branch를 사용하면 됩니다.
만약 branch가 없는 상황을 가정해보면, 프로젝트 폴더를 복사해서 개발을 진행할 텐데, 긴급한 기능 수정만큼 폴더가 늘어날 겁니다. 그리고 나중에 소스를 합쳐야 되는 순간이 온다면, 하루 종일 지렁이만 쳐다보고 있을 겁니다.
branch를 사용하면 클릭 몇번으로 이러한 상황을 간단하게 해결할 수 있습니다. 깃 플로우 모델을 예시로 하겠습니다.
깃 플로우(git flow)
위의 모델은 각각의 branch를 어떻게 사용할 건지 약속되어 있는 모델입니다. 메인은 develop과 master이고, 나머지는 보조입니다. 맨 위의 행, 오른쪽부터 설명을 드리자면,
master는 실제 서비스를 제공하고 있는 운영서버에 이미 배포를 했거나, 배포가 준비된 코드입니다. 이 branch에서 병합을 한다는 것은 배포를 하겠다는 의미입니다.
hoxfixes는 서비스하고 있는 버전에서 발생한 버그를 수정하는 branch입니다.
release branches는 이번에 출시할 버전을 의미합니다. release server를 실제 서비스환경과 똑같이 구성해서 테스트를 진행하는 경우도 있습니다. 개발이 끝난 소스들을 release에서 merge 하고, 이 branch에서 QA를 진행합니다. QA에서 발견한 버그들은 release branch에서 수정되고, QA가 통과되면 master branch로 merge 합니다.
develop은 feature branches에서 추가된 기능들을 merge 합니다. 이번에 배포할 버전에 포함된 모든 기능들을 merge 했다면, release branch를 생성합니다.
feature branches는 기능 개발을 위해서 branch를 develop에서 생성하였습니다. 열이 2 열인 것은 작업자가 2명 이상이거나, 나 혼자 2개의 branch를 사용해서 기능별로 소스버전을 관리하겠다는 겁니다. 즉, 제일 작은 단위의 작업이라고 생각하시면 됩니다. 예를 들어, 로그인 기능, 회원가입 기능, 정보 수정 기능 별로 branch를 생성한 겁니다.
더 자세한 설명은 영어로 되어있습니다.
https://nvie.com/posts/a-successful-git-branching-model/
A successful Git branching model
In this post I present a Git branching strategy for developing and releasing software as I’ve used it in many of my projects, and which has turned out to be very successful.
nvie.com
마치며
저는 회사에서 이 모델을 베이스로 해서, develop이 release branch 역할을 포함하고, master는 운영서버로 배포하는 시스템을 갖춰서 운영하고 있습니다. 기능별로 branch를 생성하고, develop으로 개발 진행상황을 공유하고 QA까지 진행하고 있습니다. 개발인원이 더 늘어난다면 release branch와 release 서버는 꼭 필요하게 될 겁니다. feature branch가 너무 많아서, 선작 업된 기능들만이라도 배포가 필요한 경우에는 먼저 develop branch로 merge 하고 QA를 진행하고, 운영서버로 배포한 경우도 있을 정도로 branch만 관리하는 것도 버거울 때가 있었습니다. 최대한 git-flow 기본 전략을 지켜가면서 하려고는 하지만, 추후 인원이 늘어나서 좀 더 팀의 색깔에 맞는 전략으로의 발전을 기대하고 있습니다.
다음 글에서는 branch별로 aws(amazon)의 실제 서비스 배포까지 다뤄보도록 하겠습니다.