자식 태그를 다시 만든 후 "태그가 이미 원격에 존재합니다"오류

자식 태그를 다시 만든 후 "태그가 이미 원격에 존재합니다"오류

---

아래 단계를 실행하면 다음 오류가 발생합니다.

To git@provider.com:username/repo-name.git
 ! [rejected]        dev -> dev (already exists)
error: failed to push some refs to 'git@provider.com:username/repo-name.git'
hint: Updates were rejected because the tag already exists in the remote.

1. 리포지토리 생성
2. 로컬 컴퓨터에서 저장소를 복제했습니다.
3. README 파일을 수정하고 변경 사항을 커밋하고 커밋을 푸시했습니다.
4. 생성 된 태그 dev:git tag dev
5. 푸시 태그 : git push --tags
6. README 파일을 수정하고 변경 사항을 커밋하고 커밋을 푸시했습니다.

7. 태그를 삭제 dev하고 다시 작성하고 태그를 푸시했습니다.

   git tag -d dev
   git tag dev
   git push --tags
   

왜 이런 일이 발생합니까?

저는 Mac에 있습니다. Linux (Ubuntu)를 사용하는 친구에게는이 문제가 없습니다. git push --tags -f태그를 강제로 업데이트 하는 데 사용할 수 는 있지만 위험합니다 (예를 들어, 브랜치가 아닌 태그에서만 실수로 커밋을 다시 작성).

---

편집, 2016 년 11 월 24 일 :이 답변은 분명히 인기가 있으므로 여기에 메모를 추가하고 있습니다. 중앙 서버에서 태그 를 교체 하면 이전 태그 (태그가 이미있는 중앙 서버 저장소의 복제본)를 가진 사람은 기존 태그를 유지할 수 있습니다. 따라서 이것이 수행 방법을 알려주는 동안 실제로 하고 싶습니다 . 이미 "잘못된"태그가있는 모든 사람이 "잘못된 태그" 를 삭제 하고 새 "올바른 태그"로 교체해야합니다.

Git 2.10 / 2.11에서 테스트 한 결과 이전 태그를 유지하는 것이 실행중인 클라이언트의 기본 동작 git fetch이며 업데이트는 실행중인 클라이언트의 기본 동작입니다 git fetch --tags.

(원래 답변은 다음과 같습니다.)

---

태그 푸시를 요청하면 git push --tags(커밋 및 필요한 기타 객체 및 푸시 설정의 다른 참조 업데이트와 함께) 형식의 업데이트 요청을 원격으로 보냅니다 . (그러나 각 태그마다 하나를 많이 보냅니다.)new-sha1 refs/tags/name

업데이트 요청은 리모트에 의해 수정되어 old-sha1(또는 태그마다 하나씩) 수신 된 후 및 / 또는 업데이트 훅 (원격에있는 후크)에 전달됩니다. 이러한 후크는 태그 생성 / 삭제 / 업데이트를 허용할지 거부 할지를 결정할 수 있습니다.

old-sha1값은 모두 제로 "NULL"SHA-1, 태그가 생성되는 경우이다. 는 new-sha1태그가 삭제되는 경우 널 SHA-1입니다. 그렇지 않으면 두 SHA-1 값이 모두 실제 유효 값입니다.

후크가없는 경우에도 일종의 "내장 후크"가 실행됩니다. "force"플래그를 사용하지 않으면 리모콘은 태그 이동을 거부합니다 ( "내장 후크"는 항상 두 가지 모두 OK 임에도 불구하고) "추가"및 "삭제"). 보고있는 거부 메시지는이 내장 후크에서 나옵니다. (실제로이 동일한 내장 후크는 빨리 감기되지 않는 분기 업데이트도 거부합니다.) ¹

그러나 현재 진행중인 작업을 이해하는 데 필요한 열쇠 중 하나 git push는 리모컨에 현재 해당 태그가 있는지 여부와 그에 따른 SHA-1 값이 무엇인지 전혀 알 수 없습니다. "내 SHA-1 값과 함께 전체 태그 목록이 있습니다"라고만 표시됩니다. 리모콘은 값을 비교하고 추가 및 / 또는 변경이있는 경우 해당 값에 대한 후크를 실행합니다. (같은 태그의 경우에는 아무 것도 수행하지 않습니다. 태그가없는 태그의 경우 아무 것도 수행하지 않습니다!)

태그를 로컬에서 삭제하면 push푸시만으로 태그가 전송되지 않습니다. 리모콘은 변경하지 않아야한다고 가정합니다.

