Git从入门到入门：安装配置与SSH免密推送实战

写代码这么多年，隔三差五就会遇到新人同事问我：Git到底怎么装、怎么才能把代码推到远端仓库。说实话，这个问题看起来简单，但涉及的东西其实不少——光是安装过程中的选项、换行符设置、远端链接走HTTPS还是SSH，每一样都能让一个刚接触Git的人卡上半天。标题叫“从入门到入门”，想表达的就是：别怕，这篇文章不装高深，把最基础的两件事——安装在本地、连接远端——讲清楚，让你看完就能动手把代码推上仓库。

这篇文章适合完全没接触过Git的纯新手，也适合那些已经装了Git但配置总是半懂不懂、clone和push频繁报错的人。我不打算讲什么高级命令，那些花里胡哨的 rebase、cherry-pick，等你真正上手之后再学也不迟。核心就两件事：让Git在你的电脑上好好活着，让它跟远端仓库顺利握手。

1. 动手之前：先搞清楚Git装来干什么

很多教程上来就让你下载、下一步、下一步，装完了却不知道Git到底是什么，更不知道它怎么帮你干活。这是我认为大多数Git新手最大的问题——不是命令记不住，而是脑子里没有一个清晰的工作模型。

1.1 没有版本管理时的日常混乱

你可以先回忆一下，没有Git之前你是怎么存文件的。最常见的操作是：论文终版.doc、论文最终版v2.doc、论文最终版v3改.doc、论文真的不改了.doc……如果合作的人再多一点，还会出现最终版_小明改.doc、最终版_小明改_小红再改.doc这种名字。

代码一模一样。没有版本管理的时候，你会把整个项目文件夹复制一份，改个带日期的名字，扔在桌面或者网盘上。问题在于：时间一长，你根本分不清哪个文件夹是最新的；哪怕好不容易记住了，万一改坏了想回退，只能凭记忆手动撤销，效率极低。

Git就是来解决这件事的。它是一个分布式的版本控制系统，追踪你的每一次文件变化，让你随时可以回到历史中的任意版本，还能让多个人同时在一个项目上工作，不必在网盘里互相覆盖文件。

1.2 Git是怎么记录变化的

用一个生活化的类比：Git就像你的代码备份日记。你每一次完成一段工作，喊一声“记下来”，Git就在日记里写一条：今天给首页加了导航栏，改了哪几个文件、每个文件变化了什么。之后任何时候翻日记，都能看到那天的状态，并且可以一键回去。

但和普通日记不同的是，Git的“记录”是分布式的——你电脑上有一个完整的仓库副本，别人电脑上也有。你们各自干活、各自记录，之后再把记录合并到一起。这也是Git和SVN这类集中式版本管理工具最大的区别：不用每次提交都连服务器，断网也能干活。

1.3 “从入门到入门”这句话的真正含义

“从入门到入门”这个名字，一方面是调侃网上各种“从入门到放弃”的梗，另一方面是我真实的体验：Git这个工具，你用一天可以在命令行push代码，你用一年可能还是只会那几个基本命令，这不奇怪，也完全够用。它不像编程语言需要系统学习，更像骑自行车——会了之后基本忘不掉，但大多数人也就只会往前骑。

所以你不需要有压力。安装、配置、连接远端，这三步走完，就已经超过了大半个“会用Git”的门槛。剩下的都是在具体场景里慢慢积累的。

2. Windows下安装Git的完整操作与三个易错选项

虽然macOS和Linux安装Git也很快，但我发现身边的初学者八成用的是Windows，所以这一节我重点讲Windows的完整安装过程。macOS和Linux用户我放在后面简单补充。

2.1 下载安装包：版本与位数选择

去Git官网git-scm.com，首页就能看到下载按钮，它会自动识别你的系统。如果你是Windows，一般会看到两个版本：64-bit和32-bit。现在的电脑几乎都是64位，直接选64-bit就好。

