我怎么知道git推送完成的百分比是多少？

我正在把一个大约200MB的代码推到回购协议中。这需要很多时间。我们是否可以显示进度条，这样我就可以知道有多少代码被推送到回购协议中？

它不是进度“条”，但是当从终端运行时，

git push

已经默认报告了进度。从：

除非指定了

-q

，否则当标准错误流连接到终端时，默认情况下会在标准错误流上报告进度状态。即使标准错误流未定向到终端，此标志也会强制执行进度状态

您试图一次推送200 MB的事实表明，您可能在用git做一些次优的事情。

git推送——git 2.10（2016年第三季度）的进度将更加精确

见杰夫·金（佩夫）

索引包
命令有两个进度表：


一个用于“接收对象”，以及
一个用于“解析三角洲”

默认情况下，使用“
-v
”既不获取也不获取

但对于推送式接收包，我们只需要“
解析增量”
”阶段，而不是“
接收对象”
”过程。

原因有两个：


一个原因很简单，现有客户机已经在同时打印“写入对象”进度。

可以说，从远端“接收”更有用，因为它告诉您实际得到了什么，而不是什么可能卡在客户端和服务器之间的某个缓冲区中。但这需要一个协议扩展来告诉客户不要打印他们的进度。可能，但是
复杂而无收获


第二个原因更重要。

在像git over ssh这样的全双工连接中，我们可以在
该包正在传入，它将立即到达客户端。

但是对于半双工连接（如git over http），在收到完整请求之前，我们不应该说任何话。

我们编写的任何内容都可能被Web服务器卡在缓冲区中。更糟糕的是，如果缓冲区被填满，我们可能会陷入死锁



因此，我们最好的办法是避免写任何不符合标准的东西
小的固定尺寸，直到我们收到完整的包装


2016年9月更新：Git 2.10已经存在，您可以在GitHub博客文章“”中看到此进度表的示例：



更新Git 2.11（2016年第4季度）

现在，一个试图推送过多字节的传入“
git push
”现在可以
通过在接收端设置新的配置变量来拒绝
结束

参见（2016年8月24日）作者
参见（2016年8月24日）作者。

（于2016年9月9日合并）

接收包
：允许指定最大输入大小
Receive pack将其输入馈送到index pack或unpack对象，这些对象将乐于接受发送方愿意提供的字节数。

让我们允许一个任意的截止点，在这里我们将停止向磁盘写入字节

现在包括：

receive.maxInputSize
如果传入包流的大小大于此限制，则git receive pack将出错，而不是接受包文件。

如果未设置或设置为0，则大小不受限制


使用Git 2.22，可以更好地管理进度：

参见（2019年4月12日）和（2019年4月5日）作者。

（于2019年4月25日合并）

参见。

（于2019年5月30日合并）

进度
：打断过长的进度条行
最近增加的一些进度指标标题很长，
如果翻译成某些语言，时间可能更长
它们在更大的存储库上运行时显示，然后
进度条的长度超过默认的80列终端宽度

当进度条超过终端的宽度时，它会
线缠绕，之后，末端的CR不会返回到
进度条的开头，但到最后一列的第一列
行。

因此，前面显示的进度的第一行
条不会被下一条覆盖，我们最终会得到一堆
滚动过去的截断进度条行：

$ LANG=es_ES.UTF-8 git commit-graph write
  Encontrando commits para commit graph entre los objetos empaquetados:   2% (1599
  Encontrando commits para commit graph entre los objetos empaquetados:   3% (1975
  Encontrando commits para commit graph entre los objetos empaquetados:   4% (2633
  Encontrando commits para commit graph entre los objetos empaquetados:   5% (3292
  [...]

通过在标题后断开进度条来防止出现这种情况
超出终端的宽度，因此计数器和可选
百分比和吞吐量（即所有更换零件）位于最后
行。

从那时起，后续更新将仅刷新正在更改的
部分，但不是标题，它将如下所示：

$ LANG=es_ES.UTF-8 ~/src/git/git commit-graph write
  Encontrando commits para commit graph entre los objetos empaquetados:
  100% (6584502/6584502), listo.
  Calculando números de generación de commit graph: 100% (824705/824705), listo.
  Escribiendo commit graph en 4 pasos: 100% (3298820/3298820), listo.


Git 2.23（2019年第3季度）修复了重基的进度显示：

参见，，（2019年6月24日）和（2019年6月27日）作者。

（于2019年7月9日合并）

rebase
：用“
-x
”修复混乱的进度显示
在交互式rebase会话期间使用“
exec
”指令运行命令时，或者对于使用“
git rebase-x
”的一系列提交，当命令名足够短时，输出可能会有点混乱：

 $ git rebase -x true HEAD~5
 Executing: true
 Executing: true
 Executing: true
 Executing: true
 Executing: true)
 Successfully rebased and updated refs/heads/master.

注意最后一行末尾的“
）
”。

随着提交范围的增加，它会变得更加混乱：

 $ git rebase -x true HEAD~50
 Executing: true)
 [ repeated 3 more times ]
 Executing: true0)
 [ repeated 44 more times ]
 Executing: true00)
 Successfully rebased and updated refs/heads/master.

这些额外的数字和“
）
”是先前显示的“
重定基址（N/M）
”进度行的残余，这些进度行通常被“
执行：
”行完全覆盖，除非“
cmd
”短而“
N/M
”部分长

确保使用上一个修补程序中添加的
术语清除行（）
帮助函数清除先前显示的“
重定基址（N/M）
”行。

仅当不是“
--verbose
”时才这样做，因为在这种情况下，这些“
重定基址（N/M）
”行不是作为进度打印的（即，作为结尾带有“
\r
”的行），而是作为“常规”输出打印的（带有“
\N $ git rebase -x true HEAD~50
 Executing: true)
 [ repeated 3 more times ]
 Executing: true0)
 [ repeated 44 more times ]
 Executing: true00)
 Successfully rebased and updated refs/heads/master.

Collecting referenced commits: 123  

Expanding reachable commits in commit graph: 344786, done.
Computing commit changed paths Bloom filters: 100% (344786/344786), done.
Collecting referenced commits: 154, done.