3
나는 릴리스, 개발, 기능 및 버그 수정 지점에서 작동하는 자식 워크 플로우 모델에서 다음 우수 블로그 게시물 건너했습니다 http://nvie.com/posts/a-successful-git-branching-model/릴리스는
그것은 훌륭한 워크 플로우 같은데 정말입니다 생산에서 그것을 시험해보고 싶어하지만 1 개의 단락은 나의주의를 끌었고, 나를 궁금하게 생각하게한다.
다음 릴리스에는 버전 번호가 할당됩니다. 이전 버전과 완전히 같지 않습니다. 그 시점까지 개발 브랜치는 "다음 릴리스"에 대한 변경 사항을 반영했지만 릴리스 브랜치가 시작될 때까지 "다음 릴리스"가 결국 0.3 또는 1.0이 될지 여부는 불분명합니다. 이 결정은 릴리스 분기 시작일에 이루어지며 버전 번호 범핑에 대한 프로젝트의 규칙에 따라 수행됩니다.
이 작업 방식은 티켓팅 및 bugtracking 시스템에 어떻게 반영되어 있습니까? JIRA와 BugZilla에서는 티켓이 속할 수있는 "버전"을 만듭니다. 릴리스 분기로 전환하기 전에 개발 분기에 티켓이 속한 버전은 무엇입니까? 모든 지점에 대해 issuetracker에 버전이 있습니까?
그리고 곧 출시 될 것이 아니라 출시 이후에 구현할 예정인 기능 티켓은 무엇입니까? 나는 이런 종류의 티켓에 대해 "다가올"버전과 "미래"버전을 만들어야 하나?
이 분기 작업 흐름이 티켓/문제 관리에 반영되는 방법에 대한 통찰력은 인정됩니다!