[Git] 브랜칭 기법

Git에서는 브랜치를 아주 자유롭게 만들 수 있어 작업을 분할하기 좋지만, 브랜치를 효과적으로 관리하지 못하면 의미가 없어지게 됩니다. 따라서 프로젝트의 참여자 전체가 브랜치를 다루는 방식을 통일하는 것이 좋습니다. 새로운 브랜치의 생성 조건, 브랜치 네이밍, 통합 조건 등등의 규칙들입니다. 여기서 설명하려는 브랜칭 기법들은 일반적으로 브랜치를 통합 브랜치(Integration Branch)와 토픽 브랜치(Topic Branch)로 나눕니다.

통합 브랜치(Integration Branch)

통합 브랜치란 언제든지 배포할 수 있는 버전을 만들 수 있어야 하는 브랜치 입니다. 그렇기 때문에 늘 안정적인 상태를 유지하는 것이 중요합니다. 만약 어떤 문제가 발견되어 그 문제(버그)를 수정하거나 새로운 기능을 추가할 때, 토픽 브랜치를 만듭니다. 처음에는 보통 통합 브랜치에서 토픽 브랜치를 만들어 냅니다.

일반적으로 저장소를 처음 만들었을 때에 생기는 master 브랜치를 통합 브랜치로 사용합니다.

토픽 브랜치(Topic Branch)

토픽 브랜치란, 기능 추가나 버그 수정과 같은 단위 작업을 위한 브랜치 입니다. feature_x, feature_y, hotfix_z와 같은 형태의 브랜치들입니다. 여러 개의 작업을 동시에 진행할 때에는, 그 수만큼 토픽 브랜치를 생성하는 방식입니다.

토픽 브랜치는 보통 통합 브랜치로부터 만들어 내며, 토픽 브랜치에서 특정 작업이 완료되면 다시 통합 브랜치에 병합하는 방식으로 진행됩니다.

Git-flow

Git-flow는 Vincent Driessen의 'A successful Git branching model'을 적용하여 코드를 관리하는 전략입니다. Vincent의 브랜칭 모델은 'feature - develop - release - hotfixes - master'의 형태로 브랜치를 나누는데, git-flow도 별반 다르지 않습니다.

git-flow의 주요 브랜치는 master와 develop입니다. 이 브랜칭 전략에서는 새 버전을 배포하기 위해 master 브랜치에 병합합니다. master 브랜치로 커밋될 때 git hook 스크립트를 걸어서 자동으로 빌드하고 운영 서버로 배포하는 형식을 취합니다.

feature

다음 버전을 위해 개발하는 코드는 develop에서 관리합니다. 그러나 이 브랜치 하나로는 한계가 있기 때문에, 보조 브랜치들을 사용합니다. 기능 개발을 위해 feature 브랜치를 사용합니다. develop에서 시작하고, 병합도 develop을 향합니다. feature 브랜치는 그 기능을 다 완성할 때까지 유지하고 있다가 다 완성되면 develop 브랜치로 병합합니다.

release

release 브랜치는 실제 배포할 상태가 된 경우에 생성하는 브랜치입니다. develop에서 시작하고, 병합은 develop과 master에 합니다. 지금까지 개발한 기능을 묶어 develop 브랜치에서 release 브랜치를 따내고, develop 브랜치에서는 다음번 릴리즈를 위한 준비, release 브랜치에서는 버그픽스에 대한 부분만 커밋하게 되고 릴리즈가 준비되었다고 생각하면 master로 머지를 진행합니다. 이후 tag 명령을 이용하여 릴리즈 버전에 대해 명시합니다.

hotfix

production 과정에서 발생한 버그들은 전부 hotfix로 이동합니다. master에서 시작하고, 병합은 develop과 master에 합니다. 이미 배포한 운영버전에서 발생한 문제를 해결하기 위해 만드는 브랜치입니다. 운영 버전에 생긴 치명적인 버그는 즉시 해결해야 하기 때문에, 마스터 브랜치에 만들어둔 태그로부터 hotfix 브랜치를 생성합니다.

git-flow는 꽤 오래 전에 나온 전략인데, git-flow만의 단점(브랜치가 많아 복잡하고, 안 쓰는 브랜치가 있으며 몇몇 브랜치의 포지션은 애매함)을 극복하기 위해 github flow와 gitlab flow 전략이 나왔습니다.

Github-flow

Github-flow는 배포가 정기적으로 이루어지는 프로젝트를 위한 브랜치 기반 workflow입니다. 브랜치 전략이 단순하고, Pull request 위주로 각 브랜치들의 변경 사항을 머지하므로 코드 리뷰를 자연스럽게 수행할 수 있습니다. Git flow는 좋지만, Github에서 사용하기에는 복잡하다는 입장에서 만들어졌습니다.

브랜칭

브랜칭은 git의 핵심 개념이며, 전체 Github flow는 이를 기반으로 합니다. Github flow에서는 브랜치에 대해 딱 한가지 규칙만이 있는데, master 브랜치의 모든 항목은 항상 배포 가능한 상태여야 한다는 것입니다. 따라서, 기능 구현이나 수정 작업을 할 때 master에서 브랜치를 생성해야 합니다.

Github-flow에서는 브랜치 네이밍, 브랜치 생성, 삭제에 관한 규칙도 따로 없으며, master 브랜치에 대한 규칙 하나만 정확하면 됩니다.

커밋

브랜치가 생성되고 나면, 변경 사항을 만들어낼 것입니다. 파일을 추가, 편집, 삭제할 때마다 커밋을 추가하게 됩니다. 각 커밋에는 관련된 변경 메시지가 있으며, 이는 해당 변경이 이루어진 이유를 설명합니다. 각 커밋은 별도의 변경 단위로 간주되며, 따라서 특정 커밋으로 돌아가거나, 복구하는 데에 편한 환경을 만들어낼 수 있습니다.

Pull request

Pull request는 Github-flow의 가장 중요한 요소입니다. 브랜치 간의 병합을 위해 단순히 merge만을 사용하지 않고, 한 번의 리뷰를 거치도록 변경 사항을 '요청'하는 일입니다. 따라서 Pull request라는 개념은 특히 오픈 소스 프로젝트의 기여에 자주 사용됩니다. 개발 프로세스 중 언제라도 Pull request를 열 수 있고, 이는 해당 브랜치의 변경 사항에 대한 토론을 시작합니다. Github-flow에서 Pull request는 master 브랜치에 변경 사항을 병합하기 전에 코드를 리뷰하기 위한 용도로 자주 사용됩니다.