고민

Develop에서 시작해서 Hotfix를 팠을 때의 Git 전략은?

기존에 우리 프로젝트에서 에러가 발생하면, Develop브랜치에서 hotfix 브랜치를 파서 > Develop브랜치에 머지를 했다. 하지만 Develop브랜치에 반영을 할 경우, Master 브랜치에는 영향을 미치지 못한다. 이 Git전략은 잘못되었다고 생각했다.

우리 프로젝트가 채택한 Git Flow전략에서 빠르게 에러를 수정하는 Hotfix브랜치는 원래 master브랜치에서 생성이 되어야 한다. 현재 무언가 잘못되었다.

❓ Git Flow전략이 뭔데?

2010년 Vincent Driessen이 그의 블로그에 올리며 인기를 끌며 대중적으로 사용하게된 브랜치 전략이다. 그는 2020년, 웹 애플리케이션에서 이 Git Flow전략이 적합하지 않다고 이야기하였다. 그 이유로, 웹 애플리케이션은 일반적으로 롤백되지 않고, 지속적으로 제공되므로 여러 버전의 소프트웨어를 지원할 필요가 없다고 한다. 앱은 여러 버전으로 관리하여 병렬적으로 지원할 필요가 있지만, 웹은 항상 최신의 단일 버전만을 사용하며 하루에 여러 번 릴리즈 될 수 있기 때문이다.

1. Git Flow 전략이 우리 프로젝트에 유용할까?

하나의 버전만을 사용하기 위해서 Git Flow전략이 적합하지 않다고는 하는데, 우리 서비스는 운영 서버(Main 브랜치)와 개발 서버(Develop 브랜치)를 구분하여 운영하고 있다. 운영 서버는 실제로 사용자들이 이용하는 서비스, 개발 서버는 우리 팀원들이 배포 전에 테스트할 수 있는 서비스이다. 이 둘을 구분해야 더 오류 없이 운영이 가능하다. 운영 서버에 배포하기 전에 웹에서 혹은 앱에서 개발 서버로 테스트를 해볼 수 있기 때문이다. 앱 또한 개발 버전과 운영 버전을 구분해두었다.

우리 서비스가 웹뷰 기반 앱이여서 그런가 생각해볼 수 있지만, 웹이여도 상황은 동일했을 것이라 생각한다.

2. Github Flow 전략은 어떨까?

Github Flow 방식은 Main브랜치와 feature브랜치만 두고, 항상 배포되는 Main브랜치를 중심으로 한 브랜칭 전략이다. 이 방식은 장애 상황에 대해 가장 빠른 롤백 시나리오가 필요하지 않은 경우 적합하다고 한다. 배포 서버와 운영 서버를 분리하여 운영하는 우리 서비스에는 적합하지 않다고 판단하였다.

3. Git 전략에 대한 고민

보통 운영은 main, 개발은 develop브랜치에서 이뤄진다. main에서 develop로 판 다음, feature브랜치 단위로 파서 작업을 진행해 해당 작업을 마치면 develop에 머지를 하는 방식이다.

지금 발생한 문제가 있다. develop에서 hotfix를 파서 에러를 수정해서 develop에 머지를 했다. 그런데 이 문제는 실제 앱(운영 서버)에서 발생한 에러였다. 물론 개발 서버에서도 발생했던 에러였다. 해당 에러를 픽스하여 develop를 main에 머지를 하려했는데 develop에서 한 작업(국가 설정 기능)이 백엔드 서버에서는 아직 배포가 이뤄지지 않았다. 백엔드 서버에서는 국가 설정 기능을 개발 서버에만 업데이트를 하고, 운영 서버에 올리지 않고 다음 개발 과업인 커뮤니티를 개발하고 있는 중이다. 이에 대한 해결책은 두 가지가 떠오른다.

1. 프론트단에서 에러를 고친 커밋만 cherry pick하여 develop > main으로 올린다.
2. 백엔드 단에서 국가 설정 기능을 운영 서버에 올리고, 프론트단도 에러 고친 커밋과 지금까지 작업한 것을 develop > main으로 올린다.

전자는 임시로 해결이 가능한 부분이기 때문에 장기적으로 보았을 때 후자가 옳은 방법이라 생각한다.

앞으로는 한 기능을 구현이 끝나면 프론트단에서도, 백엔드 단에서도 동시에 운영 서버에 올리도록 해야겠다. 개발 서버에서 모아두었다가 배포 서버에 올리면 에러가 발생할 수 있을 뿐더러, 계속 의존성이 쌓이게 된다.

그리고, hotfix를 통해 main을 변경했다면, main에서 시작한 develop는 git pull origin main —-rebase을 통해 변경 사항을 가져와야 한다.

결론

Master 브랜치와 Develop 브랜치, 즉 운영 서버와 배포 서버를 구분하여 서비스하는 우리 프로젝트에는 Git 전략이 적합하다. 그리고 Hotfix 브랜치는 Master 브랜치에서 파서 작업을 진행하며, 작업이 끝나면 Master에 머지한 후, Develop브랜치에서는 Master의 최신 변경 사항을 반영해야 한다. (git merge master) 이 때 기존 Develop브랜치에서 작업을 하여 충돌이 일어날 수 있으므로 이 충돌 해결에 주의해야한

그리고, Hotfix를 Develop에서 파서 작업을 진행하여 Develop에 머지를 했다면, 이 작업 내용만 Main에 옮기는 것은 힘들다. 정 올리고 싶으면, 해당 작업에 대한 Commit을 Cherry Pick을 통해 Main에 올릴 수 있다. 하지만 이 방법은 다른 의존성 문제가 생길 수 있고 오류가 발생할 수 있다.

앞으로는 운영서버에 문제가 생겨 Hotfix를 해야 한다면, Main브랜치에서 파도록 하자.