Git应用之使用问题集锦 | Malloy Yuan的博客

type

status

date

slug

summary

Push代码时显示Everything up-to-date，但是未显示在文件目录

这种情况新手一定会发生，且无从下手，这其实跟git的实现原理密切相关。

一般发生在自有远程服务器的远端仓库（因为GIthub远端仓库会自动同步仓库最新状态文件进行显示），没有设置hook钩子将当前仓库最新的文件同步至需要显示的本地仓库显示目录。

其他情况排查

检查文件是否被 Git 跟踪

首先，确保 .html 文件和文件夹被 Git 跟踪。可以使用以下命令查看工作目录的状态：

如果这些文件没有显示在 "Changes not staged for commit" 或 "Untracked files" 下，那么它们没有被跟踪。要开始跟踪它们，需要将它们添加到暂存区：

检查 .gitignore 文件

确保的 .gitignore 文件没有排除 .html 文件或文件夹。打开的 .gitignore 文件，查看是否有任何模式排除了这些文件。如果有，删除这些行或进行相应调整。

确保在正确的分支上

确保在正确的分支上（这里是 master）：

验证远程仓库 URL

检查远程仓库的 URL 是否正确：

这将显示远程仓库的 URL，确保它与想要推送的仓库匹配。

检查本地仓库问题

如果上述步骤没有解决问题，可能是本地仓库设置有问题。尝试在一个新目录中克隆该仓库并重复这些步骤：

验证权限

确保有写入远程仓库的适当权限。因为使用的是 root 账户的 SSH，通常应该有必要的权限，但也要确认 SSH 密钥配置正确。

远程仓库地址错误提示内容

kex_exchange_identification: Connection closed by remote host Connection closed by 198.xxx.xx.xx.x port 30576

kex_exchange_identification: Connection closed by remote host 表示在尝试通过 SSH 连接到远程主机时，密钥交换过程被远程主机关闭。这通常意味着远程主机拒绝了连接。原因是所连接的仓库地址填写错误，需要重新检查仓库地址核对。

没有初始化远程仓库的错误提示信息

是的，如果要将本地代码推送到远程服务器上的某个目录，那么该目录必须是一个已经初始化的 Git 仓库。推送操作需要远程仓库来接收和管理这些提交记录。下面是一些关键点：

远程仓库必须已经初始化才可以进行git操作，新仓库并不会在初次推送代码时自动初始化仓库

Git 版本控制需求：Git 是一个分布式版本控制系统，本地和远程仓库都需要有一个 .git 目录来存储版本历史、配置和其他 Git 对象。如果远程路径没有初始化为 Git 仓库，Git 不知道如何处理从本地推送过去的提交数据。

保证一致性：初始化 Git 仓库会创建必要的目录结构和文件，这些是 Git 操作所需的最小环境。没有这些初始化的结构，Git 的推送操作无法完成。

通信端口号设置错误的错误提示信息

Action通过Github API拉取数据时提示rate limit显示问题

API 请求超过了 GitHub 的速率限制。根据 GitHub 的文档，未认证的请求速率限制较低，而经过身份验证的请求有更高的速率限制。

在环境变量.env文件中设置访问令牌增加访问权限

将访问令牌设置为环境变量，以确保它在脚本运行时可用：

本地运行：可以创建一个 .env 文件，并添加如下内容：

GitHub Actions：将 GITHUB_TOKEN 存储在 GitHub Secrets 中，然后在 GitHub Actions 工作流中引用：

Action中使用secret引入带有端口的URL进行ssh-keyscan通讯时必须拆分成两个独立secret独立存储端口号和域名或者IP

因为不这样的话Action会解析引用错误报错

ssh-keyscan -t rsa -p "${{ secrets.MYECS_ADD_PORT }}" "${{ secrets.MYECS_ADD }}" >> ~/.ssh/known_hosts

~/.ssh/known_hosts中域名地址或者IP地址时，对于非22号端口的其他端口时也都不需要端口号

known_hosts 文件：不需要包含端口号，仅需存储主机名（或 IP 地址）和主机密钥。

