[Git] git-flow 소개, 설치 및 사용법

하나의 소스코드로 여러명의 개발자들이 협업을 하게 되면서 소스코드의 버전 관리 시스템의 중요성이 매우 높아졌다. 과거에는 SVN, CVS 같은 소프트웨어들도 많이 사용되었지만 최근에는 거의 git으로 통일되어 가는 듯 하다. (그럼에도 아직까지 파일 서버에서 소스코드를 업로드하는 원시적인 방법을 사용하는 프로젝트도 많다.)

SVN과 CVS에 비해 git이 갖는 큰 장점은 효율적인 브랜치(Branch) 관리가 가능하다는 점이다. 소스코드의 일부분을 수정하기 위해 브랜치를 생성하고 작업한 다음 원래 소스코드에 손쉽게 수정사항을 병합(Merge)할 수 있다.

Vincent Driessen의 브랜칭 모델

소스코드를 관리하는데 브랜치 기능을 적극적으로 사용할 수 있는게 git의 장점이라고 언급했다. 브랜치 기능도 효율적으로 사용하지 못하면 혼란이 더 가중될 가능성이 있다. Vincent Driessen은 효과적으로 git 브랜치 전략을 사용하는 것에 대한 제안을 했다. (링크 : https://nvie.com/posts/a-successful-git-branching-model/)

자세한 내용은 원문을 읽어보기 바란다. 약간 요약을 하자면

Author : Vincent Driessen

이런 형태로 소스코드를 관리해 나가자는 내용이다.

Vincent Driessen의 브랜칭 모델에는 5개의 브랜치가 사용된다.

• master
• develop
• feature
• release
• hotfix

각각에 대해서 설명을 해보자면

master

정식 배포되는 안정적인 버전의 소스코드가 이곳에 관리된다. master 브랜치의 HEAD는 소프트웨어의 최신 배포판의 소스코드 버전이 들어있다. master 브랜치에는 지난 배포판 버전의 소스코드를 따라가기 위해 태그(tag)들이 추가되어 있다. 이 태그를 이용해 각 릴리즈 버전의 소스코드를 빠르게 확인할 수 있다.

master 브랜치에는 배포해도 될 만큼 안정성이 충분히 검증된 코드들만이 병합되어야 한다.

develop

develop 브랜치에는 소스코드들이 끊임 없이 추가된다. 버그들을 수정하기 위한 코드와 새로운 기능을 추가하기 위한 코드, 성능을 개선하기 위한 코드들이 검증이 완료되고 PR 요청을 거치게 되면 이 곳으로 병합된다.

개발자는 feature 브랜치에서 소스코드 수정을 한 다음 develop 브랜치로 PR 요청을 하게 된다. 또 다른 리뷰어가 기능들을 검토한다음 최종적으로 develop 브랜치에 병합된다. 새로운 기능을 위한 feature 브랜치는 develop 브랜치의 HEAD에서 생성된다.

feature

새로운 기능 개발이나 버그 수정을 위한 일련의 코드 수정이 이뤄지는 브랜치다. 이 브랜치에서 개발자 혼자 작업을 할 수도 있고, 특정 기능 개발을 위한 여러명의 개발자들이 공동으로 작업할 수도 있다.

feature 브랜치에서 작업된 내용은 최종적으로 PR을 거쳐 develop 브랜치에 병합(Merge)된다.

release

git으로 관리되는 소프트웨어는 정기적으로 성능 개선, 기능추가, 버그 수정을 반영하면서 릴리즈 된다. release 브랜치는 릴리즈를 하기 위한 목적으로 생성되는 브랜치다.

release 브랜치는 develop 브랜치를 기반으로 생성된다. 다음 릴리즈에 포함되어야 하는 기능셋과 버그픽스들이 확정된 다음 생성된다. 릴리즈 브랜치가 생성된 다음 QA 테스트가 릴리즈 브랜치를 기준으로 진행된다. 이 과정에서 발견된 버그 수정 사항들이 릴리즈 브랜치와 develop 브랜치에 적용되며, 그 밖에 메이저 기능들이 중간에 추가되지는 않는다.

테스트 이후 릴리즈 브랜치의 코드가 안정적이라고 판단되면, master 브랜치에 병합되고 릴리즈에 해당하는 태그가 생성된다. 릴리즈 브랜치가 생성된 이후 반영된 수정사항들은 develop 브랜치에도 반영된다.

hotfix

여기까지 본 작업은 PR, QA 테스트 등의 작업들이 필요하다. 안정성을 높이기 위한 작업이지만 긴급한 대응에는 장애물이 될 수 있다. hotfix는 정기적인 릴리즈 이외에 긴급하게 수행되어야 할 버그 수정을 반영하기 위해 생성되는 브랜치다. 다음 릴리즈 프로세스를 기다릴 수 없을 정도로 긴급한 패치가 바로 반영되어야 하는 경우 이 브랜치를 사용한다.

hotfix 브랜치는 master 브랜치를 기반으로 생성된다. 생성된 hotfix 브랜치에 긴급한 패치들이 반영된다. 이후 hotfix 브랜치는 master 브랜치에 병합되고 태그 생성이 된다. 마찬가지로 수정 사항은 develop 브랜치로도 병합되어 긴급 수정 사항이 이후 릴리즈에도 반영되도록 한다.

git-flow

git-flow는 Vincent Driessen의 "A successful git branching model"이라는 글에서 제안한 브랜치 모델을 쉽게사용할 수 있도록 몇개의 명령으로 구현해 놓은 git의 확장이다. 간단한 명령을 이용해서 Vincent Driessen의 브랜치 모델에서 필요한 브랜칭 동작들을 수행할 수 있다.

git-flow 설치

git-flow를 설치하기 위해서는 우선 git이 설치되어 있어야 한다. git은 패키지 매니저를 이용해 쉽게 설치할 수 있다. (혹은 Download 페이지에서 운영체제에 맞는설치 파일을 다운로드 할 수 있다. (링크 :git 다운로드 페이지)

우분투의 경우 apt-get을 이용해서 설치할 수 있다.

$ apt-get install git-core

맥의 경우 HomeBrew를 이용해 쉽게 설치할 수 있다. 다만 몇 가지 추가 작업을 요한다.

$ brew install git

$ echo "export PATH=/usr/local/bin:$PATH" >> ~/.bash_profile

맥을 사용하는 경우 옛날 버전의 git을 기본으로 포함하는 경우가 있다. 따라서 새로 설치한 git을 사용할 수 있도록 PATH 환경 변수를 변경해줘야할 수 있다.

git이 설치되었으니 git-flow를 설치한다.

우분투의 경우

$ apt-get install git-flow

맥의 경우

$ brew install git-flow-avh

명령을 사용하면 된다.

기타 리눅스에서의 설치방법은 다음 링크를 참조한다 (링크 : https://github.com/nvie/gitflow/wiki/Linux)
윈도우에서의 설치 방법은 다음 링크를 참조한다 (링크 : https://github.com/nvie/gitflow/wiki/Windows)

git-flow 사용법 - init

git-flow를 사용하기 위해서는 git 저장소를 git-flow에 맞게 초기화를 해야한다. 어떤 브랜치를 어떤 용도로 사용할 것인지 등을 명시하게 된다. 디렉토리를 git 저장소로 만드는 것처럼 init 명령을 실행한다.

$ git flow init

명령을 실행하면 Vincent Driessen이 제안했던 브랜치들의 이름을 지정할 수 있다. 그냥 엔터키만 누르면 기본값으로 이름이 정해진다. (혹은 이름을 직접 입력해주면 된다.)

$ git flow init

/Users/user/workspace/test/.git/ 안의 빈 깃 저장소를 다시 초기화했습니다
No branches exist yet. Base branches must be created now.
Branch name for production releases: [master]
Branch name for "next release" development: [develop]

How to name your supporting branch prefixes?
Feature branches? [feature/]
Bugfix branches? [bugfix/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []
Hooks and filters directory? [/Users/user/workspace/test/.git/hooks]

기본값으로만 입력하고 싶다면 -d 옵션을 이용하면 된다.

$ git flow init -d

git flow init 명령으로 6개의 브랜치가 지정된다.

-master: 사용자에게 배포되는 Stable 브랜치
-develop: 다음 릴리즈를 위해 기능들을 모으는 최신 브랜치
-feature: 특정 기능 개발을 위한 브랜치
-release: 릴리즈를 위해 버그 픽스(Bug fix)를 모으는 브랜치
-hotfix: 긴급 버그 픽스를 위한 브랜치
-support: 버전 호환성 문제를 위한 브랜치

Version tag prefix 항목은 릴리즈가 master 브랜치에 병합될 때 생성되는 태그의 프리픽스(prefix) 문자열이다. 그냥 버전을 태그로 할 수도 있고, 'rel/' 같은 문자열을 앞에 넣을 수도 있다.

마지막 항목인 'Hooks and filters directory' 는 git hook을 위한 디렉토리다. 어떤 이벤트가 발생했을 때, 자동으로 특정 스크립트를 실행하도록 설정할 수 있다. 예를 들어 커밋이 발생했을 때, 자동으로 push를 하는 기능을 post-commit 파일에 저장해놓을 수 있다. 이 파일들이 위치한 디렉토리를 명시하는 곳이다.

git-flow 사용법 - feature 브랜치

버그 수정이나 기능추가를 위해 features 브랜치를 사용할 수 있다. 새로운 개발브랜치(feature브랜치)를 생성하기 위해 다음 명령을 실행하면 된다.

$ git flow feature start <feature name>

이 명령을 실행하면 develop 브랜치를 기반으로 새로운 feature 브랜치가 생성된다. 이 후 자동으로 생성된 feature 브랜치로 checkout 된다. 생성된 feature 브랜치는 feature/<feature name> 형태의 이름을 갖는다. (git-flow init 과정에서 feature 브랜치의 이름으로 다른 문자열을 써넣었다면 그 문자열이 맨 앞의 feature 대신 들어간다.)

이제 평소 git을 이용하는 것처럼 feature 브랜치에 개발을 진행하면 된다.

개발 작업이 끝나서 feature 브랜치를 마무리할 때에는 다음 명령을 실행한다.

$ git flow feature finish <feature name>

이 명령을 수행하면 git-flow가 develop 브랜치로 checkout 한 다음 feature 브랜치의 내용을 병합한다. 그리고 feature 브랜치를 삭제한다. PR 과정이 필요하다면 이 기능 대신 깃허브의 PR 기능을 이용해야한다.

깃허브에서 PR을 사용하려면 우선 리모트 저장소에 push가 되어 있어야한다.

$ git flow feature publish <feature name>

publish 명령을 수행하면 원격 저장소에 feature 브랜치를 push한다.

반대로 원격 저장소에서 feature 브랜치를 가져오려면 다음 명령을 수행하면 된다.

$ git flow feature pull origin <feature name>

git-flow 사용법 - release

릴리즈 브랜치를 생성하기 위해서는 다음 명령을 실행해준다.

$ git flow release start <version>

이 명령을 실행하면 release/<version>이라는 릴리즈 브랜치가 생성된다. (마찬가지로 git flow init 과정에서 release 브랜치로 사용할 브랜치 명이 release 문자열 부분에 들어가게 된다.) 이 브랜치에 릴리즈 과정에서 수정된 내용들이 들어가면 된다.

feature 브랜치처럼 깃헙 등에서 협업을 하기 위해 원격 저장소로 push 할 수 있다.

$ git flow release publish <version>

반대로 원격 저장소에서 변경사항을 가져오려면 다음 명령을 수행하면 된다.

$ git flow release track <version>

pull 이라는 키워드 대신 track 이라는 키워드를 사용했음을 유의해야한다.

릴리즈 준비가 끝났으면 finish를 통해 마무리한다.

$ git flow release finish <version>

이 명령을 수행하면

1) release 브랜치를 master 브랜치에 병합(merge) 하고
2) release 버전을 태그로 생성한다. 이 때, git flow init 에서 명시한 Version tag prefix 문자열이 release버전 앞에 추가되어 태그로 생성된다.
3) release 브랜치를 develop 브랜치에 병합한다.
4) release 브랜치를 삭제한다.

마지막으로 새로운 릴리즈가 포함된 master 브랜치를 원격 저장소에 태그와 함께 push 한다.

$ git push --tags

git-flow 사용법 - hot fix

긴급 패치 적용을 위한 Hot Fix 브랜치도 git flow를 이용해 생성할 수 있다.

$ git flow hotfix start <version>

마찬가지로 hotfix/<version> 브랜치가 생성되고 checkout된다. 버그를 고치자.

$ git flow hotfix finish <version>

명령을 수행하면

1) hotfix 브랜치를 master 브랜치로 병합한다
2) hotfix 버전을 태그로 생성한다. 마찬가지로 git flow init 에서 명시한 Version tag prefix 문자열이 hotfix 버전 앞에 추가되어 태그로 생성된다.
3) hotfix 브랜치를 develop 브랜치에 병합한다
4) hotfix 브랜치를 삭제한다.

마지막으로 새로운 핫픽스가 포함된 master 브랜치를 원격 저장소에 태그와 함께 push 한다.

$ git push \--tags

Reference

Using git-flow to automate your git branching workflow
A successful Git branching model
git-flow cheatsheet