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

Gif-flow의 필요성

요즘 서비스를 운영하며 Git-flow가 필요하다고 생각이 많이 듭니다. 현재 운영중인 서비스는 학생 생활 관리 서비스로 대구소프트웨어고등학교에서 사용되고 있는 서비스입니다.

 

기존 Github을 이용한 협업은

upstream 레포지토리에서 각자 fork 받은 레포지토리에 작업을 push 한 후 upstream으로 Pull Request를 보내는 방식이었습니다. 브랜치는 master, develop 각각 현재 서비스 중인 브랜치, 개발 브랜치로 사용했습니다.

 

 

이 구조에서 겪은 문제점은 아래와 같았습니다

 

1. Hotfix에 대한 대응

   서비스 중인 서비스에 오류가 발생했을 경우 develop에서 수정 후 master브랜치로 올렸습니다. 이 경우 기존 개발하던 내용이 master 브랜치에 함께 올라가야 했습니다.

2. 새로운 기능

   팀원이 가 A작업을 끝낸 후 B작업을 했다면 B작업에 대한 PR을 올리기 위해서는 A작업에 대한 PR이 같이 올라가야 했습니다.

3. 배포 전 테스트

   배포를 하기 전 테스트 하기 위해서는 develop 브랜치를 사용했습니다. 이로 인해 특정 버전에 대한 테스트가 정확하게 이루어지지 않았습니다.
   
   

이런 문제점들을 느낀 후 Git-flow를 사용해야겠다는 생각을 했습니다.

Git-flow 사용하기

Git-flow를 설명하는 사진입니다. 거의 모든 글에서 이런 사진을 보았습니다. 그래서 저희 팀에서는 Git-flow를 기반으로 한 새로운 Git-flow를 사용하기로 했습니다.

 

저희가 사용할 Git-flow에 대해서 소개하겠습니다.

팀에서 사용할 Git-flow

master

현재 운영 중인 서비스의 브랜치

 

develop

개발 메인 브랜치

 

feature

기능별 브랜치

develop에서 분기 후 develop으로 병합

 

release

다음 버전을 위한 브랜치로 테스트에 사용

develop에서 분기 후 master, develop으로 병합

 

hotfix

master브랜치의 버그 수정에 대한 브랜치

master에서 분기 후 master, develop으로 병합

 

직접 Git-flow를 사용하기 위해 사용한 저장소의 history를 확인하면 더 자세하게 확인할 수 있습니다.

 

Choi-Jinwoo/Git-flow