깃 기반에서 팀 프로젝트 운용이나 방법론을 개인적으로 정리하는 글입니다. #오해금지 #딴지금지 #지적환영 자동화된 테스트가 부족하고 우리 회사같이 금요일에는 배포가 없다든지 그리고 코드리뷰가 끝나길 기다려야 하는 등등 기다림이 있는 상황에는 Ticket 별로 Feature 브랜치를 생성해서 개발하는 GitFlow 브랜치 모델이 적합하다. 프로젝트 시작은 develop 브랜치에서 하고 Feature가 추가 될 때 Ticket (이슈) 별로 Feature 브랜치를 생성하고 Integration 브랜치를 두어 Feature를 머지하는 방식은 다른 브랜치 모델과 유사하다. 물론 Feature 브랜치가 시작되는 브랜치가 develop 인 것도 같다. 버그를 수정할 때, Waterfall 방식으로 개발하는 팀에서는 기간을 정해 QA 주관하에 진행 버그를 수정하게 되고, 애자일 방식을 가진 팀은 개발자가 Ticket 별로 여러 브랜치를 생성/개발을 하고 테스트는 다른 사람들이 진행한다. 그리고 두 가지 개발방식 모두 release-1.0과 같은 Integration 브랜치를 생성하고 QA를 한다. 어떻게 보면 당연하지만, Release 브랜치에는 Feature Freeze - https://en.wikipedia.org/wiki/Freeze_(software_engineering) 라는 개념이 필요하다. 즉 Release 브랜치에는 버그 수정은 하되 더는 기능추가를 하지는 않는다. 그리고 Feature Freezing 중 버그는 Release 브랜치에 적용되고 다시 develop에도 머지된다. 이렇게 Release 브랜치에서 QA를 계속 진행하며 모든 버그가 수정되면 배포준비 생태의 Release 브랜치가 하나 완성된다. 일반적으로 QA가 끝나고 Sign Off가 된 상태를 말한다. 그러면 master에 v1.0과 같은 버전을 하나 Tagging 하고 배포를 한다. 이렇게 끝나면 좋은데 보통 리얼에 배포되면 HotFix가 생기게 마련이다. 버전이