在CentOS上克隆GitHub仓库需先安装Git并配置认证方式，推荐使用yum或dnf从官方源安装稳定版本，更新系统后执行sudo yum install git -y（CentOS 7）或sudo dnf install git -y（CentOS 8），安装后通过git –version验证；接着配置全局用户名和邮箱：git config –global user.name “用户名” 和 git config –global user.email “邮箱”；克隆仓库时可选HTTPS或SSH方式，HTTPS需使用个人访问令牌（PAT）代替密码，执行git clone https://github.com/用户名/仓库名.git并在提示时输入PAT；SSH方式更便捷安全，需生成密钥对ssh-keygen -t rsa -b 4096 -C “邮箱”，将公钥添加至GitHub的SSH keys中，再用git clone git@github.com:用户名/仓库名.git克隆；常见认证问题包括HTTPS因未用PAT导致失败，应生成PAT并可配置凭证缓存，SSH则常见于公钥未正确添加或ssh-agent未加载私钥，可通过ssh -T git@github.com测试连接，确保密钥存在且被正确识别。
在CentOS上克隆GitHub仓库，核心步骤无非是两点：先确保你的系统安装了Git这个版本控制工具，然后利用Git的
clone
命令将远程仓库的内容拉取到本地。听起来很简单对吧？但实际操作中，尤其对于刚接触Linux或者Git的朋友来说，安装Git的版本选择、以及后续的认证方式（HTTPS还是SSH，特别是GitHub现在对密码认证的限制），往往是容易让人卡壳的地方。理解这些细节，能让你少走不少弯路。
解决方案
要顺利在CentOS上安装Git并克隆GitHub仓库，我们通常会遵循以下步骤。这不仅仅是命令的堆砌，更是一种思维流程，确保你的环境是准备好的，并且知道如何应对可能出现的认证挑战。
首先，确保你的CentOS系统是最新的，这能避免一些不必要的依赖问题。
sudo yum update -y # CentOS 7及更早版本# 或者sudo dnf update -y # CentOS 8及更新版本
更新完成后，我们就可以安装Git了。CentOS的官方仓库通常会提供Git包，但版本可能不会是最新的。对于大多数日常使用，官方仓库的版本已经足够。
sudo yum install git -y # CentOS 7及更早版本# 或者sudo dnf install git -y # CentOS 8及更新版本
安装完成后，验证Git是否安装成功，并查看其版本：
git --version
接着，在使用Git之前，配置你的全局用户信息是良好的习惯，这会让你的每一次提交都带有你的身份信息。
git config --global user.name "你的GitHub用户名"git config --global user.email "你的GitHub注册邮箱"
这步很重要，因为它直接关联到你在GitHub上的提交记录。
现在，Git已经准备就绪，我们可以开始克隆GitHub仓库了。GitHub提供了两种主要的克隆方式：HTTPS和SSH。
1. 使用HTTPS方式克隆：这是最直接的方式，你可以在GitHub仓库页面的“Code”按钮下找到HTTPS链接。
git clone https://github.com/你的用户名/你的仓库名.git
当你执行这个命令时，如果是私有仓库，Git会提示你输入GitHub的用户名和密码。注意： GitHub在2021年8月之后不再支持使用账号密码进行HTTPS认证，你需要使用个人访问令牌（Personal Access Token, PAT）作为密码。这可能是我遇到过最常见的“坑”了，很多新手会在这里反复尝试密码而不得其解。
2. 使用SSH方式克隆：SSH方式相对来说设置稍微复杂一些，但一旦设置好，后续操作会非常便捷，不需要每次都输入认证信息，特别适合频繁操作和私有仓库。首先，你需要生成一对SSH密钥（如果还没有的话）：
ssh-keygen -t rsa -b 4096 -C "你的GitHub注册邮箱"
一路回车即可，或者根据提示设置密码。生成的密钥默认在
~/.ssh/id_rsa
（私钥）和
~/.ssh/id_rsa.pub
（公钥）。
然后，将你的公钥添加到GitHub账户。你可以通过以下命令查看公钥内容：
cat ~/.ssh/id_rsa.pub
复制显示的所有内容，登录GitHub，进入
Settings -> SSH and GPG keys -> New SSH key
，粘贴你的公钥并保存。
最后，使用SSH链接克隆仓库：
git clone git@github.com:你的用户名/你的仓库名.git
第一次使用SSH连接GitHub时，系统可能会询问你是否信任该主机，输入
yes
即可。
在CentOS上安装Git有哪些推荐且稳定的方法？
在CentOS这样的企业级Linux发行版上，安装Git其实有几种路径，但为了稳定性和维护便利性，我个人最推荐的，也是最主流的，就是通过系统自带的包管理器来安装。
1. 使用
yum
或
dnf
（推荐，最稳定）：这是最简单、最稳妥的方式。对于CentOS 7及更早版本，使用
yum
；对于CentOS 8及更新版本（包括RHEL 8+），则使用
dnf
。这两个工具会自动处理依赖关系，从官方或配置的软件源中获取Git包。
# CentOS 7sudo yum install git -y# CentOS 8sudo dnf install git -y
这种方式的优点是：
稳定可靠： 包管理器提供的版本经过测试，与系统兼容性好。维护方便： 后续升级Git也只需要简单的
yum update git
或
dnf update git
。依赖自动处理： 你不需要手动解决Git运行所需的各种库文件。
缺点可能就是，通过这种方式安装的Git版本，通常不会是最新版。对于大多数开发者来说，这通常不是问题，但如果你需要Git的最新特性，可能就需要考虑其他方法。
FineVoice语音克隆
免费在线语音克隆，1 分钟克隆你的声音，保留口音和所有细微差别。
61 查看详情 
2. 通过EPEL仓库安装（获取较新版本）：如果官方仓库的Git版本太旧，而你又不想手动编译，可以考虑启用EPEL (Extra Packages for Enterprise Linux) 仓库。EPEL是一个由Fedora项目维护的，为RHEL及其衍生系统提供高质量额外软件包的仓库。启用EPEL后，你通常能安装到比官方仓库更新的Git版本。
# CentOS 7sudo yum install epel-release -ysudo yum update -ysudo yum install git -y# CentOS 8sudo dnf install epel-release -ysudo dnf update -ysudo dnf install git -y
安装步骤与普通安装类似，只是在之前多了一步安装
epel-release
。我个人觉得，对于需要较新Git版本但又不想折腾编译的场景，这是个很好的折衷方案。
3. 从源代码编译安装（不推荐，除非有特殊需求）：理论上，你总是可以从Git的官方网站下载源代码，然后手动编译安装。
# 示例命令，具体步骤可能因Git版本而异sudo yum groupinstall "Development Tools" -y # 安装编译工具sudo yum install curl-devel expat-devel gettext-devel openssl-devel zlib-devel perl-ExtUtils-MakeMaker -y # 安装依赖wget https://mirrors.edge.kernel.org/pub/software/scm/git/git-x.x.x.tar.gz # 下载最新版tar -zxf git-x.x.x.tar.gzcd git-x.x.xmake prefix=/usr/local allsudo make prefix=/usr/local install
这种方式的优点是：你能获得最新、最定制化的Git版本。缺点非常明显：
复杂： 需要手动解决各种编译依赖，过程繁琐。维护困难： 后续升级也需要手动重复编译过程。可能引入不稳定因素： 编译环境或参数不对可能导致非预期行为。除非你真的需要Git的某个前沿特性，或者需要在特定的非标准路径下安装，否则我强烈不建议采用这种方式。对于日常开发，
yum/dnf
或EPEL的Git版本已经足够了。
克隆GitHub仓库时，HTTPS和SSH方式有什么区别和优劣？
这两种克隆方式，HTTPS和SSH，是Git与远程仓库交互的两种主要协议。它们就像两条通往GitHub的道路，虽然都能达到目的地，但沿途的风景和通行规则却大相径庭。理解它们的区别，能帮助你根据自己的使用场景做出最佳选择。
1. HTTPS (Hypertext Transfer Protocol Secure) 方式：
工作原理： 基于HTTP协议，通过加密传输数据。当你克隆或推送时，Git会通过HTTPS协议连接到GitHub服务器。认证方式： 过去是使用GitHub用户名和密码。但现在，GitHub已经强制要求使用个人访问令牌（Personal Access Token, PAT）作为密码。 这意味着你需要在GitHub上生成一个PAT，然后在Git提示输入密码时，输入这个PAT。优点：设置简单： 对于初学者来说，获取HTTPS链接直接
git clone
是最直观的。不需要额外的配置，如生成SSH密钥。防火墙友好： HTTPS通常使用443端口，这是Web流量的标准端口，很少会被防火墙限制。无需本地密钥： 你可以在任何机器上克隆仓库，只要你知道PAT（或者如果是公共仓库则无需认证）。缺点：重复认证： 每次进行需要认证的操作（如
git push
到私有仓库），你可能都需要输入PAT。虽然可以通过Git凭证管理器（credential helper）来缓存凭证，但初始设置还是比SSH麻烦。安全性考量： PAT本身是一串长字符串，如果泄露，风险较大。不再支持密码： 这是个大坑，很多老教程还在说输入密码，但现在已经行不通了。
2. SSH (Secure Shell) 方式：
工作原理： 基于SSH协议，通过公钥-私钥对进行身份验证。你的私钥保存在本地，公钥添加到GitHub账户。当Git通过SSH连接GitHub时，GitHub会使用你提供的公钥来验证你的身份。认证方式： 基于SSH密钥对。本地生成密钥对，将公钥添加到GitHub账户，私钥安全地保存在本地。优点：无需重复认证： 一旦SSH密钥设置好，你就可以进行无密码的交互，极大地提高了开发效率，特别是当你频繁进行
push
或
pull
操作时。安全性高： 私钥从不离开你的本地机器，公钥即使泄露也无法用于认证。你可以为私钥设置密码，增加一层保护。多账户管理： 通过配置
~/.ssh/config
文件，可以轻松管理多个GitHub账户（或不同Git服务提供商）的SSH密钥。缺点：初始设置复杂： 需要生成SSH密钥对，并将公钥添加到GitHub，对于新手来说可能有点门槛。防火墙限制： SSH默认使用22端口，某些严格的防火墙环境可能会限制此端口的访问。密钥管理： 私钥必须妥善保管，一旦丢失或泄露，可能需要重新生成并更新GitHub上的公钥。
个人观点和选择建议：对于我个人而言，SSH是首选，尤其是在进行日常开发工作时。 尽管初始设置略显繁琐，但其带来的便捷性和安全性是HTTPS无法比拟的。想象一下，你每天要推送十几次代码，每次都要输入那个长长的PAT，那会是多么令人抓狂的事情！SSH一旦配置好，基本就是“一劳永逸”。
然而，如果只是偶尔克隆一个公共仓库，或者在临时、不常使用的机器上进行操作，HTTPS会更方便快捷，因为它不需要你生成和管理SSH密钥。但请记住，对于私有仓库，你依然需要PAT。
总结来说：
频繁开发、私有仓库、追求效率和安全：选择SSH。偶尔操作、公共仓库、追求快速上手：选择HTTPS（并准备好PAT）。
在CentOS中，如何解决克隆GitHub仓库时遇到的常见认证问题？
认证问题是克隆GitHub仓库时最常见的拦路虎，尤其是GitHub对密码认证策略的调整后，很多开发者在这里踩过坑。解决这类问题，关键在于理解其背后的原理，并针对性地排查。
1. HTTPS方式的认证问题：
最常见的错误提示可能是
Authentication failed for 'https://github.com/...'
，或者直接提示你输入密码但输入正确密码后依然失败。
问题核心： GitHub不再支持使用账户密码进行HTTPS认证。解决方案：使用个人访问令牌（Personal Access Token, PAT）。生成PAT： 登录GitHub，点击右上角头像 ->
Settings
-> 左侧边栏找到
Developer settings
->
Personal access tokens
->
Tokens (classic)
->
Generate new token
。配置权限： 给你的令牌起个名字，并勾选必要的权限（例如，如果只是克隆和推送，
repo
权限通常足够）。保存PAT： 生成的令牌只会显示一次，务必复制并妥善保存。它就是你的“密码”。使用PAT： 当Git提示你输入密码时，粘贴你生成的PAT。缓存PAT（可选，但强烈推荐）： 为了避免每次都输入PAT，你可以配置Git凭证管理器。
git config --global credential.helper store# 第一次输入PAT后，Git会将其存储在 ~/.git-credentials 文件中# 或者使用更安全的缓存方式，例如 libsecret# git config --global credential.helper /usr/bin/git-credential-libsecret# 这通常需要安装额外的包，如 gnome-keyring 或 libsecret
credential.helper store
会将凭证以明文形式存储，方便但不安全。
libsecret
等是更安全的选项，它将凭证存储在系统的密钥环中。
2. SSH方式的认证问题：
SSH认证失败通常会提示
Permission denied (publickey)
，或者
fatal: Could not read from remote repository.
。这通常意味着你的SSH密钥没有正确设置或GitHub无法识别。
问题核心： GitHub无法通过你的公钥验证你的身份。排查步骤及解决方案：检查SSH密钥是否存在： 确认你的私钥文件（默认为
~/.ssh/id_rsa
）和公钥文件（默认为
~/.ssh/id_rsa.pub
）是否存在。
ls -al ~/.ssh/
如果没有，你需要重新生成：
ssh-keygen -t rsa -b 4096 -C "你的GitHub注册邮箱"
。
检查公钥是否已添加到GitHub：使用
cat ~/.ssh/id_rsa.pub
命令查看你的公钥内容。登录GitHub，进入
Settings -> SSH and GPG keys
，确认这个公钥已经添加，并且没有被禁用。确保你复制的是完整的公钥内容，包括开头的
ssh-rsa
和结尾的邮箱。检查SSH代理（ssh-agent）是否运行并加载了密钥：
ssh-agent
可以缓存你的私钥密码，避免每次使用都输入。
eval "$(ssh-agent -s)" # 启动ssh-agentssh-add ~/.ssh/id_rsa # 添加私钥，如果私钥有密码会提示输入
运行
ssh-add -l
可以查看当前
ssh-agent
中加载的密钥。
测试SSH连接： 这是一个非常重要的诊断步骤。
ssh -T git@github.com
如果一切正常，你会看到
Hi 你的GitHub用户名! You've successfully authenticated, but GitHub does not provide shell access.
这样的消息。如果提示
Permission denied
，则说明认证仍有问题。
检查
~/.ssh/config
文件（高级）： 如果你管理多个SSH密钥或有特定的SSH配置需求，检查这个文件。例如，确保
Host github.com
条目没有错误配置。
Host github.com HostName github.com User git IdentityFile ~/.ssh/id_rsa # 确保指向正确的私钥文件 # 或者如果你有多个密钥，可以指定不同的 # IdentityFile ~/.ssh/id_rsa_your_other_key
防火墙问题： 极少数情况下，本地或网络防火墙可能阻止SSH（22端口）连接。可以尝试临时关闭防火墙测试（仅限受控环境），或联系网络管理员。
总结一下我的经验：大多数SSH认证问题都出在公钥没有正确添加到GitHub或者
ssh-agent
没有加载私钥。而HTTPS认证问题，几乎100%都是因为没有使用PAT。只要理清这两条线，认证的“坎”基本就能迈过去了。遇到问题不要慌，一步步排查，总能找到症结所在。
以上就是CentOS中怎么克隆Github_CentOS安装Git与克隆仓库教程的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/345626.html
微信扫一扫 
支付宝扫一扫 
