GitHub已经多次更改了他们的建议（example）。
看来他们目前推荐HTTPS，因为它是最容易在最广泛的网络和平台上设置的，并且是由新用户设置的。
SSH没有固有的缺陷（如果有，他们会禁用它）-在下面的链接中，您将看到他们仍然提供有关SSH连接的详细信息：

1. HTTPS不太可能被防火墙阻止。
   https://docs.github.com/en/get-started/getting-started-with-git/about-remote-repositories#cloning-with-https-urls
   https://克隆URL可用于所有存储库，无论可见性如何。https://克隆URL即使在防火墙或代理服务器后面也可以工作。
2. HTTPS连接允许credential.helper缓存您的密码。
   https://docs.github.com/en/get-started/quickstart/set-up-git#connecting-over-https-recommended
   如果您使用HTTPS克隆，则可以使用凭据帮助程序在Git中缓存您的GitHub凭据。有关详细信息，请参阅“使用HTTPS URL克隆”和“Caching your GitHub credentials in Git.”

我假设GitHub推荐HTTPS有几个原因
1.从任何地方访问存储库都更简单，因为您只需要您的帐户详细信息（不需要SSH密钥）即可写入存储库。

1. HTTPS是在所有防火墙中打开的端口。SSH并不总是作为与外部网络通信的端口打开
   因此，使用HTTPS比SSH更容易访问GitHub存储库。
   在我看来，SSH密钥值得在创建它们时做一些额外的工作
2. SSH密钥不提供对您的GitHub帐户的访问，因此如果您的密钥被盗，您的帐户不会被劫持。
   1.在SSH密钥中使用强关键词可以限制任何滥用，即使您的密钥被盗（在首次破坏对计算机帐户的访问保护之后）
   如果您的GitHub帐户凭据（用户名/密码）被盗，可以更改您的GitHub密码以阻止您访问，并且可以快速删除所有共享存储库。
   如果私钥被盗，有人可以强制推送一个空的存储库，并清除您拥有的每个存储库的所有更改历史，但无法更改您的GitHub帐户中的任何内容。如果你可以访问你的GitHub帐户，尝试从这个漏洞中恢复会容易得多。
   我的首选是使用SSH和密码保护的密钥。我为每台计算机都有一个不同的SSH密钥，所以如果那台机器被盗或密钥泄露，我可以快速登录到GitHub并删除该密钥以防止不必要的访问。
   如果您所在的网络阻塞了SSH端口，则SSH可以通过HTTPS进行隧道传输。
   https://help.github.com/articles/using-ssh-over-the-https-port/
   如果您使用HTTPS，我建议您添加双因素身份验证，以保护您的帐户和存储库。
   如果您使用HTTPS与工具（例如编辑器），您应该使用GitHub帐户中的开发人员令牌，而不是在该工具配置中缓存用户名和密码。令牌可以减轻使用HTTPS的一些潜在风险，因为令牌可以配置为非常特定的访问权限，并且如果该令牌被泄露，则可以轻松撤销。

要么你引用错了，要么github在不同的页面上有不同的推荐，或者他们可能会随着时间的推移而学习并更新他们的reco。

• 我们强烈建议在与GitHub交互时使用SSH连接。SSH密钥是一种识别受信任计算机的方法，无需使用密码。下面的步骤将引导您生成SSH密钥，然后将公钥添加到您的GitHub帐户。

https://help.github.com/articles/generating-ssh-keys

推荐：使用带有 OAuth credential helper 的HTTPS，如Git Credential Manager或git-credential-oauth。

没有更多的密码或个人访问令牌！第一次推送时，助手将打开一个浏览器窗口进行身份验证。在存储寿命内的后续推送不需要交互。

SSH的缺点：

• 克隆或获取公共存储库时进行不必要的身份验证。
• 必须安装SSH客户端。
• 创建SSH密钥对于许多Git新用户来说并不熟悉。
• 为了防止中间人攻击，用户必须手动verify the host fingerprints。不是每个人都烦！
• 在主机上配置密钥涉及到在终端和网站之间进行复制和粘贴。要使用3台计算机和5台主机，用户必须执行此操作15次。
• 没有密码的SSH密钥以明文形式存储，不会过期。
• 必须定期键入SSH密钥密码（如果使用）。即使在配置了ssh-agent之后，每次系统重启之后都必须输入密码。
• SSH有时会被防火墙阻止。

HTTPS的优势：

• 克隆或获取公共存储库无需身份验证。
• 使用HTTPS证书自动验证服务器真实性。
• 假设您使用了一个OAuth凭证助手，如Git Credential Manager或git-credential-oauth，您永远不必输入密码或配置个人访问令牌。
• OAuth协议通过使用短期令牌和检测重放攻击的刷新令牌循环来防止令牌被盗。这是优于个人访问令牌的优点。
• 凭证可以存储在缓存或特定于平台的存储中，例如winred、osxkeychain或libsecret。

使用SSH密钥进行身份验证的安全性可能会降低，因为我们更倾向于定期更改密码，而不是生成新的SSH密钥。
服务器限制了它们将荣誉给定SSH密钥的寿命，这有助于强制用户定期刷新SSH密钥。

支持HTTPS的另一个原因是，如果多个用户在一个中央服务器上管理代码--比如一台开发机器--每个用户都需要创建自己的ssh密钥，以便使用基于SSH的连接。如果连接是HTTPS，则不存在此问题。
我猜你可能会争辩说，设置自己的密钥并不是很难，只是使用存储项目的服务器的一部分，但这是完成工作的另一个障碍。

Git对此没有“官方”建议，但每个Git远程主机都有自己的首选项。
例如，GitHub网站和GitHub CLI都是default to HTTPS，以“更好的互操作性和易用性”。另一方面，GitLab在其文档中推荐SSH。
这两种方法各有优缺点：

• SSH
• 优势
• 允许在不使用凭据管理器的情况下进行自动身份验证
• SSH密钥比用户名和密码身份验证更安全
• 缺点
• 防火墙可能会阻塞SSH使用的端口22
• 必须在连接到远程的每台计算机上管理SSH密钥
• HTTPS
• 优势
• 通过用户名/密码组合或个人访问令牌简化身份验证设置
• 使用端口443，很少被防火墙阻止
• 缺点
• 比SSH密钥更安全
• 需要重新输入用户名和密码进行身份验证，而不使用凭据管理器

由于各种原因，这些建议在过去几年中发生了变化。

• 凭据管理器和访问令牌消除了通过HTTPS进行身份验证的自动化问题
• 如今，自托管Git远程设备的情况要少得多。自托管意味着对于SSH身份验证，所有贡献者都需要对主机进行SSH访问，但在专用网络中进行设置和保护通常更容易
• 监听端口9418的Git协议是一个很少使用的守护进程，它与Git一起预先打包。它是目前最快的协议，但也被认为是不安全的