로컬에서 태그를 삭제 한 다음 새 위치를 가리키는 태그를 생성하면을 push누르면 푸시가 태그를 전송하고 원격에서이 태그를 태그 변경으로 인식하고 강제 푸시가 아닌 한 변경을 거부합니다.

따라서 두 가지 옵션이 있습니다.

• 강제 푸시를 수행하거나
• 리모컨에서 태그를 삭제하십시오.

후자 는 태그를 로컬로 삭제하고 ing이 효과가 없지만 git push² 를 통해 가능 push합니다. 리모컨의 이름이 origin이고 삭제하려는 태그가 다음과 같다고 가정합니다 dev.

git push origin :refs/tags/dev

이것은 리모콘이 태그를 삭제하도록 요청합니다. dev로컬 저장소에 태그 가 있는지 여부 는 관련이 없습니다. 이런 종류의 push와 함께, refspec로, 순수 삭제 푸시입니다.:remoteref

리모컨은 추가 된 후크에 따라 태그 삭제를 허용하거나 허용하지 않을 수 있습니다. 삭제를 허용하면 태그가 사라지고 두 번째로 커밋 또는 주석이 달린 태그 저장소 객체를 가리키는 git push --tags로컬 dev태그가 있으면 새 dev태그를 보냅니다 . dev이제 원격에서 새로 생성 된 태그가 될 것이므로 원격에서 푸시를 허용 할 것입니다 (이는 추가 된 후크에 따라 다름).

강제 푸시가 더 간단합니다. 당신이 업데이트 아무것도 확실하지 수 있도록하려면 다른 태그보다 단지 이야기 git push만 하나 refspec를 밀어 :

git push --force origin refs/tags/dev:refs/tags/dev

(참고 : --tags하나의 태그 참조 스펙 만 명시 적으로 푸시하는 경우 필요하지 않습니다 ).

---

¹Of course, the reason for this built-in hook is to help enforce the behavior that other users of that same remote-repo expect: that branches are not rewound, and tags do not move. If you force-push, you should let the other users know you are doing this, so that they can correct for it. Note that "tags don't move at all" is newly enforced by Git 1.8.2; previous versions would allow the tag to "move forward" in the commit graph, much like branch names. See the git 1.8.2 release notes.

²It's trivial if you can log in on the remote. Just go to the Git repository there and run git tag -d dev. Note that either way—deleting the tag on the remote, or using git push to delete it—there's a period of time when anyone who accesses the remote will find that the dev tag is missing. (They will continue to have their own old tag, if they already have it, and they might even push their old tag back up before you can push the new one.)

---

In Mac SourceTree only deselect the Push all tags checkbox:

---

It's quite simple if you're using SourceTree.

Basically you just need to remove and re-add the conflicting tag:

1. Go to tab Repository -> Tag -> Remove Tag
2. Select the conflicting tag name
3. Check Remove tag from all remotes
4. Press Remove
5. Create new tag with the same name to the proper commit
6. Make sure to check Push all tags when pushing your changes to remote

---

If you want to UPDATE a tag, let's say it 1.0.0

1. git checkout 1.0.0
2. make your changes
3. git ci -am 'modify some content'
4. git tag -f 1.0.0
5. delete remote tag on github: git push origin --delete 1.0.0
6. git push origin 1.0.0

DONE

---

It seems that I'm late on this issue and/or it has already been answered, but, what could be done is: (in my case, I had only one tag locally so.. I deleted the old tag and retagged it with:

git tag -d v1.0
git tag -a v1.0 -m "My commit message"

Then:

git push --tags -f

That will update all tags on remote.

Could be dangerous! Use at own risk.

---

The reason you are getting rejected is that your tag lost sync with the remote version. This is the same behaviour with branches.

sync with the tag from the remote via git pull --rebase <repo_url> +refs/tags/<TAG> and after you sync, you need to manage conflicts. If you have a diftool installed (ex. meld) git mergetool meld use it to sync remote and keep your changes.

The reason you're pulling with --rebase flag is that you want to put your work on top of the remote one so you could avoid other conflicts.

Also, what I don't understand is why would you delete the dev tag and re-create it??? Tags are used for specifying software versions or milestones. Example of git tags v0.1dev, v0.0.1alpha, v2.3-cr(cr - candidate release) and so on..

---

Another way you can solve this is issue a git reflog and go to the moment you pushed the dev tag on remote. Copy the commit id and git reset --mixed <commmit_id_from_reflog> this way you know your tag was in sync with the remote at the moment you pushed it and no conflicts will arise.

---

In Windows SourceTree, untick Push all tags to remotes.

참고URL : https://stackoverflow.com/questions/19298600/tag-already-exists-in-the-remote-error-after-recreating-the-git-tag