형상관리 규칙

마이클의 AI 연구소·2022년 10월 25일

본 문서는 Git 형상관리 운영 규칙을 설명합니다.

개요

형상관리란 소스코드 변경에 대한 모든 관리를 말한다. 형상관리 전략이란 그 변경을 추적하고 처리하는 메커니즘을 체계적으로 관리하기 위한 전략을 의미한다. 여러가지 방식들 중 현실적으로 적용하기 어렵지 않으면서도 효과적인 방법론을 정의해본다.

브랜치 운영 규칙

브랜치 전략이란 여러 개발자가 하나의 저장소를 사용하는 환경에서 저장소를 효과적으로 활용하기 위한 work-flow다. 브랜치의 생성, 삭제, 병합 등 git의 유연한 구조를 활용해서, 각 개발자들의 혼란을 최대한 줄이며 다양한 방식으로 소스를 관리하는 역할을 한다. 즉, 브랜치 생성에 규칙을 만들어서 협업을 유연하게 하는 방법론을 말한다.

브랜치 전략이 없으면 발생하는 질문들

최신 브랜치는 뭐야?
개발 시에 어떤 브랜치를 받아야 하나?
배포는 어떤 브랜치로 하면 돼?
핫픽스를 어떤 브랜치를 기준으로 하는거야?

GIT-FLOW

여러 브랜치 전략 중 Git-Flow 전략을 도입하도록 한다. 아래 사진은 Git-Flow 전략을 가장 잘 나타내주는 그림이다.

Git-Flow 전략을 조금 변형하여 Release Branch는 제외하고 master 브랜치를 곧 Release (Production) 브랜치로 규정한다. 각 브랜치에 대해 알아보자.

feature/fix branch

기능 구현을 담당
브랜치명은 팀마다 컨벤션을 가지고 작성
우리는 Jira 이슈번호를 기반한 브랜치명을 사용하여 해당 branch가 어떤 이슈로 인해 수정되었는지 매칭할 수 있게 함
develop 브랜치에서 생성되고 develop 브랜치로 merge 됨
브랜치명 컨벤션
- {수정유형}/{이슈번호}-{수정내용간단요약}
- (예) 수정유형은 fix, 이슈번호은 AINS-17, 수정내용은 메모리릭 버그인 경우
  - bugfix/AINS-17--memory-leak

수정유형	의미	비고
bugfix	버그수정	기존 기능의 버그를 수정
feature	기능추가	새로운 기능이나 동작을 추가
hotfix	핫픽스	긴급수정으로 바로 배포 브랜치로 병합

develop branch

말 그대로 개발을 지행하는 브랜치로 중심적인 브랜치임
하나의 Feature 브랜치가 머지될 때마다 develop 브랜치에 해당 기능이 더해지며 살을 붙여감
develop 브랜치는 배포할 기능이 모두 갖추어지면 master 브랜치로 merge함 (그림 상에는 Release가 별도로 존재하지만 생략하고 바로 master로 merge)

hotfix branch

배포된 소스에서 버그가 발생하여 긴급 수정되어야 하는 경우 생성
브랜치명은 hotfix-1 형태로 지정
수정이 완료되면 master, develop 브랜치에 모두 반영해야 함

main (master) branch

최종적으로 배포되는 브랜치

커밋 작성 규칙

커밋은 staged 상태에 있는 변경 내용들을 repository에 저장하는 행위이며, 이보다 더 중요한 의미는 프로젝트의 히스토리의 기록이다. 너무 세밀한 내용 단위로 커밋을 하면 커밋정보가 불필요하게 많아지고, 너무 큰 단위로 커밋을 하면 특정한 부분의 기록을 추적하는 것이 어렵다. 따라서 적절한 커밋 전략이 필요하다.