似乎xargs已经做了很多工作。回顾这篇文章，我猜你所经历的xargs的缓慢是因为最初的答案使用了xargs-n 1，而实际上并不需要。

除了xargs自动处理最大命令行长度之外，这与方法1等效：

git tag | sorting_processing_etc | xargs git push --delete origin

xargs也可以并行运行进程。使用xargs的方法2：

git tag | sorting_processing_etc | xargs -P 5 -n 100 git push --delete origin

上面最多使用5个进程来处理每个进程中最多100个参数。你可以尝试这些论点，以找到最适合你的需求的东西。

这里有一个本地测试用例，可以在本地测试而不干扰远程设备：

~/p $ mkdir gittest    
~/p/git $ cd gittest/
~/p/gittest $ git init
Initialized empty Git repository in /Users/local_user/p/gittest/.git/
 ~/p/gittest $ touch testfile.txt
 ~/p/gittest $ git add testfile.txt
 ~/p/gittest $ git commit -m "initial commit"
[master (root-commit) 912ce0e] initial commit
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 testfile.txt
 ~/p/gittest $ git tag
 ~/p/gittest $ git tag -a testtag
 ~/p/gittest $ git tag
testtag
 ~/p/gittest $ git show-ref
912ce0e40635c90241fdab756dce7ea34938de57 refs/heads/master
b0a6c15cabb990e6d6c46f762891b63608d962f3 refs/tags/testtag
 ~/p/gittest $ cd ..
 ~/p $ mkdir gitbare
 ~/p $ cd gitbare
 ~/p/gitbare $ git init --bare
Initialized empty Git repository in /Users/local_user/p/gitbare/
 ~/p/gitbare $ cd ..
 ~/p $ cd gittest/
 ~/p/gittest $ git remote add origin /Users/local_user/p/gitbare
 ~/p/gittest $ git push -u origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 215 bytes | 215.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To /Users/local_user/p/gitbare
 * [new branch]      master -> master
Branch 'master' set up to track remote branch 'master' from 'origin'.
 ~/p/gittest $ git push origin testtag
Counting objects: 1, done.
Writing objects: 100% (1/1), 163 bytes | 163.00 KiB/s, done.
Total 1 (delta 0), reused 0 (delta 0)
To /Users/local_user/p/gitbare
 * [new tag]         testtag -> testtag
 ~/p/gittest $ git show-ref
912ce0e40635c90241fdab756dce7ea34938de57 refs/heads/master
912ce0e40635c90241fdab756dce7ea34938de57 refs/remotes/origin/master
b0a6c15cabb990e6d6c46f762891b63608d962f3 refs/tags/testtag
 ~/p/gittest $ git push -d origin testtag
To /Users/local_user/p/gitbare
 - [deleted]         testtag
 ~/p/gittest    git tag -d testtag
Deleted tag 'testtag' (was b0a6c15)
 ~/p/gittest $ git show-ref
912ce0e40635c90241fdab756dce7ea34938de57 refs/heads/master
912ce0e40635c90241fdab756dce7ea34938de57 refs/remotes/origin/master
 ~/p/gittest

如果您有一个远程标签v0.1.0要删除，并且您的远程标签是源，那么只需：

git push origin :refs/tags/v0.1.0

如果您还需要在本地删除标记：

git tag -d v0.1.0

有关Git异常的解释，请参见Adam Franco的回答：删除语法。

gitpush--delete origin$TAGNAME是正确的方法（除了本地删除之外）。

但是：确保使用Git 2.31+（2021第一季度）。

“git-push$there--delete”（man）本应被诊断为一个错误，但却变成了一个匹配的push，已使用git 2.31（2021第1季度）进行了更正。

参见Junio C Hamano（gitster）提交的20e4164（2021 2月23日）。（由Junio C Hamano——gitster——于2021 2月25日提交1400458合并）

push：不要将--delete“”转换为匹配的push通知人：Tilman Vogel

当我们将语法糖“git push remote--delete”（man）＜ref＞添加到“git推送”（man）中，作为标准git pushremote（man）的同义词：语法在f517f1f（“内置推送：add（man）--delete as syntax sugar for：foo”，2009-12-30，git v1.7.0-rc0--merge）中时，我们没有足够谨慎地确保＜ref＞不为空。盲目地将“--delete＜ref＞”重写为“：＜ref＞“意味着空字符串＜ref＞将导致refspec“：”，这是要求“匹配”推送的语法，但不删除任何内容。更糟糕的是，如果有匹配的引用可以快速转发，那么即使用户觉得它们还没有准备好推出，它们也会过早发布，这将是一场真正的灾难。

我只是想分享我创建的别名，它做了同样的事情：

将以下内容添加到~/.gitconfig中

[alias]
    delete-tag = "!f() { \
            echo 'deleting tag' $1 'from remote/origin ausing command: git push --delete origin tagName;'; \
            git push --delete origin $1; \
            echo 'deleting tag' $1 'from local using command: git tag -d tagName;'; \
            git tag -d $1; \
        }; f"

用法如下：

-->git delete-tag v1.0-DeleteMe
deleting tag v1.0-DeleteMe from remote/origin ausing command: git push --delete origin tagName;
To https://github.com/jsticha/pafs
 - [deleted]             v1.0-DeleteMe
deleting tag v1.0-DeleteMe from local using command: git tag -d tagName;
Deleted tag 'v1.0-DeleteMe' (was 300d3ef22)

其他答案指出了如何实现这一点，但您应该记住后果，因为这是一个远程存储库。

git标签手册页的On Retagging部分很好地解释了如何礼貌地将更改通知远程回购的其他用户。他们甚至提供了一个方便的公告模板，用于传达其他人应该如何获得您的更改。