Git flow 이해하기

Intro

회사에서는 Git과 Git-flow를 매우 익숙하게 사용하고 있지만.. 버튼 몇 번만 누르면 다 해주는 방식을 계속 써왔다 보니(fork 사랑해요)

또 아무 생각 없이 사용하는 나 자신을 발견하게 되어 팀장님에게 말로 맞은 겸 정리할 겸 오랜만에 글을 작성해보았습니다.

 

 

git flow의 시작, git flow init

 

우리가 처음 깃허브에 레파지토리를 만들 때 맨 처음 git init 명령어를 사용하는 것을 보았을 겁니다. git flow init은 이 보다 확장 된 명령어 이며, develop브랜치를 생성하여 분기처리를 하는 것 이외에는 아무런 영향을 주지 않습니다.

 

<참고>

git init은 새로운 깃 레파지토리를 생성을 하게 됩니다. 프로젝트 root directory에서 숨겨진 파일목록 보기를 클릭해보면 .git 이라는 파일이 생성되어 있는데요, 해당 파일에서 깃에 필요한 모든 기능을 담당하게 됩니다.

 

 

develop & main branch

main(구 master)

예전에는 master 였지만 최근엔 main으로 명칭이 변경되었습니다. main 브랜치는 공식적으로 배포된 모든 버전들을 tracking 합니다. 때문에 tag를 배포와 동시에 같이 커밋하게 되면 보다 편하게 관리를 할 수 있습니다.

 

main(=master) 브랜치는 지금까지 작업 된 것들의 요약본이라고 생각하면 됩니다.

 

develop

지금까지 개발 된 모든 프로젝트의 히스토리를 가지고 있는 브랜치입니다. 처음으로 프로젝트를 clone 받았다면 이 develop브랜치를 트랙킹할 develop 브랜치를 로컬에 반드시 생성해야 합니다.

$ git branch develop  # creating local branch
$ git push -u origin develop # 원격 develop 브랜치 tracking

 

위에서 언급했듯이, 위 코드블럭 내 작업을 git flow init 이라는 명령어 하나로 대체할 수 있습니다.

 

 

Feature branch

최신으로 업데이트 된 develop 브랜치에서 분기 처리가 되어야 하며, 작업 후 develop 브랜치로 merge 되어야 합니다.

개발 되어야 하는 프로젝트의 세부 기능들을 쪼개어 feature 브랜치에서 작업하고, develop으로 병합하여 develop 브랜치에 모든 개발 히스토리가 보여지도록 합니다.

$ git checkout develop  # 현재 작업브랜치 Index 변경, 모든파일도 해당 브랜치의 내역으로 업데이트 진행
$ git checkout -b feature_branch  # 로컬에 feature_branch 라는 이름의 브랜치를 생성

 위 작업을 git flow를 활용하면 아래와 같이 하나의 명령어로 대체할 수 있습니다.

$ git flow feature start feature_branch

작업이 종료되었을 경우, 이제는 develop으로 merge를 해야합니다. 

$ git checkout develop
$ git merge feature_branch

이 작업을 git flow를 통해 한 줄의 명령어로 실행할 수 있습니다.

$ git flow feature finish feature_branch

 

Release branch

이제, 모든 프로젝트의 기능들이 마무리 되었고, develop 브랜치에도 머지가 완료되어 배포를 준비하게 됩니다. 모든 배포 버전들은 main에서 관리하기 때문에 main으로 merge를 해야합니다. release 브랜치를 생성하기 전에 develop/master 를 모두 fetch + pull 받아 최신상태로 업데이트 후, develop 브랜치에서 분기처리하여 새로 생성을 합니다. 주의할 점은, release 브랜치가 생성되면 새로운 배포버전이 생성이 되는 것이기 때문에 해당 브랜치 생성 이후, (원칙적으로는) 새로운 feature 기능을 작업해서는 안됩니다. (버그 수정, 문서화 등은 예외) 이 브랜치를 통해서 main 브랜치로 merge가 되며, 배포버전을 명시한 tag가 함께 merge 됩니다.

 

이렇게 하여 main에서는 release 브랜치가 merge 된 내역을 조회하여 손 쉽게 어떤 배포버전에서 어떤 기능들이 추가되었는지 확인할 수 있게 됩니다.

$ git checkout develop
$ git checkout -b release/0.0.0

git flow 명령어로는 아래처럼 한 줄의 명령어로 실행할 수 있게 됩니다.

$ git flow release start 0.0.0   # Switched to a new branch 'release/0.0.0'

release 브랜치를 통해 배포 될 기능들을 확인하고 main으로 merge를 합니다. 

git 명령어로도 할 수 있지만, git flow 명령어를 통해 쉽게 처리할 수 있습니다. git flow 명령어를 활용하면 자동으로 release 브랜치를 삭제시켜줍니다.

$ git checkout main
$ git merge release/0.0.0


# git flow
$ git flow release finish '0.0.0'

 

 

Production에서 버그 발견으로 긴급패치가 필요하다..! hotfix branch

 핫픽스 브랜치는 릴리즈 브랜치와 상당부분 유사하게 보입니다. 다른 점이 있다면 위에 설명한 브랜치들과 다르게 분기 시작 지점이 main이라는 점입니다. 핫픽스 브랜치가 유일하게 main 브랜치에서 시작합니다.

 

핫픽스 브랜치는 반드시 develop과 main 두 브랜치에 merge가 되어야 합니다. 그리고, main에는 업데이트 된 버전명이 적힌 tag도 함께 올라가야 합니다. tag를 함께 명시함으로써, 팀원들에게 버그를 공유하고 또 다른 배포주기에 오류가 생기지 않도록 합니다.

$ git checkout main
$ git checkout -b hotfix_branch

# git flow 명령어
$ git flow hotfix start hotfix_branch

 

핫픽스 마무리 후, main과 develop에 모두 merge 하는 작업을 진행합니다.

$ git checkout main
$ git merge hotfix_branch
$ git checkout develop
$ git merge hotfix_branch
$ git branch -D hotfix_branch  # 해당 브랜치 삭제

# git flow 명령어
$ git flow hotfix finish hotfix_branch

 

 

References

https://git-scm.com/doc

Git - Documentation

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

Gitflow Workflow | Atlassian Git Tutorial