태그는 Git의 브랜치와 어떻게 다릅니 까?

태그는 Git의 브랜치와 어떻게 다릅니 까? 여기에서 어느 것을 사용해야합니까?

---

git 에서 태그 대 분기 를 사용하는 방법을 이해하는 데 약간의 어려움이 있습니다 .

방금 코드의 현재 버전을 cvs 에서 git 로 옮겼 으며 이제 특정 기능에 대한 해당 코드의 하위 집합을 작업 할 것입니다. 몇몇 다른 개발자들도이 작업을 수행 할 것이지만 우리 그룹의 모든 개발자가이 기능에 관심을 갖는 것은 아닙니다. 브랜치 또는 태그를 생성해야합니까? 어떤 상황에서 하나를 사용해야합니까?

---

태그는 한 순간 특정 지점의 버전을 나타냅니다. 분기 와 동일한 코드베이스에 다른 개발 노력과 동시에 실행할 수 있습니다 개발의 별도의 스레드를 나타냅니다. 분기에 대한 변경 사항은 결국 다른 분기로 다시 병합되어 통합 될 수 있습니다.

일반적으로 특정 버전에 태그를 지정 하여 다시 만들 수 있습니다 (예 : XYZ Corp에 배송 한 버전) . 지점특정 버전의 코드에 대한 지속적인 업데이트를 제공하는 동시에 개발을 계속하는 전략입니다. 제공된 버전의 브랜치를 만들고 메인 라인에서 계속 개발하지만 제공된 버전을 나타내는 브랜치에 버그를 수정합니다. 결국 이러한 버그 수정을 다시 메인 라인에 병합 할 것입니다. 종종 분기와 태그를 함께 사용합니다. 배달, 버그 진단 등을 위해 재생성 할 수있는 각 분기를 따라 특정 버전 (예 : 고객에게 제공되는 버전)을 표시하는 메인 라인과 분기 모두에 적용 할 수있는 다양한 태그가 있습니다.

실제로 이보다 더 복잡하거나 원하는만큼 복잡하지만이 예제는 차이점에 대한 아이디어를 제공합니다.

---

로부터 이론적 관점 :

• 태그 는 주어진 개정판의 상징적 인 이름입니다 . 그들은 항상 동일한 객체를 가리 킵니다 (보통 : 동일한 개정판을 가리 킵니다). 그들은 변하지 않습니다.
• 브랜치 는 개발 라인을 상징하는 이름입니다 . 새 커밋이 분기 위에 생성됩니다. 분기 포인터는 자연스럽게 진행되어 더 새로운 커밋을 가리 킵니다.

---

로부터 기술적 관점 :

• 태그 는 refs/tags/네임 스페이스에 있으며 태그 객체 (주석 및 선택적으로 GPG 서명 태그)를 가리 키 거나 객체를 직접 커밋 (로컬 이름에 덜 사용되는 경량 태그)하거나 매우 드물게 트리 객체 또는 blob 객체 (예 : GPG 서명)를 가리킬 수 있습니다. ).
• 분기 는 refs/heads/네임 스페이스에 있으며 커밋 객체 만 가리킬 수 있습니다 . HEAD포인터 분기 (심볼 참조) 또는 직접 커밋 (또는 분리 HEAD 이름 점)을 참조한다.
• 원격 추적 분기 는 refs/remotes/<remote>/네임 스페이스에 있으며 원격 저장소의 일반 분기를 따릅니다 <remote>.

---

gitglossary 맨 페이지 도 참조하십시오 .

분기

"분기"는 활발한 개발 라인입니다. 분기에 대한 가장 최근 커밋을 해당 분기의 팁이라고합니다. 분기의 끝은 분기 헤드에 의해 참조되며 분기에서 추가 개발이 수행됨에 따라 앞으로 나아갑니다. 단일 git 저장소는 임의의 수의 브랜치를 추적 할 수 있지만 작업 트리는 브랜치 중 하나 ( "현재"또는 "체크 아웃"브랜치)에만 연결되고 HEAD는 해당 브랜치를 가리 킵니다.

꼬리표

태그 또는 커밋 객체를 가리키는 참조. 헤드와 달리 태그는 커밋으로 변경되지 않습니다. 태그 (태그 객체가 아님)는 $GIT_DIR/refs/tags/. [...]. 태그는 가장 일반적으로 커밋 상위 체인의 특정 지점을 표시하는 데 사용됩니다.

태그 개체

다른 객체를 가리키는 참조를 포함하는 객체로, 커밋 객체처럼 메시지를 포함 할 수 있습니다. 또한 (PGP) 서명을 포함 할 수 있으며이 경우 "서명 된 태그 개체"라고합니다.

---

리포지토리를 프로젝트의 진행 상황을 기록하는 책으로 생각한다면 ...

