[TIL] 2022/08/12 Github Flow Branch 전략

오늘 branch flow 관련하여 CTO님께서 설명 가이드를 해주셨다. 기존의 단순한 main, develop, sub branch 이외에도 상황에 따라 flow 전략이 달라질수있고 어떻게 활용해야 해당 branch 가 꼬이지 않고 유지할 수 있는지 알게 된거 같다.

 

이러한 발단은 다음과 같다.

운영서비스 중인 운영 사이트와 개발 테스트를 위한 개발 dev 사이트 두개가 있는데, 작업 테스트는 develop 브랜지를 통해 CI/CD 배포를 하고 이러한 모든 작업을 마치고 정식 운영 서비스로 main 브랜치를 통해 배포가 되어있는 상태였다. 그러던 중 two issues 가 발생하였다.

 

첫번째는 대표님께서 급하게 다른 관련 업체사람들과 미팅과정에서 사용하고있는 데이터가 잘 활용한것인지 필요했기때문에 개발테스트 dev 사이트에 프로토타입으로 올려달라고 하셨다.

 

두번째는 이러던 와중에 기존 운영 사이트에서 발견된 버그로 인해 급하게 수정해야하는 상황이 왔다(hotfix).

 

이렇게 될시 develop 브랜치에 대표님께서 요청하신 프로토타입을 적용도 하고 운영사이트에서 발견된 버그를 수정 배포 업데이트 하기위해선  develop branch를 거쳐서 push, merge 되어야 하는데 이렇게 되면 대표님이 요청한 프로토타입까지 운영사이트로 넘어가서 업데이트되는 꼴이니 운영사이트가 hotfix 하나 고치자고 프로토타입까지 안고 가는 말도 안되는 상황이 되는 거였다.

 

이렇다보니 브랜치가 꼬이게 될게 눈에 보이고, 앞으로 업무를 이어감에 있어서 conflict 발생 확률도 매우높고 다시 세팅하는데 많은 에너지와 정신적 스트레스가 예상되는 일이다. 이에 따라 이러한 상황에 맞는 전략이 필요하고 현재 우리회사의 구도, 상황에 맞는 flow branch 전략을 설명해게 된것이다.

 

다음과 같이 브랜치 전략 구도를 짜게 되었는데, 서론에서 설명한 브랜치 부분 설명은 그림을 보며 이해해보자.

feature-something 이라는 브랜치에서 현재 대표님이 요구한 기능 프로토타입을 구현하였고 이를 develop 브랜치에 merge 함으로서 github actions의 자동배포로 개발 사이트에 배포 업데이트가 이루워지는 flow를 볼 수 있고 급하게 운영사이트 수정해야하는 부분을 hotfix 라는 브랜치를 따서 push 하여 수정 배포 하는 과정이 있었다. 

 

이렇게 되면 main 브랜치 상태와 develop 상태가 매우 다른코드를 가지고, 그 하위 브랜치들도 섞여있기 때문에 작업하기위해선 waterfall 방식으로 pull 하여 업데이트해야 가능하다 하지만 이러한 과정은 브랜치가 많고 필요없는 부분까지 업데이트해야하기때문에 비효율적이다.

 

따라서 이를 해결하기위해서 github actions에서 workflow를 세팅해주게 되면 기능단위 브랜치에서 develop 브랜치로 merge 하지않아도 개발사이트로 자동배포를 구축하게 할수있다는 것이다. 따라서 프로토타입에 맞게 개발사이트에 배포도 하면서 기존의 develop, main을 건들필요가 없게 되는 것이다.

 

오늘하루 정말 뜻깊은 공부와 경험을 하게 된거 같다!! 오우!