2

我正准备发布我的存储库的下一个版本,并且正在经历更新版本的常规发布过程,使用新版本号标记存储库,并将提交连同新标签一起推送到 github。我在发布过程中遇到了一些问题,因此我不得不撤消几次顶部提交并重做标记。

最后,我无法再将标签推送到远程,并显示以下消息:

.masterenv)Cardassia:ASynK sriramkarra$ git push --tags
To git@github.com:skarra/ASynK.git
 ! [rejected]        v0.1.0 -> v0.1.0 (non-fast-forward)
 ! [rejected]        v0.2.0 -> v0.2.0 (non-fast-forward)
 ! [rejected]        v0.2.1 -> v0.2.1 (non-fast-forward)
 ! [rejected]        v0.2.2 -> v0.2.2 (non-fast-forward)
 ! [rejected]        v0.3.0 -> v0.3.0 (non-fast-forward)
 ! [rejected]        v0.4.0 -> v0.4.0 (non-fast-forward)
 ! [rejected]        v0.4.1 -> v0.4.1 (non-fast-forward)
 ! [rejected]        v1.0.0-rc1 -> v1.0.0-rc1 (non-fast-forward)
 ! [rejected]        v1.0.0-rc2 -> v1.0.0-rc2 (non-fast-forward)
 ! [rejected]        v1.0.0-rc3 -> v1.0.0-rc3 (non-fast-forward)
error: failed to push some refs to 'git@github.com:skarra/ASynK.git'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again.  See the
'Note about fast-forwards' section of 'git push --help' for details.

深入研究,我发现这些标签指的是本地和远程的不同 sha1。

这是造成原始损坏的仓库:

.masterenv)Cardassia:ASynK sriramkarra$ git show-ref --tags
984cb8e494f6012f7633f4254bfd710f62f719b9 refs/tags/v0.1.0
1e687ad060bc6498b751d37adcf3d271a326666f refs/tags/v0.2.0
d1ada5d67f61c42fc9ec00215ae974908ae79fa0 refs/tags/v0.2.1
8074c5cf392364bd8a2b19bba83cf6f7ad7ed015 refs/tags/v0.2.2
c63729b79fce4324e4f274eef7f07da60ddc7a8b refs/tags/v0.3.0
142c73d3079d8e498b91686bd9270d8a0e03799b refs/tags/v0.4.0
2d060dbfcba8ab4d144dd9419699dd107e2edfef refs/tags/v0.4.1
d551c33b26476c6d7ff5bf856c1badafe399e1ed refs/tags/v1.0.0
862f048d5ff7670f22b9ba52e1bdfada13e9443f refs/tags/v1.0.0-rc1
5502d5bbefd1e3954db0bf253de70c4fa523c358 refs/tags/v1.0.0-rc2
8bd4e5b349c978693012e9a89511da9c0315b7ca refs/tags/v1.0.0-rc3

这是来自新克隆的副本:

Cardassia:asynk.co sriramkarra$ git show-ref --tags
b149f420d306ea34257a447040af84d1984990d3 refs/tags/v0.1.0
1403ae014708dfed0443c1220170503af82eaf0c refs/tags/v0.2.0
5a643698f1dbed49e5e893db458460e742da2447 refs/tags/v0.2.1
d7be9fd3fa01bbc295dab5075a37a76fdbdb6935 refs/tags/v0.2.2
1703183c5fa2ade578fc7f11cba3a3a6ee8e9dba refs/tags/v0.3.0
94c764fa3f711b43a208f946b6031f3e742e4f07 refs/tags/v0.4.0
9d2eadd4cf34c257ea4165c43a1313f34ba8e867 refs/tags/v0.4.1
d551c33b26476c6d7ff5bf856c1badafe399e1ed refs/tags/v1.0.0
181cdfe665bcdc49f9e70c4ff1f403a79c02180f refs/tags/v1.0.0-rc1
12ef50042d6d632116de68d064e572a1c9031507 refs/tags/v1.0.0-rc2
66c899dca7b14ae93899b32bace77dc3d3872d5b refs/tags/v1.0.0-rc3

怎么会乱成这样?奇怪的是提交历史(git log --pretty=one)在两个分支中显示了相同的提交集。有人可以阐明可能出了什么问题吗?

4

1 回答 1

0

看起来整个历史都被改写了,就像一个大的rebase -i.
这意味着标签不再引用正确的提交。

最好是:

  • 从一个稳定的克隆仓库开始,
  • 将您的本地存储库作为远程添加到该新的本地克隆
  • 挑选你想要添加的提交
  • 从新克隆的 repo 推送回 GitHub上游 repo
于 2013-09-08T10:45:05.610 回答