태그를 한 커밋 앞으로 이동

태그를 한 커밋 앞으로 이동

---

분기 ( master) 가 하나만있는 저장소가 있습니다. 내 저장소에 대한 유일한 기여자입니다.

나는 최근에를 tag로컬 에 추가하고 GitHub에 푸시했습니다. 내가 마지막으로 필요한 커밋을 한 후에는 이제 한 번 더 변경 / 커밋해야한다는 것을 깨달았습니다.

그래서 내가 가진 것은 :

commit 124
commit 125
commit 126 <-- tag v1.0
commit 127

v1.0태그를 다음 커밋, 즉 : 127로컬 및 GitHub 모두로 이동하고 싶습니다 .

어떻게 할 수 있습니까?

---

회원 모두가 "금주의 책"의 동일한 판을 사용하지 않는 북 클럽에 가본 적이 있습니까? 악몽이지? 태그를 이동하면 기본적으로 동일한 상황에 처하게됩니다.

리포지토리를 프로젝트의 진행 상황을 기록하는 책으로 생각하면 태그를 장 제목 으로 생각할 수 있습니다 .

태그를 공유 한 후 다른 커밋으로 옮기는 것은 모든 북 클럽 친구들에게 말하는 것과 같습니다.

그거 알아? 지금까지 우리 모두가 사용하고있는 책의 판은 이제 쓸모가 없습니다. 126 페이지가 아니라 128 페이지에서 8 장을 시작할 것이라고 전적으로 결정했기 때문입니다.

안좋다. 태그 이동은 히스토리 다시 쓰기의 한 형태이며 공유 된 히스토리를 다시 쓰면 안됩니다. 공동 작업자를 화나게하는 가장 확실한 방법입니다. 게다가, 당신은

나는 나의 repo에 대한 유일한 공헌자이다 ...]

지금은 사실 일 수 있지만, 다른 사람이 GitHub 저장소에 액세스 할 수있는 경우 (예 : 공개 된 경우), 그들 중 일부는 이미이를 확인하거나 복제했을 수 있습니다 ( 알아낼 방법 이 있음에도 불구 하고). 역사를 다시 쓰면 화를 낼 위험이 있습니다.

---

어쨌든 그 태그를 옮기고 싶다고 100 % 확신한다면, Git에서 할 수 있습니다. 여기에서 사용할 수 있습니다.

git tag --force v1.0 <ID-of-commit-127>

그런 다음 해당 태그를 강제로 푸시해야합니다.

git push --force --tags

하지만 다시 한 번 생각 하기 전에 다시 생각해보십시오 ...

부록 (2018/09/26)

내 대답을 다시 볼 필요가 있다고 느낍니다 ...

수년 동안 일부 사람들은 이미 게시 된 태그를 이동하지 말라는 내 명령에 대해 댓글에 반대했습니다. 물론,이 조언은 보편적이지 않고 상황에 맞는 것입니다. 게시 된 태그를 이동하는 좋은 사례가 있는지 의심하지 않습니다. 그러나 일반적으로 게시 된 태그를 이동하는 결정은 신중하고 세심한주의를 기울여 이루어져야한다고 생각합니다.

최근의 한 가지 예가 떠 오릅니다. Go 1.11 은 버전 관리를 위해 Git 태그에 크게 의존 하는 모듈 시스템에 대한 실험적 지원을 추가했습니다 . 게시 된 Go 모듈 (예 : GitHub)에서 태그를 이동하면 비참한 결과가 발생할 수 있습니다.

이렇게하면 Go의 모듈 시스템이 제공하려는 보장을 무효화 할 수 있기 때문에 귀하 (모듈 작성자)와 사용자 (모듈에 의존하는 사용자)간에 설정된 계약을 깨뜨릴 수 있습니다.

모듈은 정확한 종속성 요구 사항을 기록하고 재현 가능한 빌드를 생성합니다.

그것은 사람들을 화나게하는 확실한 방법입니다.

이 예제는 적어도 어떤 경우에는 게시 된 태그를 무심코 이동해서는 안된다는 확신을주기에 충분할 수 있습니다. 난 내 경우를 휴식.

---

태그 이동은 일반적으로 Git의 고도로 분산 된 특성으로 인해 문제를 일으킬 수 있으므로 권장되지 않습니다. 중히 여기다:

• v1.0커밋시 태그 를 푸시합니다.abcd123
• 너의 친구는 그를 Fred라고 불러
• Fred는 이제 로컬 v1.0태그가 있습니다.abcd123
• v1.0커밋 cccc222하고 푸시 하기 위해 태그 를 이동합니다.
• 다음과 같은 일이 발생할 수 있습니다.
  • Fred가 가져 왔지만 v1.0서버 의 태그가 자신의 로컬 v1.0태그 와 일치하지 않으므로 Fred는 충돌을 유발하기 위해 아무 조치도 취하지 않았더라도이 충돌을 수동으로 수정해야합니다.
  • Fred는 자신이 만든 --tags새 태그를 추가하는 옵션을 푸시합니다 some-tag. 이 푸시는 로컬 v1.0태그와 서버의 v1.0태그가 일치하지 않기 때문에 서버에서 거부됩니다.

개발자가 두 명 이상이면 훨씬 더 복잡해집니다. 한 사람이라도 자신의 로컬 태그를 업데이트하지 않으면 문제가 발생할 수 있습니다 .

여전히 태그를 이동하려는 것이 확실한 경우 (아마도 이것은 하나의 개발자 프로젝트이거나 그렇지 않으면 아무도 태그를 가져 오지 않았는지 확신하거나 다른 모든 개발자와 통신 할 준비가되어 있는지 확인하십시오. 로컬 태그를 업데이트합니다) 다음과 같이 할 수 있습니다.

git tag -a -f v1.0 <new-commit-hash>
git push --tags --force

다른 개발자는 태그의 로컬 사본을 삭제하고 새 태그를 가져 오도록 권장해야합니다.

git tag -d v1.0
git fetch --tags

---

태그를 삭제 한 다음 다시 만들 수도 있습니다.이 경우 기록을 다시 쓸 필요가 없습니다.
(아니요 push --force)

로컬 및 원격 삭제

git tag -d <tag_name>
git push origin :refs/tags/<tag_name>

재생성

git tag <tag_name>
git push --tags

참고 URL : https://stackoverflow.com/questions/25849019/move-tag-one-commit-ahead