오늘은 회사 프로젝트에서 git-flow Custom 적용에 대해 얘기해보려 한다.

밑 항목들을 이용했었다.

  • Git Lab
  • SourceTree



왜 굳이 Custom 했을까?


git-flow는 보통 아래와 같이 총 5가지로 나뉜다.

  • 기능을 개발하는 featrue

  • 개발 중인 기능을 병합한 develop

  • 배포를 준비하기 위한 release

  • 배포 버전 master

  • 배포 버그 수정 hotfix


하지만, 이것은 지속적인 하나의 서비스를 개발할 때 work flow 기준의 git-flow이다.

서비스를 개발하는 회사는 하나의 서비스를 다른 여러가지의 버전으로 개발하지만.

프로젝트의 life-cycle이 순환형임.

같은 프로젝트에서 기획, 개발, QA, 배포가 한 날 한 시에 다른 버전으로 이루어질 수 있다.


우리 회사는 계약이 수주될 때마다 새로운 프로젝트를 만들고, 계약에 정해진 기능만, 또 정해진 기간에만 개발을 한다.

서비스 개발과는 다르게, 프로젝트가 직선형으로 진행된다.

프로젝트의 life-cycle이 직선형임.

기획/디자인 -> 개발 -> 테스트 -> 출시


이처럼 work flow가 다르니, git-flow도 달라질 수 밖에 없는 법 !



Git-flow in 🏢


위에서도 말했듯이 우리의 work flow는 직선형이다.

서비스 개발과 다른 것을 구체적으로 정리해보면,

1. 개발 도중에 배포를 준비할 일이 없다.

2. 배포한 이후로는 계약이 종료된 것이므로 더 이상 개발이 이루어지지 않는다. 

3. 즉, 배포한 이후로 버그가 발생했을 때는 개발 중인 상태가 아니라는 말이다.

이렇게 정리할 수 있다.

그럼 뭘 어떻게 묶을지 대충 보이기 시작할 것이다.


feature, develop, release, hotfix, master

=> feature, develop(release, hotfix) , master

이렇게 큰 틀 세가지로 묶을 수 있었다.


위 처럼 custom한 git-flow를 아래와 같이 사용했다. (총 3명에서 개발을 진행)

  1. feature에서 기능 개발 (feature)

  2. develop에서 코드 리뷰 후 merge (develop)

  3. 개발을 마칠 때까지 1, 2번 반복

  4. develop에서 테스트 등 open 준비 (release)

  5. master에 반영 후 open (master)

  6. develop에서 버그 발생 시 fix (hotfix)