Git-Flow 와 진행과정

2 분 소요

Git-Flow 란 사례 혹은 프로그램을 의미할 수 있다. 여기서는 사례에 의거해서 설명하고 기본적으로 서로간의 약속인 방법론이다. 그렇다고 Git-Flow 가 완벽한 방법론은 아니고 각자 개발환경에 따라 수정하고 변형해서 사용하게된다.

기본적으로 Git-Flow 는 5개의 브랜치를 운영한다.

master : 기준이 되는 브랜치로 제품을 배포하는 브랜치
develop : 개발 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 병합(Merge) 한다.
feature : 단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치로 병합한다.
release : 배포를 위해 master 브랜치로 보내기 전에 먼저 QA(품질검사)를 하기 위한 브랜치
hotfix : master 브랜치로 배포를 했는데 버그가 생겼을때 긴급 수정하는 브랜치.

기본적인 흐름은 아래 그림처럼 진행된다.

master 브랜치의 경우 언제나 실행 가능한 상태를 유지해야한다. 그리고 실행 가능한 상태를 만들어가는 과정은 develop 브랜치에서 만든다.

시작

시작은 git init 명령어를 통해 시작을 하게 된다. 해당 로컬에 git 이 구성되면 테스트를 위해 main.txt 파일을 만들어 놓고 해당 파일을 commit 해보자.

master 에서 기준이 되는 지점에 tag 를 사용해 버전을 붙인다. 그러다 기능개선이 필요하다 생각되는 부분을 다 develop 브랜치에서 작업하게 된다.

배포준비

기능개선을 끝마치고 버그도 다 잡앗다 가정을 해보자 그럴경우 우리는 새로운 버전에 대한 release 준비를 하게된다. 이 부분을 release 브랜치에서 작업하게 되고 만약 release 에서 작업하다 버그가 생길경우 release 에서 대응하게 된다.

결국 release에서 작업된 내용들은 추후 master 나 develop 로 병합되어야 할 부분들이다. 그러므로 자주자주 병합을 진행해서 충돌(Conflict)이 덜나도록 해야한다. develop 브랜치에 병합을 완료하고 나면 master 브랜치에도 병합을 하는데 보통 기본적인 병합을 하게되면
git fast-foward 정책으로 병합이 되어 흔적이 남지 않게 된다. 하지만 여기선 --no-ff 를 사용해 non-fast-foward 로 병합을 진행하도록 하자

(develop 병합)

(master 병합 –no-ff 를 사용)

release 브랜치는 이제 역할을 다 했기 때문에 해당 브랜치를 삭제하고 master 브랜치에선 맨첨에 한것처럼 버전명을 붙여 tag 를 지어준다.

기능추가

이제 release 도 마쳤고 만약 신규기능을 추가한다 생각해보자. 하나는 금방되는거 하나는 오래걸리는거 두개가 있다 가정하고 그러다 기존에 있던 문제와 신규로 만들고 있는 기능에 대한 작업이 끝날경우 출시준비를 하게된다.

만약 short 를 출시한다고 가정하면 똑같이 develop 브랜치와 병합하고 (no ff) 새로운 release/1.0 브랜츠를 만들어 체크아웃하게 된다.

그러다 또 만약 새로 추가한 short 기능에 이슈가 있다 가정을 해보면 release 브랜치에서 버그픽스를 진행하고 올리게 된다. (신 기능외에 버그 또한 여기서 다 수정하게 된다.)
버그도 잡고 모든 작업을 완료했을 경우 다시 develop 브랜치와 병합 및 master 브랜치와 병합을 하고 해당 기능 브랜치를 삭제까지 하면 완료가 된다.

핫픽스 발생

만약 정말 치명적인 이슈가 생겼다고 가정을 해보자 이럴경우 master 에서 바로 branch를 만들어 거기서 대응을 하게 되고 대응을 마친후에는 앞에 과정과 똑같이 develop 과 master 두곳에 병합해 반영하고 마지막으로 branch 를 제거해줌으로써 마무리 되게된다.