質問

リポジトリにブランチが1つしかありません( master ). 私のリポジトリへの貢献者は私一人です。

最近、私は tag を追加しました。最後の必要なコミットだと思ったものを行った後、しかし今になって、もうひとつ変更/コミットを行うべきだったと気づきました。

というわけで、私が持っているのは

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

を移動させたいのですが v1.0 タグを次のコミットに移動させたい、つまり 127 を追加します。

どうすればいいのでしょうか？

どのように解決するのですか？

メンバー全員が同じ版の「今週の本」を使っていないブッククラブに行ったことがありますか？それは悪夢ですよね。タグを移動すると、本質的に同じ状況に陥ります。

リポジトリをプロジェクトの進捗を記録する本と考えるなら、タグを 章の見出し .

タグを共有した後に別のコミットに移動するのは、読書会の仲間に

みんな、知ってるかい？なぜなら、第8章の始まりは、126ページではなく、128ページであると、私が単独で宣言したからです。

よくないことです。タグの移動は歴史の書き換えであり、共有された歴史を書き換えてはいけないのです。協力者を怒らせる一番確実な方法です。それに、あなたは

私のレポの貢献者は私一人です [...］

今はそうかもしれませんが、あなた以外の人があなたの GitHub リポジトリにアクセスできる場合 (公開されている場合など)、そのうちの何人かはすでにフォークやクローンを作成しているかもしれません (ただし、このような場合は 方法 で調べることができます)、歴史を書き換えると彼らを怒らせる危険性があります。

そのタグを移動させたいと100%確信しているのであれば、Gitはそれを可能にします。ここでは

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

で、そのタグを強制的にプッシュする必要があります。

git push --force --tags

しかし、また <強い よく考えて が必要です。

追記（2018/09/26）

自分の答えを見直す必要を感じています...。

何年もの間、私が「すでに公開されているタグを移動しないように」と指示したことに対して、コメントで異議を唱える人がいました。もちろん、この助言は普遍的というよりは文脈的なものです。私は、公開済みタグを移動するための良いケースが存在することを疑っていません。しかし、一般論として、公開済みタグを移動する決定は、意図的に、細心の注意を払って行われるべきであると、私は確信しています。

最近の例で思い浮かぶものが 1 つあります。Go 1.11 では、実験的なサポートとして モジュールシステム の実験的なサポートが追加されました。このシステムでは、バージョン管理のために Git タグに大きく依存しています。公開されている (たとえば GitHub で) Go モジュールのタグを移動すると、悲惨な結果になります。

そうすることで、あなた（モジュールの作者）とユーザー（あなたのモジュールに依存している人）の間に確立された契約を破ることになります。なぜなら、Goのモジュールシステムが提供しようとする保証を否定することになるからです。

モジュールは正確な依存性要件を記録し、再現可能なビルドを作成します。

それは人々を怒らせる一つの確実な方法です。

この例は、少なくともいくつかのケースでは、公開タグを無闇に移動すべきではないことを納得させるのに十分かもしれません。私は自分の主張を休みます。