Git을 한창 배울 때 Git Flow를 보고 꽤 큰 인상을 받았던게 생각납니다. Subversion에서는 브랜치 전환이 꽤 오래 걸렸기 때문에 브랜치를 많이 쓰지 않았지만 Git에서는 브랜치 전환이 너무 쉽기 때문에 브랜치를 잘 쓰는게 좋다는건 이해했지만 여전히 어떻게 쓰는게 좋을지 잘 모르다가 Git Flow에 꽤 잘 정리된걸 봤기 때문입니다. 그래서 이후 Git Flow를 꽤 사용하긴 했지만 Git에 대한 지식도 늘어나고 경험도 많아지면서 웹 개발 등 잦은 배포를 하는 개발에는 어울리지 않다고 느껴졌습니다. 실제 필요한 것에 비해서 절차가 너무 많고 불편해서 비효율적으로 느껴져서 Trunk 기반 브랜치 전략을 주로 쓰게 되었습니다. Git Flow는 굳이 쓴다면 배포 텀이 좀 긴 패키지형 애플리케이션으로 고객에게 납품한 여러 버전을 관리한다면 어울릴 수도 있겠다 생각하긴 합니다. 물론 그래도 여전히 Git Flow가 잘 쓰기도 어렵고 사람이 챙겨야할 불편함을 많이 준다고 생각하고 있습니다. 이 글에서는 GitHub 플로우랑 Trunk-based 브랜치 전략을 구분해서 얘기하고 있긴 한데 저는 크게 구분하지 않고 있기도 하고 큰 차이 없다고 생각하긴 합니다. 사설이 길었는데 Git Flow를 안쓴지가 오래되어서 여전히 많이 쓰는줄 몰랐는데 제 생각보다는 Git Flow를 많이 쓰고 있었습니다. 이 글에선 Git Flow로 소스 코드를 관리하면서 정기 배포를 하다가 잦은 배포를 하기 위해 공부하면서 공부하다보니 Git Flow의 단점을 느끼게 되고 다른 브랜치 전략으로 바꾸고 개선된 배포 프로세스를 설명하고 있습니다. 앞에 길게 쓴대로 Git Flow는 문제가 꽤 있다고 생각하기 때문에 Git Flow를 쓰고 있거나 브랜치 전략에 고민이 있다면 한번 읽어보면 좋을 글입니다.