[Git] 브랜치 전략 도입

1. 최초의 운영

Git 브랜치 전략없이 master 하나로만 운영을 해왔다.

시스템 운영자가 2~3명이였고, 하나의 화면을 동시에 수정하는 경우가 거의 없었기에 충돌이 자주 발생하지 않았다. 하지만 충돌이 발생하는 경우 overwrite 후 pull 작업이 잘 되지 않았고, reset 으로 강제 pull을 진행하곤 했다.

 

2. 개발환경 구성

IT 보안진단을 통해 dev 환경을 구성하게 되면서, dev 브랜치를 구성하게 되었다. 하지만 dev를 거쳐 prd로 흘러가는 하나의 통로일 뿐, 개발에 대한 브랜치 전략을 세우지 않아 위에서 발생한 문제가 지속적으로 겪게 되었다.

 

3. 브랜치 전략 도입

브랜치 전략에는 여러가지가 존재하지만, 먼 미래의 시스템 개발/운영의 분리를 위해 git-flow 전략을 도입한다.

 

 

master : 라이브 서버에 제품으로 출시되는 브랜치.
develop : 다음 출시 버전을 대비하여 개발하는 브랜치.
feature : 추가 기능 개발 브랜치. develop 브랜치에 들어간다.
release : 다음 버전 출시를 준비하는 브랜치. develop 브랜치를 release 브랜치로 옮긴 후 QA, 테스트를 진행하고 master 브랜치로 합친다.
hotfix : master 브랜치에서 발생한 버그를 수정하는 브랜치.

 

다소 복잡하게 생각되지만, 각 기능 개발간 철저한 분리를 통해 진행되며 개발 서버에서 철저하게 테스트된 내용만 release를 통해 배포하게 된다.