gitflow를 사용할 때 릴리스 분기 또는 마스터 분기에 태그를 지정해야합니까?

이 문제 는 다음을 나타냅니다.

병합하기 전에 릴리스 브랜치 (마스터 브랜치가 아닌)에 태그를 배치하는 것은 실제로 올바른 일이므로 git describe --develops 브랜치에서도 태그를 찾을 수 있습니다. # 374 참조

반면 또 다른 포스트 :

오늘 실수로 homebrew를 통해 0.4.2 프리 버전을 설치했으며 해당 버전에서 태그가 작동하는 방식에 혼란을 겪었습니다. 이전 (버전 0.4.1) 릴리스 분기가 병합 된 후 마스터 분기에서 태그가 작성되었습니다. 이제 태그가 릴리스 브랜치의 마지막 커밋에서 생성 된 것으로 보이지만 나에게는 좋은 생각이 아닙니다. 특히 git 태그를 사용하는 빌드 시스템이 있고 HEAD가 태그가 지정된 커밋 인 경우 릴리스 버전을 만들고 다음 버전 중 하나가 커밋되는 경우 개발 버전을 만드는 경우. 누군가이 변화의 배후에있는 논리를 설명해 주시겠습니까? 그리고 시맨틱 버전 관리와 관련하여 나는 이것을 패치 레벨에서 버전 범프라고 생각하지 않습니다!

우리 팀에서는 이에 대해 여러 차례 토론했습니다. 일부는 마스터 브랜치에서 태그를 작성해야하는 반면 다른 릴리스는 릴리스 브랜치를 선호합니다. gitflow 그림에 따르면 :

태그가 마스터에 배치 된 것 같습니다.

첫째, 분기에 태그를 지정할 수 없으며 커밋에만 태그를 지정할 수 있습니다.

실제로 해제 한 커밋에 태그를 지정해야합니다. 이것이 버전 태깅 커밋의 요점입니다. 일부 환경 (프로덕션 또는 기타)에서 소프트웨어에 문제가있는 경우 해당 릴리스에서 파생 된 커밋에 의해 문제가 발생했다고 확신 할 수 있습니다.

(이것은 사람들이 '재생 가능한 빌드'에 대해 이야기하는 이유입니다. 따라서 릴리스 프로세스가 미리보기 / 스테이징 환경에없는 새로운 버그를 도입하지 않으며 프로덕션에 버그가있는 경우 바이너리가 디버그하려고 할 때 컴퓨터에서 실행되고 있습니다.)

프로덕션에서 커밋을 해제하지 않았기 때문에 맨 아래에서 두 번째 녹색 커밋 ( '버그 수정 만!'으로 표시된 커밋의 녹색 자식)을 'v1.0'으로 태그 지정하는 것은 없습니다. 마스터 커밋을 해제했습니다. git flow가 'Tag 1.0'으로 표시되어 있음을 알 수 있습니다.

태그에는 커밋을 쉽게 찾을 수있는 목적이 있습니다. 커밋을 'v1.0'으로 태그 지정하여 버전 1.0으로 릴리스 한 것을 쉽게 찾을 수 있습니다. 커밋 트리 어딘가에 실제로 해제 한 커밋 근처에 'v1.0'태그를 사용하기 위해 태그를 지정하지 않습니다.

개발 지점에서 태그를 찾는 데 문제가있는 경우 이는 완전히 별개의 문제입니다. 태그를 찾는 데 사용하는 도구를 수정하십시오. 또는 더 나은 방법 : git-flow를 사용하지 마십시오. 그것은 사랑스러운 색깔의 점들과 멋지게 꾸며진 선으로 인해 다이어그램에서 멋지게 보이지만 실제로는 색깔이있는 선과 점의 미친 지저분한 웹처럼 보입니다.