下载之后双击安装包，一路默认其实也能用。但只点“下一步”的话，会在一些关键选项上留下隐患，后面用起来很容易遇到莫名其妙的报错。我曾经见过一个同事，安装时一路默认，结果Git装完后在普通的cmd里输入git完全没反应，因为他跳过了PATH配置的步骤，Git只装到了自己的目录里，系统压根找不到这个程序。

所以下面这三个选项，我建议你稍微停下来认真看一眼。

2.2 安装过程中最关键的三个选择项

第一个必看的选项：Adjusting your PATH environment（调整PATH环境）。

这一步在安装向导的中间部分，默认选的是中间项“Git from the command line and also from 3rd-party software”。它的意思是：在cmd、PowerShell以及第三方软件里都能直接调用git命令。千万不要改选第一项“Use Git and optional Unix tools from the Command Prompt”，除非你确切知道自己要干什么，否则它会引起一些命令冲突。就保持默认，这个选项最稳。

第二个必看的选项：Choosing the default editor（选择默认编辑器）。

Git有时候需要你输入一段提交说明，会自动弹出编辑器。默认是vim，但对新手来说vim的操作逻辑太不友好了——进去之后按了半天没反应，最后不知道怎么退出，只能强制关窗口。选了vim本身不是错，但如果你从没接触过vim，建议在这一步直接选“Use Visual Studio Code as Git's default editor”（下拉列表里选），或者选Notepad++也行。如果你机器上没装VS Code，那就先用默认的vim，等到提交的时候遇到编辑器卡住，再装个VS Code回来配置也不迟。

第三个容易被忽视的选项：Adjusting the name of the initial branch in new repositories（新仓库初始分支名）。

新版Git安装向导会问你想让新仓库的默认分支叫什么。默认是“master”，你可以改成“main”，也可以不改。纠结这个的人不少，但核心只有一点：和你团队的远端仓库保持一致。如果你用GitHub或Gitee新建仓库，远端默认分支就叫main，那你本地也用main，之后push的时候省去很多头晕的分支名不匹配问题。建议这里直接选main，理由后面实操部分会再遇到。

2.3 安装验证与Git Bash的正确打开方式

安装完成后，在桌面空白处点击鼠标右键，菜单里会出现“Git Bash Here”和“Git GUI Here”两个选项。Git Bash是Git自带的终端环境，它的意义不只是能敲git命令，而是模拟了一个Linux风格的Shell环境，让你在Windows上也能用ls、pwd这些命令，路径格式也是斜杠风格，对新手来说其实比cmd更直观。

验证安装是否成功：打开Git Bash，输入：

bash复制git --version

如果看到类似git version 2.40.0的输出，说明安装成功。如果提示command not found，大概率是上面PATH那步没选对，重新运行安装包，把PATH改回中间那个选项，覆盖安装一次就好。

macOS用户装Git简单很多：装了Homebrew的话，brew install git一条命令搞定；没装Homebrew就直接去官网下pkg安装包。Linux用户更不用说，sudo apt install git（Debian/Ubuntu）或者sudo dnf install git（Fedora）就行。装完同样用git --version验证。

3. 打开终端的第一步：全局配置与换行符

安装完成只是第一步。Git装好后就像一个不认识你的新同事，你得先告诉它你是谁，它才好在每次提交时帮你署名。同时还要处理一个Windows用户极容易踩的坑——换行符问题。

3.1 user.name和user.email为什么必须配置

Git每一次提交，都会记录一个提交者名字和邮箱。如果你没配，Git会报错：

bash复制*** Please tell me who you are.

这个错误我见过太多次了。配置方法很简单，在Git Bash里运行：

bash复制git config --global user.name "你的名字"
git config --global user.email "你的邮箱"

这里的“你的名字”和“你的邮箱”不一定要和代码托管平台（比如GitHub、Gitee）的账号完全一致，但强烈建议保持一致。因为提交记录里的名字和邮箱会作为作者信息一起推到远端仓库，团队协作时，别人需要通过这个信息知道某行代码是谁写的。

