Branch Per Feature

깃 기반에서 팀 프로젝트 운용이나 방법론을 개인적으로 정리하는 글입니다. #오해금지 #딴지금지 #지적환영

Branch Per Feature는 브랜치 하나로 쓰는 전략은 아무래도 제약이 많아서 Feature 브랜치와 Integration 브랜치를 활용하는 방법에 대한 내용이다. Feature 브랜치와 Integration 브랜치는 하는 일은 같은데, 단지 어떤 커밋들을 대상으로 하느냐의 차이가 있다.

모든 작업은 Feature 브랜치에서 이루어지고 Integration 브랜치를 통해 다른 개발자 커밋을 반영하는 등 최신상태를 맞춘다. 릴리즈 할 때는 Integration 브랜치를 생성하고 빌드에 포함할 Feature만 골라 머지하고 릴리즈를 한다. 즉 마지막 빌드이후 완료된 모든 작업을 포함할 필요가 없다.

이렇게 Feature 브랜치와 Integration 브랜치를 활용하면 특정 코드가 배포되는 것을 막을 수도 있고 배포가 준비된 상태를 유지 할 수도 있다.

이런 Feature별 브랜치 모델에 대해 좀 더 자세한 내용은 ( http://dymitruk.com/blog/2012/02/05/branch-per-feature ) 링크에 설명되어있고, 조금 더 초기 모델이 GitHub Flow 다. ( http://scottchacon.com/2011/08/31/github-flow.html )

GitHub Flow 브랜치 모델에서 master는 항상 배포가능한 브랜치다. 개발자는 Feature 브랜치를 만들고 개발하고 master 브랜치에서 코드를 가져와 최신상태를 유지한다. 작업이 완료되거나 다른 개발자와 협업 또는 도움이 필요하면 Pull Request를 master 브랜치로 날리고 이슈트래커에서 개발한 기능에 관해 이야기를 나눈다.

이런 GitHub Flow와 Dymitruk 모델과 차이점은 단지 어떻게 배포가 일어나는가의 차이다. 즉 Dymitruk 모델은 어떤 Feature를 선택해서 빌드하느냐이고, GitHub Flow는 Pull Request가 수락되면 Feature 브랜치에 있던 코드가 바로 배포가능한 코드가 되는것이다.

Mainline 모델과 달리 Feature를 선택해 빌드가 가능하다는 장점이있지만, 개발자가 Feature 브랜치들을 최신으로 유지해야 하는 부담이 있다.



참고:

Git for Team
GitHub Essentials
http://scottchacon.com/2011/08/31/github-flow.html
http://dymitruk.com/blog/2012/02/05/branch-per-feature/