1. 글을 작성하게 된 계기
회사에서 새로운 Git 브랜치 전략을 배웠는데, 이를 기록하기 위해 글을 작성하게 되었습니다.
꽤 편하긴 했는데, 솔직히 정석인지, 좋은지는 잘 모르겠습니다.
2. 기존에 사용하던 Git 관리 방식과 문제점
기존에는 아래와 같이 Git을 관리했습니다. 새로운 기능을 개발할 땐 dev->feature 브랜치를 생성한 후, 작업이 완료되면 dev로 merge 합니다. 배포할 때는, dev 브랜치로 부터 release 브랜치를 생성 후, master로 merge 했고요.
하지만 이번 프로젝트에서는 버전 두 개를 관리해야 했습니다. 즉, release1.0(v1.0)과 release1.1(v1.1)이 있으며, 둘은 코드가 많이 달랐습니다. v1.0은 배포된 서버로, 운영되고 있으며 발생하는 hotfix를 처리해야 했고, v1.1은 새로운 기능이 개발되고 있으며, 많은 코드 리팩토링이 있었습니다. 이러다 보니 기존에 배포한 프로그램을 dev 서버에서 실행하기 힘든 이슈가 발생했습니다. 코드가 다르니까요.
기존 Git Flow로도 해당 포스팅에 나오는 이슈를 모두 해결할 수 있습니다. 방법의 차이일 뿐, 정답은 존재하지 않습니다.
3. 새로 배운 브랜치 전략
이 과정에서 새로 배운 브랜치 전략은 master를 기준으로 다른 브랜치를 관리하는 전략입니다. dev뿐 아니라 release도 master로부터 생성하며, feature는 release로부터 생성하고요.
3-1. 장점
이 전략을 사용하면 hotfix를 반영한 코드, 즉 master의 최신 코드를 v1.0과 v1.1에 모두 반영할 수 있습니다. 또한 dev 브랜치로 코드가 합쳐지기에, v1.0을 또한 개발 서버에서 테스트해 볼 수도 있습니다. dev, v1, v2 모두 master로 부터 파생되었기 때문이죠.
3-2. 단점
rebase를 자주 사용해야 합니다. 이번 프로젝트에서는 Hotfix가 생각보다 많았는데, 그때마다 rebase를 주기적으로 해줘야 해서 항상 master의 최신 상태를 확인해야 했습니다. 그 과정에서 실수도 많이 발생했고요. 정리하면 master의 최신 상태를 항상 확인해야 한다.는게 단점입니다.
이건 비단 해당 전략만 그런건 아니지만요. 👀
4. 정리
회사에서 사용했던 Git 전략을 정리해 보았습니다. 중간에 실수를 좀 했지만 재미있었는데요, 다만, 이게 정석인지, 다른 곳에서도 자주 사용하고 있는지는 잘 모르겠습니다. 이런 전략이 있다는 것을 알고, 자신의 상황에 맞게 적용할 수 있으면 좋을 것 같습니다.