下载和安装 Git新手最全实操记录前几天有个刚转行的朋友问我Git 装了一下午命令也敲了怎么死活拉不下来代码我远程一看好家伙安装的时候一堆关键选项全凭默认SSH key 也没配用户名邮箱还是空的这能不翻车吗。很多人以为下载和安装 Git就是把安装包点一遍 Next 的事但实际上 Git 的安装只是万里长征第一步安装之后的配置、密钥认证、IDE 集成才是真正决定你能不能顺畅工作的关键。我这些年帮人排查过无数次 Git 环境问题今天把下载安装到配置落地的完整链路写出来Windows、macOS、Linux 都有顺便把热搜上反复出现的SSH 认证失败IDEA 拉取项目分支合并这些高频痛点一并拆掉。这篇文章适合刚接触 Git 的初学者也适合那些装了但用不明白的开发者。不整虚的全是实操经验和踩坑记录。1. 安装 Git 前先把这三件事想清楚1.1 别用最新版崇拜稳定版才是干活首选很多人在官网看到 Latest Source Release 就直接点下载觉得越新越好。我的建议恰恰相反装 Git 选稳定维护版本别追最新。Git 的更新节奏很快但你日常用到的功能在几年前的版本上就已经很完善了新版本带来的绝大多数变化跟你没关系反而可能引入一些新的行为变化影响你已有的脚本或 IDE 插件。那什么叫稳定维护版本Git 官网有一个 Downloads 页面里面会有类似 Visual Studio Code 风格的版本提示实际上对于 Git 来说你认准最新发布的主版本即可比如当前 2.4x 版本。但如果你在公司环境里建议先看看团队其他人用的是什么版本保持一致能少很多我这命令咋不好使的莫名其妙问题。注意Windows 用户下载 exe 安装包时要留意位数现在几乎都是 64 位系统直接选 64-bit 版本。除非你还在用 32 位的老机器否则不用纠结。1.2 三个平台三种安装思路Windows官方 exe 安装包装完即用集成环境最完整适合绝大多数人。macOS两种主流方式——官方 pkg 安装包或者 Homebrewbrew install git。我个人推荐 Homebrew因为后续升级方便一条命令搞定。Linux用发行版自带的包管理器apt、yum、dnf 等但有个坑后面会细说。确定系统后下一个问题是用什么方式装1.3 包管理器 vs 官方安装包到底怎么选这其实是省事和可控之间的取舍。Windows 上Chocolatey 或 winget 也能装 Gitwinget install Git.Git但我更推荐直接下载官方 exe。原因很简单官方安装包在安装过程中会把 Git Bash、Git GUI、凭证管理器这些组件一起配好对新手最友好省掉后面一堆环境变量和组件的麻烦。macOS 上我反而推荐 Homebrew因为配制好 PATH 顺手而且以后brew upgrade git就完事不需要重新下载安装包。Linux 用户注意了用apt install git的时候先看一眼版本有些发行版的软件源里 Git 版本比较老如果版本太低影响你后续使用比如某些新命令语法不支持就需要用官方 PPA 或源码编译。这里的判断标准很简单git --version看看2.30 以上基本都够用。2. 各平台的下载安装实操记录2.1 Windows 详细安装步骤打开 Git 官网下载页选 Windows 对应的 64-bit 版本下载后双击运行。整个安装向导大概有七八步我捡几个关键页面说一下。第一个是Select Components选择组件这一页默认勾选了 Git Bash、Git GUI、Git LFS、关联配置文件等选项。默认勾选的全部保留别取消。有些教程让你少装组件省那几十 MB 空间结果后面要用 Git LFS 的时候又得手动补装得不偿失。接着是Choosing the default editor会让你选 Git 默认使用的编辑器。如果你装了 VS Code直接选 Use Visual Studio Code as Gits default editor没有的话选 Vim 就行反正日常提交信息你多半会在终端或 IDE 里写这个默认编辑器用得不多。后面的Adjusting your PATH environment是重点中的重点我单独放到第 3 节讲。再往后的Choosing HTTPS transport backend保持默认的 Use the native Windows Secure Channel library 就好这个选项决定了 Git 通过 HTTPS 连接远程仓库时用哪个底层库做 TLS 加密。选原生的 Secure Channel 能少踩很多证书相关的坑尤其在公司内网有自签证书的时候。最后有一个Configuring the line ending conversions行结束符转换也单独在第 3 节讲。装完后勾选 Launch Git Bash 打开终端先跑一句git --version能输出版本号说明安装成功。2.2 macOS 安装的两种方式对比macOS 用户分两派一派用官方 pkg一派用 Homebrew。官方 pkg 安装包从官网下载 dmg双击运行一路继续就行。装完同样在终端验证git --version。但这种方式有个小问题后续想升级得去官网重新下载有点麻烦。Homebrew 方式如果你已经装过 Homebrewbrew install git装完一样验证版本。我个人推荐这种方式因为升级太方便了brew upgrade git提示macOS 系统自带的 Git路径在/usr/bin/git版本通常比较旧有些还是被 Apple 修改过的版本。如果你发现问题或者命令行为异常优先用上述两种方式安装新版本并且在终端敲which git确认实际用的是哪个。2.3 Linux 的坑软件源版本太老Ubuntu/Debian 用户直接sudo apt update sudo apt install gitCentOS/RHEL 用户sudo yum install git但前面说过这里可能有个坑。Ubuntu 默认源里的 Git 版本不算新如果你对版本没有强需求够用就行。如果不够用就需要添加 Git 官方维护的 PPAsudo add-apt-repository ppa:git-core/ppa sudo apt update sudo apt install git编译源码这条路我不建议新手走构建依赖一堆出错了你还得排查编译错误没必要。2.4 装完第一件事验证三件套不管哪个平台装完都先跑这三条命令确认基础环境正常git --version git config --list which git第一条看版本第二条看配置是否被正确加载第三条确认 Git 可执行文件路径。如果git config --list报错或者输出为空多半是你的全局配置文件有问题先看后面第 4 节配置好用户名邮箱再说。3. 安装向导里那些让人纠结的选项到底选什么3.1 PATH 环境变量选第二个别选第一个这一项通常是三个选项Use Git from Git Bash only只能在 Git Bash 里用 Git 命令。Git from the command line and also from 3rd-party software在 CMD、PowerShell 和第三方软件里都能用。Use Git and optional Unix tools from the Command Prompt不仅把 Git 加入 PATH还把一堆 Unix 命令ls、cat、grep 等也放进 PATH。新手直接选第二个。原因很简单你后续大概率会在 VS Code、IDEA 这些编辑器里集成 Git它们的终端会调用系统的命令环境。如果选了第一个就会出现在 IDEA 终端里敲 git 提示不是内部或外部命令的问题。第三个选项为什么也不推荐它会把 Git 自带的 Unix 工具覆盖到系统里有可能跟你系统里已有的同类工具冲突尤其是 Windows 环境容易引发版本混乱。3.2 换行符转换选第二个相信我Windows 上安装向导会让你选 Line Ending Conversion这个选项影响深远我展开讲讲。Windows 系统的文件默认用 CRLF回车换行作为行尾而 Linux/macOS 默认用 LF。Git 为了避免仓库文件在跨平台协作时出现行尾混乱会自动转换行尾。三个选项分别是Checkout Windows-style, commit Unix-style line endings检出时转成 CRLF提交时转成 LF。适合 Windows 用户和 Windows 团队协作。Checkout as-is, commit Unix-style line endings检出时保持原样提交时转成 LF。这是 Git 官方推荐的默认行为。Checkout as-is, commit as-is什么都不转。我强烈建议选第二个。第一个看似对 Windows 友好但有一个经典坑你写了一个 shell 脚本.sh检出后被转成了 CRLF在 Windows 的 Git Bash 里执行可能报错而在 Linux 上又正常反之如果你在 Linux 上修好提交了Windows 这侧还是各种莫名其妙。选第二个能最大程度减少团队协作时的行尾问题。大部分 IDEVS Code、IDEA都有自动处理行尾的功能它们会尊重 Git 的配置。如果你已经装完了才发现行尾配置不对也不用重装一条命令改回来git config --global core.autocrlf true或者改成 false / input看你的实际场景。3.3 凭证管理器这是你免密的关键Windows 安装向导里默认会让你启用Git Credential Manager保持默认勾选就好。这个组件的作用是当你通过 HTTPS 方式克隆或者推送时Git 会记住你的账号密码或者 Token第一次输入后后续不用重复输相当于帮你做了安全缓存。很多人装完了 Git用 HTTPS 克隆 GitHub 仓库时每次都要输密码烦得很多半就是安装时把这个组件取消了。如果你已经装完且没有这个组件可以单独下载安装 Git Credential Manager或者手动设置 Helpergit config --global credential.helper managermacOS 用户如果用了 Homebrew 方式凭证缓存天然用的是 OSXKeychain基本无需额外配置Linux 用户可以配置credential.helper store实现明文存储不推荐或者用libsecret这类密钥环工具看系统环境。3.4 默认分支名建议直接选 main新版 Git 安装向导会让你选初始分支名master 还是 main。我建议直接选main。这已经是当前社区的主流默认值新建 GitHub 仓库的默认分支就是 main。选 master 不是不能用只是你在初始化和推送时总会碰到主分支叫啥的小差异徒增困惑。4. 装完先别急着用这些初始化配置省掉未来一堆麻烦4.1 设置用户名和邮箱必须全局配置我第一次给一个项目提交代码时Git 弹出的提交人信息是一串随机字符串吓得我以为环境出问题了。后来才知道Git 的提交记录里记录的作者名和邮箱取决于本机的 Git config跟你在哪个网站注册的账号名完全没关系。所以装完 Git 的第一件事设置全局用户名和邮箱git config --global user.name 你的名字 git config --global user.email 你的邮箱这里有个细节邮箱最好用你注册代码托管平台GitHub/GitLab/Gitee 等的那个邮箱这样你的提交记录才能正确关联到平台账号上。如果 GitHub 开启了邮箱隐私保护也可以在 GitHub 设置里找你那个users.noreply.github.com后缀的邮箱来配置。验证配置生效git config --global --list4.2 生成 SSH KeySSH 认证失败的源头很多人在热搜里搜SSH 认证失败 git十有八九是 SSH Key 没配好。SSH 和 HTTPS 是 Git 连接远程仓库的两种方式SSH 方式本身不需要输入用户名密码它靠一对密钥公钥 私钥来认证。你本机持有私钥远程平台存你的公钥连接时完成互相验证。生成密钥的命令如下ssh-keygen -t ed25519 -C 你的邮箱如果你在用比较老的系统可能不支持 ed25519 算法就用ssh-keygen -t rsa -b 4096 -C 你的邮箱执行后一路回车即可默认路径是~/.ssh/id_ed25519如果你想设密码保护私钥这里可以输入一个 passphrase不输也行。生成完会得到两个文件id_ed25519私钥留在本机绝不要泄露。id_ed25519.pub公钥把它的内容复制到 GitHub/GitLab 的 SSH Keys 设置里。查看公钥内容的命令cat ~/.ssh/id_ed25519.pub4.3 把公钥添到托管平台并验证连通性以 GitHub 为例登录 GitHub → 右上角头像 → Settings → SSH and GPG keys → New SSH key。把复制的公钥粘贴进去保存。然后本地执行ssh -T gitgithub.com如果你是第一次连接会提示确认 host key输入yes回车。如果配置成功会看到类似输出Hi 用户名! Youve successfully authenticated, but GitHub does not provide shell access.看到这句话才说明 SSH 认证这条路彻底通了。如果你用的是 GitLab、Gitee 这类平台验证命令里换成对应域名即可原理一模一样。4.4 其他值得顺手配上的全局设置下面几个配置不是必须但强烈建议配上都是我踩过坑后总结出来的# 提交时自动转换为 LF检出时不转换 git config --global core.autocrlf input # 开启颜色显示终端里看状态一目了然 git config --global color.ui auto # 默认使用 main 作为初始分支名 git config --global init.defaultBranch main # 设置常用的别名少敲很多字 git config --global alias.st status git config --global alias.co checkout git config --global alias.br branch git config --global alias.lg log --oneline --graph --all --decorate这些配置都写在~/.gitconfig文件里你也可以直接用编辑器打开这个文件查看和修改。配置完成后敲git lg能看到一个可视化的提交历史树那感觉比默认的git log舒服多了。5. 搜烂了的SSH 认证失败我把完整排查链路走一遍5.1 认证失败常见症状搜索引擎里搜SSH 认证失败 git通常对应这些报错gitgithub.com: Permission denied (publickey). fatal: Could not read from remote repository.或者ssh: connect to host github.com port 22: Connection timed out前一种是公钥认证失败后一种大概率是网络层问题内网封锁 22 端口、代理干扰等。5.2 一步步排查别上来就重建密钥第一次遇到这种问题我花了整整一个下午把所有可能的坑都踩了一遍。现在总结出一套排查顺序你按这个顺序来大概率十分钟内定位问题。第一步确认 SSH agent 里有没有你的私钥ssh-add -lWindows 用户在 Git Bash 里执行如果提示The agent has no identities.说明私钥没加载。先让 agent 知道你的私钥eval $(ssh-agent -s) ssh-add ~/.ssh/id_ed25519第二步确认公钥确实在远程平台上了重新打开~/.ssh/id_ed25519.pub复制全部内容去平台 SSH Keys 页面核对。这里有个容易被忽略的细节公钥复制的时候别手动敲、别用手机拍照识别的文本直接在本地用 cat 命令输出全选复制。公钥内容是一个很长的字符串结尾有邮箱任何一处字符错了认证都会失败。第三步用 verbose 模式看具体报错ssh -Tv gitgithub.com加了-v参数后终端会输出详细的连接过程。重点看两处debug1: Offering public key: ...这行说明本地正在尝试哪个公钥。debug1: Authentications that can continue: publickey这行说明服务端还在等你提供有效公钥。如果看到类似No such file or directory的提示说明 Git 找不到你的私钥文件检查 ~/.ssh 目录和文件名。如果没有任何 Offering public key 的输出说明 SSH 客户端根本没把你的私钥提供给服务器多半是 agent 没加载。第四步检查是不是端口被墙了如果你在公司网络或者某些特殊网络环境下访问 GitHub 时 22 端口大概率被干扰。GitHub 官方提供了解法通过 443 端口的 SSH 连接。在~/.ssh/config里加一段Host github.com Hostname ssh.github.com Port 443 User git保存后再执行ssh -T gitgithub.com验证。这个技巧我在多个网络场景下实测有效值得存下来。5.3 一个容易忽略的坑多个 SSH key 的冲突如果你电脑上同时配了 GitHub、GitLab、以及公司内部平台的多个 SSH key可能会遇到这个平台用哪个私钥的问题。Git 的规则是SSH 客户端会逐个尝试 agent 里的所有私钥直到某个私钥被服务器接受。这通常没问题但如果你的 GitHub 账号下绑定的公钥跟本地 agent 里的私钥对不上就会一直失败。解决办法是在~/.ssh/config里针对不同域名指定不同的私钥Host github.com HostName github.com User git IdentityFile ~/.ssh/id_ed25519_github Host gitlab.com HostName gitlab.com User git IdentityFile ~/.ssh/id_ed25519_gitlab这样就不会互相干扰了。5.4 验证成功的完整链路走完上述步骤最终ssh -T gitgithub.com输出成功提示再用 SSH 方式克隆一个仓库试试git clone gitgithub.com:用户名/仓库名.git正常拉取没报错说明 SSH 认证链路全通。之后push和pull都不需要输密码这才是 SSH 方式该有的体验。6. 装完 Git 后最高频的两个场景IDEA 拉取项目和分支合并6.1 IDEA 里创建新项目并拉取 Git 仓库热搜词里 IDEA 创建新项目拉取 git占了不小比重。这其实不是 Git 安装本身的问题但很多人装完 Git 之后第一件事就是打开 IDEA 拉项目所以我专门讲一下。在 IntelliJ IDEA 里拉取远程 Git 项目的标准操作是File → New → Project from Version Control然后在 URL 栏填入仓库地址。这里有一个关键前提IDEA 里需要配置你的 Git 可执行文件路径。打开 Settings → Version Control → Git检查 Path to Git executable 是否自动识别了 Git。如果填的是空的或者报红手动指向 Git 安装目录下的cmd/git.exeWindows。配置好后右侧的 Test 按钮会弹出版本号说明 IDEA 和 Git 的桥接已经正常。拉取项目时有两种 URL 填法HTTPS 方式https://github.com/用户名/仓库.git首次拉取会弹窗要求登录输入用户名和 Token。SSH 方式gitgithub.com:用户名/仓库.git前提是第 4 节的 SSH key 已经配置好。我的个人经验是能用 SSH 就用 SSH。HTTPS 方式第一次要输入账号密码或 Token虽然凭证管理器会记住但 Token 这玩意容易过期过期后 IDEA 又开始弹窗让你重新输入体验非常割裂。SSH 一次配置长期免密只要不清理~/.ssh目录基本一劳永逸。如果你在 IDEA 里拉取时提示 Authentication failed优先检查凭证File → Settings → Appearance Behavior → System Settings → Passwords看看 IDEA 的密码存储方式Windows 用户也可以打开控制面板 → 凭据管理器删掉旧的 Git 凭据重新输入。这类问题通常不是 IDEA 坏了是托管的凭据过期了。6.2 分支合并新手最容易慌的操作装好 Git 之后日常开发中最容易让人心理紧张的操作就是分支合并——怕冲突、怕覆盖、怕代码丢了。这里我不展开讲 Git Flow 的复杂模型就讲新手最快能上手的安全合并流程。典型场景你在feature/login分支上改了代码想合并回main或master。第一步先把目标分支切回去并更新到最新git checkout main git pull origin main第二步把功能分支并进来git merge feature/login如果没冲突Git 会自动完成合并并生成一个合并提交或者直接快进看你当前分支的提交历史是不是分叉了。如果有冲突Git 会列出冲突文件提示形如CONFLICT (content): Merge conflict in src/index.js Automatic merge failed; fix conflicts and then commit the result.这时打开冲突文件你会看到类似这样的标记 HEAD 这是 main 分支上的内容 这是 feature/login 分支上的内容 feature/login分隔线上面是当前分支main的内容下面是待合并分支的内容。你需要手工编辑这个文件保留想要的代码删掉 这些标记行然后git add src/index.js git commit -m 合并 feature/login 分支解决冲突这里我要强调一个很多人犯的错误合并冲突解决后不要急着 push。先本地跑一遍测试确认代码没问题再推。因为冲突解决过程中很容易手滑删错代码一旦 push 到远程影响的是整个团队。如果你合并到一半突然慌了想退回合并前的状态可以用git merge --abort这条命令会放弃当前合并回到合并前的状态代码不会丢。这是 Git 给每个人的后悔药关键时刻能救命。6.3 合并操作的安全垫提交前先建个分支我个人的习惯是在合并重要分支前先给当前分支打个标记或者建一个备份分支以防万一。比如你要把feature/login合到main里先在main上建一个备份分支git checkout main git checkout -b backup/2025-01-main-before-login git checkout main git merge feature/login这样即使合并出问题还能从backup/2025-01-main-before-login拉回来重来。虽然 Git 内部机制给了你操作日志git reflog这条保底路径但对新手来说显式的备份分支心理安全感强得多也更容易理解。7. 安装后的收尾与日常维护建议Git 不是装完就完事的工具它跟你的操作系统、IDE、托管平台一直在互相作用。结合我多年的使用经验列几条日常维护建议。建议一定期关注 Git 版本更新。Git 官方每隔几个月会发布新版本包含安全修复和性能改进。Windows 下官方安装包会让你自动检查更新Linux 下用 PPA 的可以定期sudo apt update sudo apt upgrade git来升级macOS 下 Homebrew 用户一条brew upgrade git搞定。建议二遇到诡异问题先看 config。很多时候Git 行为怪异不是 Git 坏了而是某个配置项被改过。排查命令git config --list --show-origin这条命令会显示每个配置项来自哪个文件系统级、全局级、仓库级你能清楚地看到是哪一层配置影响了你。如果还不放心可以分级查看git config --system --list git config --global --list git config --local --list建议三注意.gitconfig中的 alias 别乱加。alias 虽然方便但团队协作时如果某个机器上没配 alias而你把 alias 写在提交说明或文档里别人跑起来就是命令不存在。所以 alias 可以加但在文档和教程里尽量写全命令。建议四给 GitHub 添加 SSH key 后最好同时在本地配置好 host key 的 known_hosts。第一次 SSH 连接时 Git 会提示你确认指纹输入yes后会自动写入~/.ssh/known_hosts。如果你在无人值守的脚本环境里可能需要提前用ssh-keyscan导入ssh-keyscan github.com ~/.ssh/known_hosts不然脚本里第一次连接会因为 non-interactive 模式下无法确认而失败。建议五Windows 用户建议搭配 Windows Terminal 使用。装完 Git 虽然自带了 Git Bash但说实话窗口丑、复制粘贴也不顺手。Windows Terminal 配合 Git Bash 的组合体验能提升一大截——多标签、快捷键复制粘贴、自定义主题都支持。设置方法很简单Windows Terminal 设置里添加一个新的配置文件命令行指向 Git 安装目录下的bin/bash.exe启动参数加--login即可。行文至此核心的安装、配置、认证、常见操作都覆盖到了。最后分享一个我自己的心得安装 Git 这件事本质上不是把程序装进电脑而是搭好了一条本地代码 ↔ 远程仓库的稳定通道。通道断了多数时候不是 Git 的错而是某一环配置没对上。你只要把第 3 节的安装选项、第 4 节的初始化配置、第 5 节的 SSH 排查链路这三样东西吃透Git 环境层面的问题就已经解决了九成。剩下的就是多用多用多用遇到报错先读日志再动手改配置。