[Git] Git Flow

들어가며

현재 회사를 다니고 있는 저는 입사 5개월만에 신입 개발자분을 팀 내에 받게 되었습니다. 저는 팀에 신입으로 들어올 때 개발 인원이 너무 적기도 했고, 바쁜 개발일정 때문에 다들 허덕이고 계셔서 철저하게 구성된 온보딩이나 문서가 없었고, 많은 것들을 몸으로 부딪히며 힘겹게 얻어야 했습니다.

그래서 아직 전부 알지는 못하지만, 아는 지식 선에서 짜내어 여러 문서를 작성했고, 나름 능숙하게 사용하고 있는 git flow를 피그잼으로 그림까지 만들어 문서화를 마쳤습니다.

이는 비단 팀 내에서만 사용되는 것은 아니고, 규모가 있는 개발팀에서 사용할 수 있는 구조이며, 내부 보안상 문제는 없을 것이라 판단되어 실무에서는 git flow를 어떻게 사용하고 있는지 소개하고 기록을 남기고자 글을 옮기게 되었습니다.

git flow와 서버 환경

ATS와 JOBDA는 서버를 공유합니다. pr, st, st2, dv 라는 4개의 서버를 운영하고 있습니다.

이 서버 환경을 설명하기 위해 git flow와 branch에 대한 이해가 필요할 것 같습니다.

git flow와 함께 설명하도록 하겠습니다.

아래부터는 git flow에 대한 이해가 필요한 글입니다.

시작은 dv

dv는 개발 서버를 의미하는 development의 축약어입니다. 그리고 개발 스프린트의 시작점인 develop branch가 있습니다. 이 두 가지를 혼동하지 않도록 주의하세요.

스프린트를 시작하면, 개발은 아래의 과정을 밟습니다.

1. develop branch로부터 release/vX.X.X branch를 만듭니다.

• 이 release branch는 해당 스프린트에서 각 개발자들이 개발한 내용을 모으는 branch입니다.

2. release/vX.X.X로부터 feature/ATS-XXXX branch를 따서 개인 개발을 시작합니다.

• prefix는 기능개발은 feature, 오류 해결은 bugfix 입니다.
• 뒤의 ATS-XXXX는 Jira 이슈 번호입니다.
• [Tip] local에서 충돌 해결을 위해 Pull Request를 위한 origin push 이전에 pull을 하도록 합시다.

3. 스프린트 기간을 마치면 QA셀에 입고합니다.

여기서 필요한 개념이 배포입니다.

배포

지금까지는 로컬 환경에서 3000번 포트로 개발을 진행했습니다. 로컬 작업 환경이 아니라, ‘실제 주소에서 우리의 작업내용을 확인할 수 있도록 한다‘는 것으로 배포의 의의를 가집니다.

release/vX.X.X branch는 이번 스프린트에서 우리 셀에게 주어진 개발 업무의 결과물입니다. 이를 QA셀에서 확인하여 기획 명세, 디자인 명세처럼 잘 그려졌는지, 제대로 동작하는지, 문제는 없는지 꼼꼼하게 확인(검증)을 해주십니다.

QA는 개발 직군이 아니기 때문에 QA를 진행하기 위해서는 배포가 필요하고, 이 배포까지의 개발을 마치고 배포를 진행하여 QA셀에게 우리의 작업이 닿게 하는 것을 ‘입고한다’고 합니다.

그리고 이 시점까지는 기능 개발, 그리고 이 시점 이후에는 QA셀에서 발견한 오류를 해결하는 일이 주업무이므로 이 시점을 기준으로 branch의 prefix가 feature에서 bugfix로 변화하게 됩니다. 이렇게 검증이 이루어지고, 오류 해결을 반영하는 기간을 ‘검증기간’이라고 합니다.

배포는 정기, 또는 필요에 의해 불시로 이루어집니다.

정식 배포 시각은 없지만, 검증 기간에는 보통 일 1~3회 정도 배포가 이루어집니다. 하지만 필요한 경우 release/vX.X.X에 반영 후 배포를 진행할 수 있습니다. 배포에 관해서는 이후에 더 자세히 다루겠습니다.

여기서 기억하고 넘어가야 할 점은,

• 배포를 해야 QA셀에서 확인할 수 있다.
• release/vX.X.X branch가 st2 서버에 반영된다.

입니다.

st2 서버는 뭐죠?

위에서 QA셀에 입고할 때 st2 서버에 입고한다고 했습니다. st2 는 staging2의 축약어로 QA셀에서 스프린트 개발 내용을 확인할 때 대표적으로 사용하는 QA서버입니다.

그런데, 여러 스프린트가 동시에 진행되는 경우가 간혹 있을 때, sprint1, sprint2의 개발 영역이 서로 독립적이어야 할 때에는 st서버 (staging) 나 dv까지 사용하기도 합니다(보통 st는 hotfix 개발 검증용 서버로 사용). 이는 QA셀과 개발 셀에서 공유하며, 모든 개발 스프린트의 종착지는 pr 서버입니다.

