2009-08-06 5 views
6

릴리스 관리를위한 좋은 시스템과 버전 번호 (예 : 1.0)로 태그를 지정하는 방식을 결합하려고합니다. 1.0-1, 1.0-2 등과 같이 해당 태그 이후의 모든 변경 사항이 증가합니다.Git을 사용하여 분기/마스터 태그 개정판 증가

그러나 1.0 용 릴리스에서 새 분기를 만든 다음 해당 분기로 전환하고 1.0 태그를 지정하면, 위에서 언급 한 시스템이 정상적으로 작동합니다. 그 브랜치에 대한 추가 버그 수정은 1.0-1, 1.0-2

입니다. 그러나 1.0 브랜치를 작성한 후 첫 번째 커밋 이후에 마스터에 다시 태그를 지정하지 않으면 마스터에서의 모든 작업에 동일한 증가 : 1.0-1, 1.0-2

허용, sha1 해시가 고유 할 것이지만, 나는 master와 branch 모두에서 동일한 수정/증가를 갖게 될 것입니다.

브랜치에 태그를 지정할 때 master가 태그되지 않도록하는 방법이 있습니까? 이 작업을 수행하는 더 좋은 방법이 있습니까? 현재, 브랜치 1.0을 만든 후에 유일한 옵션은 마스터에서 하나의 마이너 커밋을 만든 다음 1.1-dev 또는 그 태그에 다시 태그를 지정하는 것입니다.

그런 다음 각 릴리스마다 반복하십시오.

그러나 분기가 1.0.1 릴리스에 대해 다시 태그 지정되면 해당 태그가 마스터 태그로 간주되기 때문에 처음 발생했기 때문에 그렇게 생각됩니다.

답변

6

Git에서는 브랜치에 태그를 지정하지 않습니다. 당신은 커밋에 태그를 붙입니다. 이미 가지고있는 가지를 "표시"하고 싶다면 : 가지 이름. :)

예, git describe1.0-2-g1ab3183과 같은 커밋 식별자를 제공하지만 태그는 아닙니다. 태그 추가는 git tag (누가 추측했는지)로 수행되며 git tag을 사용하여 생성 된 태그는 커밋 식별자 git describe의 기본 태그입니다.

+0

태그, 분기 등은 무엇이며 어떻게 사용되는지 완전히 이해합니다. 문제는 기존 분기에 새 태그를 추가 할 때입니다. 1.0에 대한 지원 지사를 만들었다 고 가정 해 봅시다 - 새로운 기능 등으로 계속 마스터가 계속됩니다. 1.0에 대한 버그 수정은 해당 지사에서 발생합니다. 릴리스 1.0.1에서 태그를 다시 지정하거나 태그를 다시 지정하려고한다고 가정 해 봅니다. 만약 내가 어떤 브랜치에서 그 리비전에 태그를 지정하면 커스터마이징이 일어난 지점에만 태그를 붙이려고 할 때, 1.0.1-1, 1.0.1-2를 보여주기 시작합니다. 그런 태그를 공유하는 마스터와 브랜치는 필요 없습니다. – helion3

+0

'git describe'는'1.0.1-1','-2' 등을 의미합니까? 현재 커밋의 조상이 아닌 태그에 의해 영향을 받아서는 안되기 때문에 (다른 브랜치에 있고 두 브랜치에 커밋 한 경우라면 안됩니다.) – Bombe

2

git에서 태그는 분기가 아닌 특정 커밋의 별칭입니다.

태그 및 분기는 독립적입니다.

그래서 당신은 그것에 작은 회전을 할 수있는 특정 버전을 체크 아웃 할 경우, 당신은 할 수 :

git checkout -b new_branch_name commit_id 

또는

git checkout -b new_branch_name tag_name 

모두가 참조 단순히 해당하는 방법입니다 특정 커밋.

변경 한 후 커밋하고 마이너 리브로 커밋을 태그하십시오.

그러면 체크 아웃 한 분기를 삭제할 수도 있습니다.

4

일부 커밋에서 은 어떤 지점에이 속한다고 말할 수 없습니다. 단일 커밋은 둘 이상의 분기에있을 수 있습니다. 커밋 A가 branch tip의 조상 중 하나라면, 주어진 branch에 있다고 말합니다.

마찬가지로 Bombe said에 Git을 사용하면 브랜치에 태그를 지정하지 않습니다. 당신은 커밋에 태그를 붙입니다. Git 태그에서 커밋을 가리키는 (주석이 달린) 포인터입니다.귀하의 경우에는

당신은 태그 'V1.0'에 의해 COMIT 지적의이 'X'를 저지하자, 내 생각, 다음

 
         /-- [v1.0] 
         v 
---.---.---.---X---.---A  <-- master 
         \ 
          \-.---B  <-- maint 

같은 것을 가지고있다. 이 커밋은 'master'브랜치와 'maint'브랜치에 있습니다. 커밋 'A'('master'브랜치 맨 위)에 "git describe"을 실행하면 v1.0-2-g9c116e9과 같은 결과를 얻습니다. 커밋 'A'('maint'브랜치) 위에 "git describe"를 실행하면 v1.0-2-g3f55e41과 같은 것을 얻을 수 있습니다 (적어도 기본 git-describe 구성에서는). 이 결과는 약간 다릅니다. v1.0-2-g9c116e9은 정렬 된 SHA-1 ID가 9c116e9이고 커밋 2가 태그 v1.0 다음에 커밋되었음을 의미합니다. 태그가 없습니다 v1.0-2!

'master'브랜치에만 태그를 표시하려면 'maint'브랜치 지점을 분기 한 후 새로운 커밋 (예 : GIT-VERSION-FILE에서 기본/폴백 버전 정보 만 업데이트)을 생성 할 수 있습니다. 예를 들어 'maint'브랜치에 커밋을 태그하면 'v1.0.3'은 'maint'에서만 볼 수 있습니다.

HTH

+0

나는 충분히 명확하지 않다는 것을 나는 짐작한다. 나는 당신과 다른 사람들이 말한 모든 것을 알고 있지만, 내 문제는 내가 지점에있는 동안 새 태그를 만들면 마스터에 대한 설명에 새 태그가 반영되기 시작한다는 것입니다. 기본적으로 브랜치와 마스터에서 두 개의 1.0-1, 1.0-2, 1.0-3 버전으로 끝날 수 있습니다. 실제로는 1.0-1, 1.1- dev-1 등등. 내 주위에 유일한 방법은 릴리스 지점을 만든 후 커밋 한 후 마스터에 다시 태그를 지정하는 것입니다. – helion3

+0

태그가 지정된 comit가 'master'('master'의 조상 중 하나)에서도 사용할 수있는 경우에만 발생합니다. –

+0

git-description에서 1.0-1을 사용하지 마십시오. 1.0.1의 태그 유지 관리 릴리스 –

관련 문제