Vincent Driessen의 브랜칭 모델


"A successful git branching medel"

Vincent Driessen은 소스코드를 관리하는데 브랜치 기능을 적극적으로 활용할 수 있는 것이
git의 장점이라고 언급했다. git flow 전략은 브랜치 모델을 보다 쉽게 사용할 수 있도록
간단한 명령으로 필요한 브랜칭 동작들을 수행할 수 있도록 구현해 놓은 git의 확장이다.

Git-flow Setting (Mac-os)


맥은 HomeBrew를 이용해 설치할 수 있다.

$ brew install git
$ echo "export PATH=/usr/local/bin:$PATH" >> -/.bash_profile
$ brew install git-flow-avh

Git-flow Start


0. git clone

[ 팀장 ]

  1. 프로젝트 팀장은 새로운 Repository를 생성 후 clone한다.
  2. $ git flow init 으로 저장소를 초기화한다.
  3. $ git status 로 branch 확인 후
    $ git branch develop 하여 'develop' branch를 새롭게 생성한다.
  4. $ git touch [파일명] 작업할 파일을 생성한다.
  5. $ git add [파일명]
    $ git commit -m "commit message"
    $ git push -u origin develop
    깃허브에 develop branch 및 새로운 파일이 생성되었는지 확인 후 팀원에게 배포한다.

[ 팀원 ]

  1. 프로젝트 팀원은 팀장의 깃허브에 들어가 Fork하여 해당 Repo를 복제한다.
  2. 복제한 자신의 Repo URL을 clone한다.
    $ git clone [URL]
  3. $ git status 로 현재 브랜치 목록을 확인 후
    $ git branch develop 하여 'develop' branch를 생성한다.
  4. $ git flow init 하여 팀장이 만든 파일을 확인하고 이 후 작업을 실시한다.

1. git-flow init

git-flow를 사용하기 위해서는 git 저장소를 git-flow에 맞게 초기화 해야한다.
어떤 브랜치를 어떤 용도로 사용할 것인지 등을 명시한다.
일반적으로 Vincent Driessen이 제안한 기본 값의 브랜치 이름을 지정해 사용한다.

$ git flow init

/Users/user/workspace/test/.git/ 안의 빈 깃 저장소를 다시 초기화했습니다
No branches exist yet. Base branches must be created now.
Branch name for production release: [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]

$ git flow init -d : 기본값으로 바로 적용

2. git-flow feature branch

기능개발을 위해 다음과 같은 명령으로 새로운 feature branch를 생성한다.
$ git flow feature start [feature name]
생성된 feature branch는 feature/[feature name] 형태의 이름을 갖는다.

개발 작업이 모두 끝났다면,
$ git flow feature finish [feature name]
이 명령을 실행해 develop 브랜치로 switch한 후 feature 브랜치의 내용을 자동으로 merge,
병합이 완료되면 feature 브랜치를 삭제한다.

## PR과정이 필요한 경우
$ git flow feature finish [feature name] 이 명령 대신,
$ git flow feature publish [feature name]
이 명령을 수행하면 원격 저장소에 feature 브랜치를 push한다.
깃허브에서 팀장에게 pull request를 작성해 수정사항을 보내준다.

$ git push -u origin develop
나의 깃허브 저장소에 develop branch를 push한다.

-u 옵션 : 새로운 기능 브랜치와 동일한 이름으로 원격 저장소의 브랜치로 추가한다.
-u 옵션으로 한 번 연결한 후에는 옵션 없이 명령만으로 수행할 수 있다.

[pull request]

원격 저장소에서 feature 브랜치를 가져올 때 : $ git flow feature pull origin [feature name]
팀장이 당겨오기 : $ git pull origin develop
팀원이 당겨오기 : $ git remote add upstream [팀장 Repo URL] > $ git remote -v

변경 내용을 팀원이 모두 확인 한 후,
충돌이 일어난 경우는 팀원들과 합의 하에 충돌 내용을 수정한 후
develop branch에 병합을 진행한다.

3. git-flow release

기능개발이 끝난 후 배포작업을 진행할 release branch를 생성한다.
$ git flow release start [version]
브랜치 명은 전과 마찬가지로 release/[version] 으로 브랜치가 생성된다.

협업을 위해 원격저장소로 push할 때,
$ git flow release publish [version]

원격 저장소에서 변경사항을 가져올 때,
$ git flow release track [version]
이 때, feature 에서의 pull 과는 다르게 track 을 사용했다는 것에 유의하자!

배포 작업이 끝났으면 finish로 명령한다.
git flow release finish [version]

git flow release finish [version] 명령어가 수행하는 일
1) release branch 를 master(main) branch에 병합한 후
2) release 버전 태그를 생성한다.
3) release branch를 develop branch에 다시 병합한 후
4) release branch를 삭제한다.

마지막으로, 새로운 버전의 release branch가 병합 된 master branch를
원격 저장소에 태그와 함께 push한다.
$ git push --tags

4. git-flow hotfix

배포가 완료된 버전(출시된 버전)에 긴급하게 수정이 필요할 경우 hotfix branch를 생성해 작업한다.
$ git flow hotfix start [version]

수정 작업이 완료된 후, finish로 명령한다.
$ git flow hotfix finish [version]

$git flow hotfix finish [version] 명령어가 수행하는 일
1) hotfix branch를 master branch에 병합한 후
2) hotfix 버전을 태그로 생성한다.
3) hotfix branch를 develop branch에 다시 병합한 후
4) hotfix branch를 삭제한다.

마지막으로, 새로운 버전의 hotfix branch가 병합 된 master branch를
원격 저장소에 태그와 함께 push한다.
$ git push --tags

profile
엔프피 프론트엔드 개발자 😁

0개의 댓글