대표적인 QA 서버가 st2 서버이므로 아래 예시로는 st2로 계속 이어가겠습니다.

4. 검증을 마치면 대망의 pr 서버 배포

검증기간은 pr 서버에 배포를 하며 끝이 납니다.

pr 서버는 production 의 축약어입니다. 말 그대로 기업을 넘어 고객에게 닿는 우리 서비스의 최종본입니다. pr 서버에 배포하기 전까지 release/vX.X.X branch에 코드를 반영하다가, 최종 반영하는 것을 ‘코드 프리징(code freezing)’이라고 합니다. ‘이후로는 건들지 말라’는 의미이죠.

pr 배포는 개발/비개발을 가리지 않고 전사적으로 동시에 진행되며, 유관부서와의 배포는 순서가 있어 동시에, 또는 순차적으로 진행됩니다.

5. pr 배포 후 branch 정리

지금까지는 생략했지만, 또다른 핵심 branch로는 production branch가 있습니다. 현재 pr 서버에서 동작중인 서비스의 코드는 production branch의 코드라고 생각하면 되겠습니다.

이렇게 release/vX.X.X가 pr 배포가 되었다면, 이 시점의 pr 서버의 코드인 release/vX.X.X 가 곧 production branch가 되어야 하기 때문에 release/vX.X.X를 production 로 merge해줍니다.

또한 한 가지는 develop branch를 최신화하는 일입니다. release/vX.X.X (production 과 동일)가 이후 개발의 시작 기준점이 됩니다. 때문에 production branch를 develop branch에 merge하며 이후 개발 스프린트 시작을 준비하게 됩니다.

6. pr 서버 코드에 문제가 있는 경우

우리가 열심히 개발하고, QA셀에서 열심히 검증한 코드임에도 불구하고, 실제 서비스 환경에서 문제가 발생될 수 있습니다. 그렇다면 우리는 빠르게 이를 해결하고 pr 서버 코드에 반영해야 할 것입니다. 이때 필요한 branch가 hotfix/vX.X.X 입니다.

hotfix/vX.X.X 는 production branch로부터 따게 됩니다. 당연합니다. pr 서버는 production branch로 반영되어 있기 때문입니다. 이때 X.X.X가 중요합니다.

hotfix

보통 개발 스프린트는 release/v3.1.0, release/v2.7.0 과 같이 끝 번호를 0으로 합니다. 예를 들어 release/v3.1.0 이라고 해보겠습니다. 이를 production branch에 반영한 뒤, production branch에서 변경사항이 생겼을 때, production branch에서 hotfix/v3.1.1 을 뽑아냅니다.

그리고 hotfix/v3.1.1 로부터 개인의 오류 해결 branch를 하나 뽑아내고, 오류 내용을 처리한 뒤, 다시 hotfix/v3.1.1 에 반영합니다.

그리고 개발자 자체 검증, 또는 QA셀 입고 후 검증 과정 이후 hotfix/v3.1.1 이 production branch에 반영이 됩니다. (만약 QA 검증이 있었다면 st 등의 서버에 배포하는 과정이 있겠지만 그림에서는 생략하겠습니다.)

핵심은 production branch로의 재반영이지만, 추가로 develop branch에도 반영을 해줍니다. 개발 스프린트 때와 마찬가지로 production branch에서 develop branch로 merge를 진행합니다.

hotfix 버전 배포를 기점으로 이후에도 버그가 발견된다면 hotfix/v3.1.2, hotfix/v3.1.3 등으로 계속 minor 버전을 올려가며 pr 서버 버그에 대응합니다.

branch와 환경 remind

서버 환경

용어	내용
pr	• production : 실제 서비스 환경 • 실제 서비스 환경이므로 주의 또 주의할 것
st2	• staging2 : 스프린트 개발 QA 검증 서버 • 검증용 데이터가 많음
st	• staging: 핫픽스 개발 QA 검증 서버 • 스프린트가 여러 개 돌아가는 경우 기능 개발 검증용으로도 사용
dv	• development: 스프린트 개발 개발자 서버 • 양질의 기존 데이터는 많이 없음 • 자유롭게 데이터를 추가/삭제하는 개발자들의 공간

git flow 전략

branch명	설명
production	현재 pr 서버가 운용하는 서비스의 코드 상태
develop	현재 진행중인 개발 스프린트의 시작점 코드 상태
hotfix	• pr 환경에서 보고된 버그를 해결하기 위한 branch • pr 환경 반영 후 production, develop에 merge
release	• 진행중인 개발 스프린트의 결과물 반영 코드 • QA셀 검증을 위해 st2, st 서버 등에 배포 • pr 환경 반영 후 production, develop에 merge
sprint	• 이제는 사용하지 않는 branch prefix입니다. [deprecated] • 기존에는 개발 스프린트 시작을 sprint/X-X 으로 하고, QA 입고 시 release/vX.X.X으로 운영하였으나, 구분이 불명확해져 release/vX.X.X 방식으로 통일하였습니다.