--global的意思是全局生效，也就是你这台电脑上所有的Git仓库都会用这个身份。如果你某一项目想用另一个身份，可以不带--global，在项目目录里单独配置：

bash复制git config user.name "另一个名字"
git config user.email "另一个邮箱"

这种局部配置会覆盖全局配置。原理很简单：Git会按“项目级 > 全局级 > 系统级”的优先级读取配置，项目目录下的.git/config文件优先于~/.gitconfig文件。

3.2 CRLF与LF：Windows用户最容易忽略的坑

这个坑几乎是Windows新手必踩，而且踩完根本看不懂报错。先讲点背景：

• Windows系统里的文本文件，换行符是\r\n（回车+换行，缩写CRLF）
• Linux和macOS系统里的文本文件，换行符是\n（换行，缩写LF）

Git存储代码时，内部默认使用LF作为换行符。如果你在Windows上写代码，文件里全是CRLF，git提交的时候如果不做转换，仓库里就会出现大量CRLF符号，后续diff、合并都可能出问题。更烦人的是，如果一个团队里有人用Windows有人用macOS，同一行代码的换行符不统一，Git会认为整个文件（或者整个文件的部分行）都发生了变化，于是代码改动记录里会莫名其妙多出几十行列变更。

安装Git时，那个“Line Ending Conversions（换行符转换）”选项就是解决这个问题的：

• 选第一个“Checkout Windows-style, commit Unix-style line endings”：检出代码时自动把LF转成CRLF，提交时自动把CRLF转回LF。这是Windows用户最推荐的选择，也是大多数教程建议的选择。
• 选第二个“Checkout as-is, commit as-is”：不做任何换行符转换。这是macOS/Linux用户的常见选择。
• 选第三个“Checkout as-is, commit Unix-style line endings”：检出时保持原样，提交时统一转成LF。

对Windows用户来说，选第一个就行。如果你的项目已经建好了，没选对怎么办？也可以在命令行里手动设置：

bash复制git config --global core.autocrlf true

不过说实话，从长期维护的角度看，我更推荐在项目根目录放一个.gitattributes文件来统一规范换行符，比如：

text复制* text=auto
*.bat text eol=crlf
*.sh text eol=lf

这样团队所有人无论用什么系统，Git都会按文件类型自动处理换行符，其他人clone下来也不会因为换行符差异导致diff爆掉。.gitattributes是跟着仓库走的，比每个开发者自己配core.autocrlf靠谱得多，因为这相当于把规则写进了项目里，交给Git强制执行。

3.3 检查配置是否生效

配置完之后，可以用下面的命令查看当前所有配置：

bash复制git config --list

如果只想看某个单项：

bash复制git config user.name
git config user.email
git config core.autocrlf

这是一个很好的习惯——每次到一台新电脑、装完Git之后，先跑一遍这三个检查命令，确认身份和换行符都符合预期，再开始正式干活。很多莫名其妙的提交信息问题，本质上就是配置没检查导致的。

4. 远端链接的核心概念：本地仓库和远端仓库是怎么接上的

装好Git、配好身份，接下来就是重头戏——远端链接。很多人听到“远端链接”四个字就紧张，觉得是什么高大上的网络配置，其实它做的事情很简单：把你电脑上的Git仓库和服务器上的Git仓库之间建立一条路，之后你写的代码就能推上去，别人改的代码也能拉下来。

4.1 先理解remote对你意味着什么

“远端”在Git里的官方术语叫remote，中文常翻译成“远程仓库”。你可以在代码托管平台（比如GitHub、Gitee）上创建一个空仓库，然后把本地的代码推上去；也可以先从远端clone一个项目到本地，然后在这基础上工作，改完再推回去。

不管哪种方式，本地Git仓库都只是你电脑上的一个目录，里面有一个隐藏的.git文件夹，这个文件夹里保存了这个仓库的全部历史记录。它本身是完全独立的——在没有接到网络的世界里也能正常提交代码。

