4
지금 나는 그와 함께 문제의 번호를 가지고 :릴리스 가지가 개발 지점에서 만들어집니다. 예를 들어, 1.1.5 버전이 현재 프로덕션 릴리스이고 큰 릴리즈가 출시된다고 가정 해보십시오. 개발 상태는 "다음 릴리스"에 대한 준비가되었으며 버전 1.1 (1.1.6 또는 2.0이 아닌)이 될 것이라고 결정했습니다. 그래서 우리는 오프 분기 및 릴리스 지점을 새 버전 번호를 반영하는 이름을 부여하십시오 :
$ git checkout -b release-1.2 develop Switched to a new branch "release-1.2" $ ./bump-version.sh 1.2 Files modified successfully, version bumped to 1.2. $ git commit -a -m "Bumped version number to 1.2" [release-1.2 74d9424] Bumped version number to 1.2 1 files changed, 1 insertions(+), 1 deletions(-)
- 분기를 개발 1.1에 아직도있다. 5; 언제 업데이트 되나요? 개발중인 지사가 특정 시점의 버전 번호와 관련하여 릴리스 지사의 "배후"에 있다는 것은 의미가 있습니까?
- 그래서 릴리스 브랜치를 만드는 전에 전에 버전 번호를 늘리십시오. 그렇게한다면 다음 버전이 나올 때까지 dev와 release 브랜치에 동일한 버전 번호를 갖게된다. 분기를 만든 후 버전 번호를 부딪히는 이유는 무엇입니까?
은 그렇다하더라도, 실제로 나는 내 개발 지점이 명확이 개발 버전 (을 나타냅니다 버전 번호를 갖고 싶어하기 때문에 고려해야 할 어딘가에 생성 "myproject라는-1.2.jar"파일을 발견 아무도 없다 프로덕션 환경에서이 jar 파일을 실행하려면 두 번째). 그래서 내가 릴리스 브랜치를 만들면서 "버전 1.2.0"과 "1.2 버전을 기반으로 한 개발 버전"을 반영하는 버전 번호를 원합니다.
불행하게도 릴리스 지점을 만들 때 버전 번호를 "1.2"로 지정하고 개발 지점에서 "1.2 + dev"와 같은 내용을 사용하면 릴리스의 변경 사항을 병합하려고 할 때마다 충돌이 발생합니다 다시 개발로 분기. git을 사용하여 이러한 종류의 버전 관리를 얻는 방법에 대한 조언이 있습니까? 그것은 다음과 같은 워크 플로우 것 같다