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