remote就是给本地仓库加了一个“远端地址”的标签。默认情况下，你克隆下来的项目，远端叫origin，指向你clone时的那个仓库地址。你自己新建的仓库，可以手动添加一个origin。

理解这一点很重要：origin不是什么神秘魔法，就是一个自定义的远程仓库名。你可以叫它origin、myrepo、甚至gitee，都行，只是行业惯例默认叫origin。所以不用怕理解错，它是完全掌控在你手里的一个名称。

4.2 HTTPS与SSH：两种连接方式的区别

添加远端仓库时，你会面对两个不同的协议选择：HTTPS和SSH。这是新手最常见的困惑点。

HTTPS方式很简单直接，远程仓库地址长这样：

text复制https://github.com/你的用户名/仓库名.git

使用HTTPS push时，每次都会要求你输入用户名和密码（或者说令牌token）。操作逻辑符合直觉，普通Web访问式的体验，对新手来说比较友好。缺点是频繁输密码，虽然可以通过Windows凭据管理器记住密码，但偶尔还是会遇到奇怪的卡顿。

SSH方式则是用加密密钥来验证身份。远程仓库地址长这样：

text复制git@gitee.com:你的用户名/仓库名.git

SSH的本质是配置一对密钥：私钥放在你电脑本地，公钥上传到代码托管平台。之后push/pull时不需要输入任何密码，Git自动用私钥完成身份验证。只认证一次，之后彻底免密，这是长期开发最推荐的方式。

我从一开始就建议你直接用SSH，虽然配置密钥的过程多几步，但换来的是以后所有操作都畅通无阻。HTTPS更适合偶尔用一下别人给的仓库链接、临时下载一份代码的情况。

4.3 添加远端仓库地址的标准命令

我先给你一个生成HTTPS远端链接的完整流程，让你对整体有一个感官认识，后面第5节再深入讲SSH的配置。

在本地项目目录里打开Git Bash（右键项目文件夹，选“Git Bash Here”），然后：

bash复制# 在项目目录里初始化一个Git仓库
git init

# 查看当前仓库状态
git status

# 把当前目录下所有文件加入暂存区
git add .

# 提交一次快照
git commit -m "first commit"

# 添加远端仓库地址
git remote add origin https://github.com/你的用户名/仓库名.git

# 把本地代码推送到远端
git push -u origin main

这几条命令把“从零创建仓库到推上远端”的整个链路串起来了。这里-u参数的意思是：把本地当前的main分支和远端origin的main分支建立关联，之后你直接运行git push，Git就知道你要推到origin的main去，不用每次都写完整命令。

这里要特别提醒一件事：你本地初始化的仓库，默认分支名取决于安装Git时的设置（第2.2节里提过的那个选项）。如果你本地分支叫master，而远端仓库默认分支叫main，push时会遇到分支不匹配的问题。所以我才建议安装Git时就把默认分支名改成main，从源头上规避这个坑。

5. 免密链接实战：SSH Key的生成、添加与验证

现在进入本文最核心、也最实用的部分——配置SSH Key，实现免密链接。配置好一次，终身受用，不管是每天push代码，还是clone别人的私有仓库，都不会再被密码拦截。

5.1 为什么SSH Key比输密码靠谱

原理是这样的：SSH Key是一对非对称加密的密钥，一个公钥一个私钥。公钥可以公开，它是一串很长的字符；私钥绝对不能泄露，它保存在你电脑的~/.ssh/id_ed25519文件里。

你把公钥添加到代码托管平台的设置页面，Git验证身份时，平台会用公钥加密一段内容发送到你电脑上，你的电脑用私钥解密并返回确认信息。私钥从来没有通过网络传输，所以安全性远高于明文密码。这就像一个专用的门禁卡，刷一次之后门就开了，不用每次进办公室都登记一次。

5.2 生成密钥并添加到托管平台