SSH 连接：在 SSH 连接命令中使用-p 选项指定端口号。known_hosts 文件中的条目不需要包括端口号。

git的SSH通讯方式与https通讯方式的切换可能会发生的问题

从https://github.com/user/project.git切换git@github.com:user/project.git时几乎不会有什么问题可以马上进行仓库操作但是当我从git@github.com:user/project.git切换https://github.com/user/project.git时，push时

在windows端把打开的终端重开进行push就好了。

重新打开终端可能有助于刷新环境变量和配置，更好地处理 SSH 密钥或代理设置的更改。以下是我可能的原因：

SSH Agent：

如果使用了 SSH 密钥进行认证，SSH Agent 可能没有正确加载密钥。关闭并重新打开终端会重新启动 SSH Agent 并加载所有的密钥。

网络连接的临时问题：

之前的网络连接可能出现了短暂的不稳定状况。重新打开终端后，重新建立的连接可能避开了之前的网络问题。

Git Credential Manager：

在重新打开终端时，Git Credential Manager 可能重新请求了凭证，并正确加载了的 SSH 密钥或访问令牌。

设置好了token还要使用用户名密码或者Acess token令牌登录Authorize Git Credential Manager问题

在使用 Git 推送代码到 GitHub 时，通常有两种身份验证方式：SSH 公钥 和 个人访问令牌（PAT）。而SSH 公钥用于匹配SSH 协议通信方式的，而个人访问令牌（PAT）用于 HTTPS 协议通信方式，这种情况出现的原因就是添加的远程仓库时https格式的仓库，而不是ssh://…或者git@…的ssh协议通讯方式。

检查SSH 远程 URL 配置错误：

确保的远程仓库 URL 使用了 SSH 协议，而不是 HTTPS 协议。可以使用以下命令检查和设置 SSH 远程 URL：如果输出中显示的是 HTTPS URL（如 https://github.com/user/repo.git），需要将其改为 SSH URL（如 git@github.com:user/repo.git）：

什么时候需要个人访问令牌（PAT）？

个人访问令牌通常在以下情况下使用：

使用 HTTPS 进行身份验证：如果选择使用 HTTPS URL 进行 Git 操作，GitHub 不再接受直接使用密码进行认证，而是要求使用个人访问令牌（PAT）。PAT 是替代密码的安全方式。

特定 API 操作：一些需要特定权限的 GitHub API 操作可能要求使用 PAT。

没有配置 SSH 或 SSH 被限制：在某些环境中，SSH 连接可能被限制或阻止。在这种情况下，可以使用 HTTPS 和 PAT 作为替代。

如果已经正常通信过Github但是突然“fatal: unable to access”仓库

绝大部分情况下是网络问题，因为“城墙”缘故：

网络连接不稳定或者网络断开。

的 ISP 可能在阻止访问 GitHub（在某些国家和地区可能会出现这种情况）。

使用 SSH 替代 HTTPS：

如果网络环境限制了对 HTTPS 的访问，可以尝试使用 SSH 克隆和操作仓库。首先，确保的 SSH 密钥已经正确配置，然后将远程 URL 更改为 SSH：

多台PC可以共用ssh-keygen问题

多台 PC 可以共用一个 SSH 密钥对（id_rsa 和 id_rsa.pub），但需要注意一些细节和潜在的安全问题。公开场合必要重要的服务的话可以每台设备使用不同的 SSH 密钥对。

第一次连接到新Github平台的“not provide shell access”信息

Hi MCUheart! You've successfully authenticated, but GitHub does not provide shell access. 是什么原因？

当尝试使用 SSH 连接到 GitHub 时，看到以下信息是正常的：

成功认证：这条消息表明的 SSH 密钥已经正确配置，并且 GitHub 已成功验证了的身份。这意味着的 SSH 公钥已经正确添加到 GitHub 账户中，GitHub 确认是 MCUheart 用户。

无 shell 访问：GitHub 使用 SSH 来进行 Git 操作（如克隆、拉取和推送代码），而不是提供交互式 shell 访问（例如使用 ssh 登录到 GitHub 服务器进行命令行操作）。因此，当通过 SSH 连接 GitHub 时，只允许执行 Git 操作，而不是获取一个可以输入命令的 shell。这就是为什么会显示“GitHub does not provide shell access”这条消息。

