지금껏 작업해온 브랜치관리 전략은 gitFlow라고 생각해왔는데
조금 차이가 있었다. 우선은 기본적인 gitFlow에서 release와 Hotfix개념이 생소했으며, 굳이 정확히 따지자면 gitHub을 통해 PR을 날리고, 코드리뷰를 한 후에 merging을 하는 작업을 gitHub-Flow라고 칭하고 있었다.
무튼 Gitflow에서 내가 잘 알지 못했던 것을 정리하고 넘어가려고 한다.
release
지금까지는 release할 내용을 주로 master브랜치에 직접 merge해 왔었다. 예전 jaranda 프로젝트할 때 한번 release 브랜치를 사용했었는데, 개발주기가 1회성에 짧다보니 따로두는게 더 불편하다고 느꼈던 것 같다.
무튼 바로바로 배포할 것이 아닌, 앞으로 배포할 내용에 대해서 release branch를 두어 작업하게 된다.
- 실제 기능개발은
develop/feature/기능명에서 진행하고 - 출시 준비는
release/버젼에서 develop의 내용을 머지하며 업그레이드 시킨다.master는 언제든 실행가능한 상태를 유지해야하기 때문에 앞으로의 배포상태를 위한 파일은 release에 두는 것이다.
release에서 간단한 에러가 발생했다면 해당 브랜치에서 간단하게 수정해도 되고 대신 수정사항을 다시 develop에 merge해주어야 한다. 그리고 수정된 내용이 배포할 상태라면 master에도 merge시킨다.
이 때 merge 시에 --no-ff를 진행하는 게 추천된다.
이는 병합을 위한 커밋 기록을 의도적으로 남기는 방법이다.
(Merge branch 'release')
hotfix
hotFix 브랜치를 만드는 경우는 배포대상인 master브랜치 작업물에 긴급하게 수정해야하는 내용이 있을 때, master브랜치에서 바로 브랜치를 열어 수정사항을 반영하는 것이다. 반영한 내용을 다시 master로 직접 병합하여 배포시키며, 변경한 내용 역시 develop 브랜치에도 다시 merge하는 방식이다. 완료된 hotfix 브랜치는 삭제하면 완료된다.
마지막으로 가볍게
git-flow를 훑어보면, 항상 유지가 되는 메인 브랜치 (master, develop)
필요할 때 생성되는 보조 브랜치 (feature, release, hotfix)로 나누어 볼 수 있다. 보조브랜치는 사용을 다 하고 필요가 없어지면 삭제해서 브랜치를 정리한다.
- 메인 브랜치
- master: 현재 바로 실행가능한 제품 브랜치
- develop: 다음 출시 버젼을 개발하는 브랜치
- 보조 브랜치
- release: 다음 출시 버젼을 준비하는 브랜치
- feature: 기능 구현 브랜치
- hotfix: master의 내용에서의 버그를 긴급히 수정하는 브랜치
번거로운 일처럼 느껴질 때도 있지만,
협업할 때 일관성있게 브랜치를 운영하고 작업물을 안전하게 관리할 수 있는 좋은 방법이라고 생각한다. 기업마다 브랜치관리 방식으로 다른 방법을 사용하고 있을 수도 있지만 대체적으로 gitFlow를 기반으로 조금씩 달라졌을 것이라는 생각이다.
