* Git-flow?
Git을 사용한 개발 작업 절차이다. 완벽한 하나의 방법이 있는 것이 아닌, 각자 팀에 맞는 개발 환경에 따라 변형해서 사용하는 것이 좋다.
- Git-flow의 브랜치
- master: 제품으로 출시(배포)할 수 있는 브랜치
- develop: 다음 버전을 개발하는 브랜치
- feature: 단위별로 기능을 개발하는 브랜치 (완료되면 develop 브런치와 병합)
- release: 배포 전 (master와 병합 전) QA를 통해 버그를 찾아내기 위한 브랜치
- hotfixes: master브랜치에서 발생한 버그를 긴급하게 수정하는 브랜치
master와 develop은 항상 유지되는 메인 브랜치들이며 그 외에 feature, release, hotfixes는 필요한 기간에만 유지되는 보조 브랜치들이다.
- 예시
타임라인을 보면 알겠지만 처음에는 master로 시작해 develop브랜치만 존재한다. 아직 소프트웨어를 배포하지 않았기 때문에 develop브랜치에서 개발을 시작한다. 개발을 진행하다가 추가로 필요한 기능이 생기면 feature브랜치를 생성해 작업을 한다. feature브랜치는 언제나 develop브랜치로부터 시작된다. 기능을 다 개발했다면 작업한 feature브랜치를 검토한 후 develop브랜치에 병합한다. 이제 이번 버전에서 필요한 기능이 모두 개발되었다면 QA를 위해 release브랜치를 생성한다. QA를 진행하며 발견하는 버그들은 모두 이 release브랜치를 통해 fix된다. 이제 QA과정이 모두 끝났다면 release브랜치를 master와 develop브랜치로 병합한다. 그리고 master브랜치에 버전명시를 위한 태그를 생성 후 배포한다. 여기까지가 기본적인 개발 단계에서의 Git-flow이다.
하지만 배포 후에도 버그가 발생하는 경우가 있다. 그렇다면 긴급하게 수정을 해야하는데 그럴 경우 hofixes브랜치를 생성해 발생한 버그를 수정한다. 버그 수정이 완료되었다면 release브랜치가 완료됬을 때와 같이 master와 develop브랜치로 병합 후 버그 수정을 완료했다는 태그를 추가한다.
어디까지나 정답은 없고 팀마다의 방식을 적용하여 활용하여야 한다. 나는 브랜치를 나눈 협업을 처음 해보았을 때 브랜치에 익숙하지 않아서 main, develop, hotfix 이렇게 3가지로만 나누어서 개발하였다. 이처럼 본인의 상황과 팀의 상황에 맞추어 적절히 수정, 활용한다면 성공적인 git flow 관리가 될 것이다.