正常情况下的用途

当运行 ssh -T git@github.com 时，这条命令的目的是测试的 SSH 配置和 GitHub 的连接是否正常。这条信息说明已经成功配置了 SSH，可以用来执行 Git 操作，如克隆、提交和推送代码到的 GitHub 仓库。

SSH通过验证但是发生密钥交换过程（kex）期间连接被重置错误

这个信息显示的 SSH 连接已成功通过身份验证，并且 GitHub 确认了是 MCUheart 用户。但是后续的连接尝试被重置，这可能有几种原因：

信息解析

成功身份验证：消息 Hi MCUheart! You've successfully authenticated, but GitHub does not provide shell access. 说明的 SSH 密钥已成功与 GitHub 关联，并且认证成功。请注意，这也是 GitHub 的预期行为，因为 GitHub 不提供交互式 shell 访问，SSH 仅用于 Git 操作（如克隆、拉取和推送）。

连接重置错误：kex_exchange_identification: read: Connection reset 和 Connection reset by 198.18.0.25 port 22 表示在密钥交换过程（kex）期间连接被重置。这通常与网络问题、SSH 配置错误或防火墙设置有关。

系统迁移、重装或者恢复后，公、私秘钥都相同的情况下，无法与以前建连接的Github通讯

这个错误信息表明在尝试通过 SSH 连接到 GitHub 时，远程主机的标识（host key）与以前存储在的 known_hosts 文件中的记录不匹配。需要重新更新known_hosts记录。

解决方法

更新 known_hosts 文件：

打开终端或 PowerShell，运行以下命令删除旧的 GitHub 主机密钥记录：

然后，再次尝试连接到 GitHub（例如通过 git pull 或 git push），SSH 会提示接受新的主机密钥：

检查 SSH 配置：确保的 SSH 配置文件（通常是 ~/.ssh/config）中没有错误的条目。例如，确保没有错误地尝试连接到 qq.com。

网络问题：的连接尝试似乎在连接 qq.com 时超时了，这表明可能使用了错误的配置。应该确保 SSH 目标主机配置正确，例如 git@github.com。

手动编辑 known_hosts 文件：如果删除整个文件有风险或不方便，可以手动编辑 C:\\Users\\yuanm/.ssh/known_hosts 文件，删除与 GitHub 相关的那一行（通常会在错误信息中指出行号，例如：known_hosts:1）。

当使用git操作所用的用户不是文件用户名组所有出现的问题

比方说，使用root用户进行操作malloy用户组所有的仓库文件夹就会出现此错误，此处就算是root管理权限用户也不能去操作其他用户的仓库文件。

从Github fork到自己的仓库后，原始仓库存在的最新数据同步问题

GitHub 上将一个仓库 fork 到自己的账户后，默认情况下是不会自动与原始仓库同步的。为了保持 fork 的仓库与原始仓库最新的数据同步，需要手动进行同步操作。以下是几种常用的方法来实现这一目的：

1. 手动同步 (通过命令行)

添加原始仓库作为远程仓库：在 fork 后的仓库中添加一个指向原始仓库的远程引用，通常命名为 upstream。

获取原始仓库的更新：从 upstream 远程仓库拉取最新的更改。

将更新合并到的分支：通常情况下，会将更改合并到 main 或 master 分支。

推送到的 fork 仓库：如果需要在 GitHub 上同步的 fork 仓库。

2. 使用 GitHub Actions 实现自动同步

可以使用 GitHub Actions 来实现自动同步的功能。以下是一个简单的 GitHub Actions 配置文件，它会定期自动从原始仓库拉取更改并更新的 fork 仓库：

在 fork 的仓库中创建一个文件 .github/workflows/sync.yml。

在文件中添加以下内容：

以上方法会每天自动将原始仓库的最新更改同步到的 fork 仓库的 main 分支。如果使用的是其他分支或有更复杂的需求，可以调整相应的配置。