[Git] 브랜치 전략 구성

회사를 다니다 보면 형상관리의 중요성에 대해 많이 느낀다.

이전 직장에선 당연히 지금 소개 하려는 전략을 구성해서 사용하고 있었기 때문에 중요성을 크게 느끼지 못했는데, 지금 회사에서는 형상관리가 안된 소스를 가지고 유지보수, 개발하는 프로젝트가 몇몇 있어서 머리 아플때가 참 많다..

일일이 운영 소스와 관리 안된 소스를 비교 해가면서 맞추는데 이때 또 사용하는 기똥찬 프로그램이 하나 있는데 이건 나중에 설명하도록 하겠다.. (WinMerge)

거두절미하고 이전 직장에서 구성해서 사용했던 브랜치 전략에 대해 소개하겠다.

브랜치 종류

브랜치 플로우

hotfix -> master : 위에서 설명 했듯이 hotfix는 긴급용 브랜치로 master로 바로 병합한다.
bugfix, feature -> dev : 오류수정, 기능개발이 마치면 dev 브랜치로 병합하여 개발서버에서 최종 확인을 거친다.
dev -> master : 최종으로 운영으로 배포되는 병합이며 보통 운영시간 이전이나 이후로 해서 작업을 거친다.
master -> dev : 하향병합이라고 부르며 dev -> master로 병합하기 전 hotfix -> master로 직접 병합된 경우나 불특정 이유로 층돌이 나는 것을 방지하기 위해 하향병합하여 dev 브런치를 기준으로 수정하여 리스크를 줄인다.

모든 브랜치들은 생성 시 master를 기준으로 생성한다. 이유는 굳이 설명하지 않아도 되겠지만 최신 환경을 기준으로 브랜치를 생성해야 나중에 master로 병합 시 누군가 변경한 다른 commit과 충돌할 가능성이 적기 때문이다.

브랜치 네이밍

commit 규칙

생계형 개발자 아년규