hotfix branch 전략으로 빠른 버그수정하기

왜 필요했냐면..

최근 며칠동안 프로덕션 배포 일정을 위해

개발 브랜치에 이미 많은 변경사항들이 반영되어 있는 상태였는데

프로덕션에서 긴급하게 수정해야할 버그가 발생하는 일이 있었습니다.

따라서 핫픽스 브랜치가 필요하다고 판단했지만

실제로 핫픽스 브랜치 전략을 사용해본적은 없어 시행착오를 조금 겪었습니다.

---

hotfix branch는 왜 필요한가?

 

실제로 일을 하다보면 흔히 개발 브랜치와 프로덕션 브랜치가 나뉘어지기 마련입니다.

개발중인 코드가 실제 프로덕션에 올라가게되면 안되는 경우가 빈번합니다.

유저가 없는 서비스라면 마음편하게 개발해도 상관 없지만

만약 유저가 있는 서비스라면 실제 프로덕션에 문제가 생겼을 때 이를 빠르게 조치해주어야합니다.

그렇게하기 위해 hotfix branch를 통하여 해당 문제를 해결할 수 있습니다.

 

발상은 간단합니다.

main

main을 base로 하는 dev 

main을 base로 하는 hotfix

dev를 base로 하는 각 팀원들의 feature branch

 

이런 형태로 브랜치를 나누어 놓았다면

핫픽스 해야하는 경우 핫픽스 브랜치를 수정하고 메인에 머지해주면 될 것입니다.

---

문제가 뭐냐면

메인에 핫픽스 브랜치를 머징시켜둔 다음 메인을 베이스로 하는 데브 브랜치와

그 데브를 베이스로 하는 각 팀원들의 브랜치에도 핫픽스의 변경사항들이 적용되어야 한다는 것입니다.

hotfix 를 main 에 병합한 뒤 dev에서 main을 그냥 pull을 땡기니까 잘 안되는 문제가 있었습니다. 

git merge --no-ff origin/hotfix

--no-ff 옵션은 No Fast-Forward 병합을 수행하도록 지시하는 옵션입니다.

핫픽스 브랜치와 기존 브랜치의 병합이 필요한 상황이기 때문에

새로운 병합 커밋을 만들면서 두 브랜치의 이력을 명시적으로 합치는 것을 통해

병합 작업이 수행된 시점을 추적할 수 있어지는 것은 물론 되돌리기도 가능해집니다.

 

이렇게 명령어를 넣어주고 나면 터미널이 vim editor로 자동 전환되는데

vim editor에서의 저장 종료 명령어는 다음과 같습니다.

shift + ;

-> 선택창

w q ! enter

---

마치며

사실 이 방법이 hot fix branch를 운영하는 best pratice는 아닐 수 있습니다.

하지만 아무튼 저는 이러한 방법을 통해 핫픽스 브랜치를 관리하고 있습니다.

더 좋은 전략이나 방법이 있다면 알려주세용