답변:
태그는 주로 커밋에 태그를 지정하여 프로젝트의 특정 버전에 대한 향후 참조에 사용됩니다. 물론 항상 브랜치를 사용할 수 있지만 버전을 많이 변경하면 사용하지 않거나 거의 사용하지 않는 브랜치가 많이 생깁니다.
실제로 태그는 어쨌든 분기가없는 분기이며 복잡성을 줄이기 위해 프로젝트의 특정 버전을 참조하는 방법을 추가하는 것입니다.
편집 : 다음 은 모든 프로젝트에 사용하는 git을 사용하는 좋은 방법입니다.
저는 태그 와 분기를 모두 통합하는 워크 플로를 사용하는 경향이 있습니다 . 태그는 릴리스 된 코드 또는 주목할만한 개발 빌드를 표시하는 데 유용합니다. 분기는 특정 버전과 관련된 모든 변경 사항을 추적하는 데 유용합니다.
다음은 이러한 유형의 워크 플로에 대한 좋은 글입니다. http://nvie.com/posts/a-successful-git-branching-model/
브랜치와 태그는 동일합니다 (커밋에 대한 포인터, 일명 "ref" ). 단, 브랜치는 자동으로 다음 커밋으로 이동하고 태그는 동일한 커밋에서 영원히 1로 유지됩니다 .
릴리스를 만들 때 일반적으로 해당 릴리스가 빌드 된 코드의 "스냅 샷"을 표시하고 코드를 계속 발전시키는 동안에도 그대로 표시되기를 원하므로 태그를 사용합니다.
이를 위해 브랜치를 사용하려고 시도하면 의도 치 않게 릴리스가 빌드 되지 않은 다른 커밋으로 이동할 수 있습니다.
1 물론 태그를 삭제하지 않는 한.
참고 : 이것이 오래된 질문이라는 것을 알고 있지만 브랜치와 태그 간의 유사성 (및 하나의 중요한 차이점)이 다른 답변에서 가능한 한 명확하게 구체화되지 않았다고 느꼈습니다.
git commit하면 체크 아웃 된 브랜치의 헤드가 새 커밋을 참조하도록 업데이트되지만 다른 브랜치는 "자동으로"다음 커밋으로 이동하지 않습니다. 답변의 첫 번째 단락을 명확히해야합니다.
.git\refs\heads커밋의 해시를 포함 하는 한 줄짜리 파일 입니다. 커밋은 자신을 생성 한 분기를 "기억"하지 않습니다. 예를 들어 브랜치 정보를 커밋의 메타 데이터에 기록 할 수있는 Mercurial과는 다릅니다.
태그를 사용하여 기록에서 중요한 커밋을 기록합니다. "이것은 빌드 서버가 고장 났을 때 비오는 목요일에이 버전에 사용한 정확한 커밋입니다." 태그 대신 브랜치를 사용하면 정확히 어떤 커밋을 사용했는지 알 수 없습니다. 해당 커밋에 대한 정확한 해시를 수동으로 기록하지 않는 한 "우리는이 브랜치 어딘가에 버전 1.1.0을 출시했습니다."라는 것만 알고 있습니다. 이것이 태그를 처음에 사용하는 이유입니다. :)
다른 답변 외에도 여기에 2 센트가 있습니다.
짧은 답변 : 릴리스 버전에 태그 사용
긴 답변 : 특히 릴리스 버전 관리에 태그를 사용하는 것이 분기를 사용하는 것보다 낫다고 생각합니다. 릴리스를 업데이트해야하는 경우 태그가 지정된 커밋에서 분기하고 해당 분기 (대부분 핫픽스 분기)에서 작업을 마친 후 새 버전으로 새 분기의 헤드에 새 태그를 만듭니다. 그런 다음 소스 코드에 다시 병합해야하는 핫픽스가 아닌 이상 릴리스 버전을 변경해서는 안되므로 해당 분기를 마스터 / 개발로 다시 병합합니다. 그런 다음 더 이상 필요하지 않으므로 해당 분기를 삭제하십시오. 새 버전에 다른 핫픽스를 적용해야하는 경우 동일한 단계를 반복하십시오.
핫픽스를 작성자의 Git 워크 플로와 병합하는 방법을 보여주는 다음 문서의 섹션 ( https://hackernoon.com/a-branching-and-releasing-strategy-that-fits-github-flow-be1b6c48eca2)을 참조하세요.