Git-flow를 이용한 프로젝트 관리

들어가기에 앞서

이제는 정말 많은 개발자들이 git을 이용해서 프로젝트를 관리한다. 협업에서도 그렇고 토이 프로젝트를 만들 때도 git은 이제 절대 떨어질 수 없는 존재가 되었다. 그리고 이 git을 활용한 다양한 협업방법중 하나인 git-flow가 있다. git-flow의 단점들을 보안하기 위한 github-flow나 gitlab-flow등도 있지만 여기서는 git-flow만 알아보도록 하자.

 

이건 개인적인 의견이지만 git을 branch로 나눠서 사용하고 merge해보는 등의 적극적인 활동을 해보지 않고는 git-flow에 대해서 이해해보기 힘들 수도 있다. 또한 커밋이나 병합등의 작업으로 가지가 뻗어나오는 것을 경험해보지 못한 사람들도 이해하기 힘들 수도 있다. 먼저 git에 대해 어느정도 이해하고 혼자서 사용해본 후에 이 글을 보는 것이 좋을 것이다.

 

 

 

 

 

Git-flow전략

git-flow는 결국 소프트웨어의 소스코드를 관리하고 출시하기 위한 '브랜치 관리 전략'이다. git을 사용해서 커밋, 병합을 하면 브랜치에 따라서 여러 가지들이 뻐져나오기 마련인데 이런 브랜치의 특성을 활용해서 더 수월하게 협업할 수 있도록 만든 전략이다.

 

git-flow를 설명하는데 완벽하다고 불리는 사진이 있다.

이것이 git-flow의 진행 흐름이다. 총 5개의 브랜치로 나뉘어서 진행된다.

• master : 출시가능한 브랜치(출시되었거나 출시예정인상태)
• develop : 다음 출시버전을 위해서 개발을 진행하는 브랜치
• feature : 새로운 기능을 개발하기 위한 브랜치
• release : 이번 출시버전을 준비하는 브랜치
• hotfix : 출시 버전에서 발생한 버그를 수정하는 브랜치

 

 

 

 

 

git-flow에서 사용하는 브랜치들의 특징

git-flow에서 가장 중심이 되는 주요 브랜치는 master와 develop 이 2개의 브랜치이다. 나머지 브랜치들은 모두 이 브랜치에서 뻗어나오는 보조 브랜치라고 할 수 있다.

 

(1) master

직접적으로 배포를 하는 브랜치로서 모든 브랜치들은 master에서 뻗어나가고 master로 돌아온다. 새로운 기능들이 추가되어 master에서 합쳐지면 마지막으로 버전태그를 추가한다.

 

(2) develop

master에서 뻗어나온 주요 브랜치이다. 다음 출시버전을 위한 새로운 기능에 대한 개발이 이루어지는 브랜치이지만 이 브랜치에서 직접 개발되는 것이 아니라 이 브랜치에서 새로 뻗어 나가는 feature브랜치에서 개발되어 여기서 합쳐진다.

 

(3) feature

develop에서 뻗어나온 브랜치로서 새로운 기능을 개발하는 브랜치이다. 각 기능별로 브랜치를 만들어서 완성된 것들부터 develop에 merge하여 다시 하나로 합쳐진 뒤 이 브랜치는 삭제된다.

 

(4) release

delveop에서 완성된 브랜치가 새로운 버전 출시를 준비하는 브랜치이다. 모든 코드가 배포 준비를 마치고 마지막으로 QA로 넘어가서 테스트를 하는 단계이다. 여기서 에러가 발생한다면 코드를 수정하고 계속해서 진행한다. 완성된 코드는 master와 develop에 모두 merge된다.

 

만약 중간에 수정된 코드가 develop에 돌아가게된다면 그 코드는 다음 release에서 배포될 것이다. 즉, 다음 버전에서 배포되는 것이다.

 

(5) hotfix

배포후에 발견되는 긴급한 에러를 처리하기 위한 브랜치이다. master에서 뻗어나오며 에러가 수정되면 master와 develop모두에게 merge한다.

 

 

 

 

 

 

git-flow를 적용한 진행과정

이번에는 프로젝트가 진행되었을 때 구체적으로 어떤식으로 분리되고 개발되고 합쳐지는지 위의 사진을 쪼개서 알아보도록하자.

 

(1) master와 develop생성

가장먼저 master와 develop이 생성된다. git init을 통해 git을 만든 후 develop을 따로 추가하는 방법도 있겠지만 git flow init을 사용하면 자동으로 develop까지 생성할 수 있다.

 

(2) develop에서 feature분리 후 병합

새로운 개발 할 기능이 있다면 develop에서 feature브랜치를 분리시킨다. 그리고 완성된 기능은 다시 develop으로 병합시킨다. 추가된 2개의 feature브랜치 중 1개는 아직 완료되지 않아서 1개만 병합하는 과정이다.

 

(3) release브랜치에서 최종확인

모든 기능이 완성되어 develop브랜치에 합쳐지면 release브랜치로 보내서 최종점검을 해야한다. release를 생성한 후 해당 코드를 QA로 넘겨 테스트를 진행한다. 만약 중간에 에러가 발생한다면 해당 에러를 수정한 후 최종적으로 master와 develop에 병합한다.

 

release에서 중간에 빠져나온 develop으로 가는 merge는 새로운 feature을 만들어서 다음 release때 병합되어 사용된다.

 

(4) 배포 후 나타나는 에러는 hotfix를 만들어서 처리

master애서 새로운 버전으로 배포를 했는데 이후에 크리티컬한 장애가 나타날 수 있다. 이런 경우에는 develop으로 가서 처리 후 다시 돌아오는 것이 아니라 hotfix라는 브랜치를 생성해서 작업한다.

 

수정이 완료된 코드는 master와 develop에 merge되어 계속해서 이어나가도록 한다.