生成密钥的命令是：

bash复制ssh-keygen -t ed25519 -C "你的邮箱@example.com"

执行后，终端会问你要把密钥保存在哪里（默认是~/.ssh/id_ed25519），直接回车；然后会问你设置一个口令（passphrase），这一步可以留空直接回车两次。注意：留空的含义是你的私钥文件没有密码保护，一旦私钥泄露，别人可以直接使用你的身份。如果你不放心，也可以设置一个口令，但这样每次用SSH操作时还要再输一次口令，失去了免密的意义。权衡之下，我本人在开发机上是不设口令的，但在高风险的环境（如服务器）上一定会设。这个题你根据自己的安全需求来选就行。

生成之后，查看公钥内容：

bash复制cat ~/.ssh/id_ed25519.pub

终端会输出一行以ssh-ed25519开头的长字符串，这就是公钥。复制整行内容，打开你的代码托管平台，找到“设置”→“SSH公钥”或“SSH Keys”，起一个名字（比如“my-windows-laptop”），把公钥粘贴进去保存即可。

5.3 测试连接和第一次push：完整流程串起来

配置好公钥之后，先用这个命令测试一下连接是否正常：

bash复制ssh -T git@gitee.com

如果你用的是GitHub，就改成：

bash复制ssh -T git@github.com

第一次连接时，终端会提示你是否信任该主机，输入yes回车即可。如果看到类似“Hi 用户名! You've successfully authenticated”的提示，说明SSH配置成功。

然后开始完整的免密push流程：

bash复制# 先新建一个项目目录，进入目录
git init

# 创建你的第一个文件，比如 index.html
touch index.html

# 查看状态
git status

# 加入暂存区
git add index.html

# 提交
git commit -m "init project"

# 确保分支名是main（也可以重命名分支）
git branch -M main

# 添加SSH远端地址（注意是git@开头，不是https://）
git remote add origin git@gitee.com:你的用户名/你的仓库名.git

# 推送到远端
git push -u origin main

到这里，你已经完成了一次零密码的push操作。之后每一次修改代码，只需要三步：git add .、git commit -m "本次改了啥"、git push。整个过程不会再要任何密码，非常舒服。

5.4 推送失败时的排查思路

push遇到失败是最常见的事，但别慌，绝大多数情况下问题出在下面几个位置：

1. 认证失败：报错Permission denied (publickey)。先别急着怀疑别的，大概率是公钥没添加成功，或者添加到了错误的账号下。可以用ssh -T git@gitee.com测试，如果显示能通过认证，那就是仓库地址有问题；如果认证失败，回头检查公钥是否完整粘贴（往往少了开头或结尾的字符），或者确认你粘贴的平台账号是不是你实际要用的那个。

2. 仓库不存在：报错Repository not found。检查一下仓库地址是否拼错、仓库名大小写是否完全一致，以及你的账号是否对该仓库有写入权限。私有仓库尤其容易漏——“你没权限”和“仓库不存在”对Git来说很多时候是同一个意思。

3. 远端已有提交：报错! [rejected]或failed to push some refs。这是因为远端仓库里已经有代码，而你的本地没有这些提交。解决方法是先git pull拉取远端变更，合并后再push。注意pull之前最好先把本地提交处理完，否则容易产生冲突，冲突的处理一会儿会讲。

4. 无法解析主机名或连接超时：这个就涉及网络环境了，一般检查代理设置或网络连接即可，属于环境问题，不是Git本身的问题。

6. 连接远端之后一定会碰到的几个坑

最后这部分是经验总结，也是我踩过无数次坑之后浓缩出来的笔记。讲几个连接远端之后最常遇到的场景，以及对应的处理思路。

6.1 常见报错对照表

先给你一张速查表，建议收藏：

这张表不能代替理解，但能在你卡住的时候快速定位问题方向。记住一个原则：Git的大部分报错信息都是带明确提示的，读一读英文，再对照下当前命令的上下文，通常自己就能找到答案。