지점

브랜치를 고정 북마크 중 하나로 생각할 수 있습니다 .

새로운 저장소에는 (라고하는 master) 그중 하나만 있으며 , 이는 작성한 최신 페이지 ( 커밋을 생각하십시오)로 자동 이동합니다 . 그러나 책에서 다른 관심 지점을 표시하기 위해 더 많은 책갈피를 만들고 사용할 수 있으므로 빠르게 다시 돌아갈 수 있습니다.

또한 언제든지 특정 책갈피를 책의 다른 페이지로 이동할 수 있습니다 ( git-reset예 : 사용 ). 관심 지점은 일반적으로 시간이 지남에 따라 다릅니다.

태그

태그를 장 제목 으로 생각할 수 있습니다 .

제목을 포함 할 수도 있고 ( 주석이있는 태그를 생각해보십시오 ). 태그는 책에서 역사적 관심사를 표시한다는 점에서 브랜치와 비슷하지만 다릅니다 . 역사적 측면을 유지하기 위해 일단 태그를 공유하면 (즉, 공유 리모컨으로 푸시), 책의 다른 위치로 태그 를 이동 해서는 안됩니다 .

---

What you need to realize, coming from CVS, is that you no longer create directories when setting up a branch.
No more "sticky tag" (which can be applied to just one file), or "branch tag".
Branch and tags are two different objects in Git, and they always apply to the all repo.

You would no longer (with SVN this time) have to explicitly structure your repository with:

branches
   myFirstBranch
     myProject
       mySubDirs
   mySecondBranch
     ...
tags
   myFirstTag
     myProject
       mySubDirs
   mySecondTag
   ...

That structure comes from the fact CVS is a revision system and not a version system (see Source control vs. Revision Control?).
That means branches are emulated through tags for CVS, directory copies for SVN.

Your question makes senses if you are used to checkout a tag, and start working in it.
Which you shouldn't ;)
A tag is supposed to represent an immutable content, used only to access it with the guarantee to get the same content every time.

In Git, the history of revisions is a series of commits, forming a graph.
A branch is one path of that graph

x--x--x--x--x # one branch
    \ 
     --y----y # another branch
       1.1
        ^
        |
        # a tag pointing to a commit

• If you checkout a tag, you will need to create a branch to start working from it.
• If you checkout a branch, you will directly see the latest commit it('HEAD') of that branch.

See Jakub Narębski's answer for all the technicalities, but frankly, at this point, you do not need (yet) all the details ;)

The main point is: a tag being a simple pointer to a commit, you will never be able to modify its content. You need a branch.

---

In your case, each developer working on a specific feature:

• should create their own branch in their respective repository
• track branches from their colleague's repositories (the one working on the same feature)
• pulling/pushing in order to share your work with your peers.

Instead of tracking directly the branches of your colleagues, you could track only the branch of one "official" central repository to which everyone pushes his/her work in order to integrate and share everyone's work for this particular feature.

---

Branches are made of wood and grow from the trunk of the tree. Tags are made of paper (derivative of wood) and hang like Christmas Ornaments from various places in the tree.

Your project is the tree, and your feature that will be added to the project will grow on a branch. The answer is branch.

---

It looks like the best way to explain is that tags act as read only branches. You can use a branch as a tag, but you may inadvertently update it with new commits. Tags are guaranteed to point to the same commit as long as they exist.

---

Tags can be either signed or unsigned; branches are never signed.

Signed tags can never move because they are cryptographically bound (with a signature) to a particular commit. Unsigned tags are not bound and it is possible to move them (but moving tags is not a normal use case).

Branches can not only move to a different commit but are expected to do so. You should use a branch for your local development project. It doesn't quite make sense to commit work to a Git repository "on a tag".

---

The Git Parable explains how a typical DVCS gets created and why their creators did what they did. Also, you might want to take a look at Git for Computer Scientist; it explains what each type of object in Git does, including branches and tags.

---

I like to think of branches as where you're going, tags as where you've been.

A tag feels like a bookmark of a particular important point in the past, such as a version release.

Whereas a branch is a particular path the project is going down, and thus the branch marker advances with you. When you're done you merge/delete the branch (i.e. the marker). Of course, at that point you could choose to tag that commit.

---

A tag is used to mark a version, more specifically it references a point in time on a branch. A branch is typically used to add features to a project.

---

simple:

Tags are expected to always point at the same version of a project, while heads are expected to advance as development progresses.

Git User Manual

---

the simple answer is:

branch: the current branch pointer moves with every commit to the repository

but

tag: the commit that a tag points doesn't change, in fact the tag is a snapshot of that commit.

참고 URL : https://stackoverflow.com/questions/1457103/how-is-a-tag-different-from-a-branch-in-git-which-should-i-use-here