개인적인 Git Branch 관리 방법 공유 - 2편

우선 기존에 제가 입사해서 처음 맡았던 프로젝트입니다.

기존 프로젝트의 형상관리 형태

 

master가 있고, 하나씩 브랜치를 만들어 기능을 만들고 다시 master에 병합하는 구조입니다.

 

처음엔 저도 간단한 커밋 이외에는 깃을 사용하는 방법도 몰랐고 이렇게 관리하는 것에 큰 문제점을 느끼지 못했기 때문에

이와 같은 형태로 계속 관리를 하고 있었습니다.

 

 

하지만 하나 둘씩 겹치는 일정이 생기고 동시에 처리할 이슈들이 많아지다보니

기존의 방식으로는 도저히 브랜치 관리가 되지 않았습니다.

 

그래서 다음과 같은 브랜치 형태로 관리를 시작했습니다.

현재 사용하고 있는 관리 방법

 

브랜치는 다음과 같은 4가지 형태가 있습니다.

 

feature - 개발이나 수정사항이 들어오면 develop 브랜치에서 생성한다.

develop - 개발이 완료된 기능들 중 배포를 원하는 feature를 develop으로 병합한다.

master - develop에서 배포를 원하는 시점의 커밋을 병합한다. 항상 배포 가능한 버전으로 유지.

hotfix - 급하게 수정사항이 생긴 경우 master에서 분기시킨다. 작업이 완료되면 master와 develop으로 병합.

 

feature 브랜치에서는 기능단위의 개발을 합니다.

회사에서는 하나의 작업마다 일정이 주어지고 다음 배포 시 작업 단위로 포함/비포함 여부가 결정되기 때문에 하나의 작업 단위는 이곳에서 완료합니다.
Git-flow의 경우 로컬에서만 작업 후 remote로는 push하지 않지만 저는 만약을 위해... ㅎㅎ 모두 push합니다.

향후 모든 기능이 배포되고 안정화되어 더 이상의 히스토리가 필요하지 않을 때 해당 브랜치는 일괄적으로 삭제하는 편입니다.

 

develop 에서는 앞선 feature 브랜치들 중에서 다음 배포 시 반영할 기능들을 모아 병합합니다.

예를 들어 다음 배포 시 뱃지를 넣는 기능과 api수정 작업을 배포하고 싶다면 feature_badge, feature_api_v2를 develop으로 merge 합니다. 다만, branch를 따로 생성하기 애매할 정도로 간단한 작업이거나 모든 feature에 반영되어야 하는 수정사항이 생기면 develop에서 바로 작업 후 commit을 하고 있어요.

 

master 는 테스트를 마친 후 최종적으로 스토어에 심사를 올릴 버전들을 커밋합니다.

앞서 develop 브랜치와의 차이는, 내부테스트의 경우 develop에서 버전을 만들어 테스트를 하지만

스토어에 배포되는 공식 버전의 경우 반드시 master에 있는 버전으로 통일합니다.

Git-flow와 비교하여 release 브랜치가 따로 없고 develop에서 테스트 후 확인이 완료되면 바로 master에 붙여지는 차이가 있습니다.

단, 배포나 심사가된 버전들은 반드시 tag를 붙여 표시를 해줍니다.

 

hotfix 는 배포된 버전에서 심각한 수정사항이 발생했을 때 생성합니다.

문제가 발생한 master 버전에서 바로 분기를 생성하여 수정사항을 적용하고 테스트를 거쳐 각각 master, develop에 병합한 후

다시 심사 및 배포에 들어갑니다.

 

2023.2.2 내용 추가

배포 예정 버전에서 추가적으로 수정사항이 생기면 release 에서 feature branch를 추가하여 작업합니다.
이후 배포가 확정되면 master에 merge후 심사에 들어갑니다.이 때 develop 에도 merge하여 변경된 사항을 업데이트 해줍니다.

 

 

처음부터 이처럼 4가지의 브랜치 형태로 사용한 것은 아니지만,

master-feature 형태로도 사용해보고 master-develop-feature 로도 변형해보며 한 단계씩 시행착오를 통해 자리잡은 방법입니다.

 

1편에서 언급했던 것처럼 자연스럽게 Git-flow와 유사한 방법으로 관리되는 것을 보며 신기한 느낌도 들었고,

모든 지식은 직접 경험해보며 필요에 의해 습득하는 게 가장 자연스럽고 이상적이라는 생각이 들게 되었습니다.

 

 

그외 소소한 관리 방법

master의 변경사항은 develop에 병합하고 있고, develop의 변경사항도 각각의 feature에 병합을 해줍니다.

과거 이러한 작업을 까먹고 몇 달치 수정사항을 한 번에 merge하려다 대참사를 겪은 적이 있기 때문에...

이러한 시행착오를 막기 위해 다소 귀찮더라도 자주 동기화를 해주고 있습니다.

 

또한 hotfix나 feature의 경우 로컬에서만 작업하는 것이 아니라 원격 저장소로도 push를 하고 있으며,

나중에 작업이 안정화되면 브랜치를 로컬&원격 양쪽에서 삭제하는 형태로 사용합니다.

 

사실 자세한 협업 관리 형태는 접해본 적이 없기 때문에 지금 제가 쓰는 방법에 잘못된 방법이 있어도 크게 불편한 것을 못느낄 수가 있습니다만, 지금 저에게는 이와 같은 관리 형태가 가장 안정적이고 생산적인 형태이기 때문에 잘 사용하고 있습니다.

 

소규모나 혼자서 작업하시는 분들 중에서 더 효율적인 방법이 있다면 언제든지 피드백 부탁드리겠습니다!