6.2 分支名不匹配导致的推送失败

这个坑我在第2.2节和第4.3节都提醒过，但因为它真的太常见了，值得单独拿出来再讲一遍。

假设你在本地初始化的仓库，默认分支叫master，而你在Gitee或GitHub新建仓库时，平台默认给你创建了一个main分支（或者反过来的情况），那么执行git push时，Git会发现本地分支和远端分支没有关联，报错让你指定具体推到哪个分支。

解决办法很简单：

bash复制git branch -M main

-M会把当前分支重命名为main（如果main已存在则强制覆盖它的引用）。执行完之后再push：

bash复制git push -u origin main

从本质上看，这是Git对分支名的强校验——本地分支名和远端分支名必须建立明确的对应关系，不能想当然。这也是为什么我一直建议安装时就把默认分支改成main：少踩一个坑，多省五分钟。

6.3 文件冲突的根本原因与处理思路

冲突是Git里最让人头疼的词。我第一次遇到冲突时，看着文件里满屏的<<<<<<<、=======、>>>>>>>，第一反应是代码被弄坏了。实际上不是，冲突是个正常反馈：Git在合并时发现，两个不同的人改了同一个文件的同一段内容，它不知道怎么选，就把麻烦留给人类。

发生冲突之后，Git会告诉你：CONFLICT (content): Merge conflict in index.html。用编辑器打开那个文件，你会看到类似这样的内容：

text复制<<<<<<< HEAD
你的本地改动
=======
远端的改动
>>>>>>> origin/main

你需要手动决定保留哪一部分、或者把两段都保留、或者改成一个合并后的版本，然后把<<<<<<<、=======、>>>>>>>这些标记行删掉，重新git add和git commit即可。

我的经验是：解决冲突时无论多急，都先看清楚两部分各自是什么，再动手改。不要看到有>>>>>>>标记就直接全删掉，也不要为了省事把别人的改动整个丢掉。同一段代码两个人同时改，往往意味着你们对这段逻辑的安排可能产生分歧，多看两步比事后debug性价比高得多。

如果冲突发生在push之前，通常流程是：

bash复制git pull
# 出现冲突，手动解决
git add .
git commit -m "merge and resolve conflicts"
git push

这个流程要反复练习几次才踏实。不要害怕冲突，它只是Git在提醒你“这里需要人的判断”，远没有网络上传言的那么可怕。

另外补充一个非常实用的经验：提交信息一定要写得清楚明白。很多新人习惯写update、123这种毫无信息量的提交说明，过一个月再回头看，完全不知道当时改了什么。这不是形式主义，而是你过一阵子需要回退历史时唯一的路标。建议提交信息用下面这个简洁格式：

text复制<type>(<scope>): <subject>

例如：
feat(login): 添加登录验证功能
fix(header): 修复导航栏在小屏幕下错位的问题
docs(readme): 补充安装说明

常见type有feat（新功能）、fix（修复Bug）、docs（文档）、style（代码格式）、refactor（重构）、test（测试）。这套规范不强制，但真的能救你一命，尤其是项目大了之后。

最后再分享一个我压箱底的小习惯：每次新建一个项目，我会先创建一份.gitignore文件，把node_modules、target、.env、*.log这类内容排除在Git追踪之外。不然哪天手滑把依赖包或者包含密码的配置文件推到远端，轻则仓库体积膨胀，重则泄露敏感信息，处理起来相当痛苦。具体需要排除哪些内容，不同语言有通用模板，GitHub上就有官方整理好的示例，直接搜.gitignore 模板就能找到，拿过来改一改再用，比自己从零写稳妥多了。

Git就是这样——入门不难，难的是刚开始总踩坑。我希望这篇文章能帮你在安装和远端链接这最难迈的第一步上走得稳一点。装好、配好、推上去，你已经超过了很多人。剩下的路，就靠一句句git commit和一次次git push慢慢走出来了。