机智的娜娜装了又好像没装，是很多人第一次接触Git的真实状态。下载、双击、Next点完，然后打开命令行敲一句git --version，看到版本号出来了，教程就结束了。可真正上手时，发现连推个代码到Gitee都要鼓捣半天，要么提示权限拒绝，要么分不清本地仓库和远程仓库到底怎么关联的，到最后干脆退回压缩包发文件。
这篇就是冲着“一篇解决”来的，目标很明确：用Windows系统，从零开始装好Git，配好Gitee远程仓库，把本地代码推上去，再把日常最常用的命令和撤销、回滚、免密、托管这些高频问题一次讲透。适合刚入门的学生、工作中需要自己搭代码管理的开发者，还有那些只用过SVN、想换Git但被命令行劝退的朋友。
1. 装之前先搞清楚：Git和Gitee到底是怎么配合的
很多人一开始就被“Git”和“Gitee”的概念绕晕。简单说，Git是本地跑的一个版本管理工具，负责记录代码的每一次改动、支持分支、支持回滚；Gitee是码云上的一个远程代码托管平台，相当于把你本地的仓库“备份”到云端，还能和别人协作。
这两个东西的关系，可以拿写文档来打比方。Git是你的本地草稿箱和修改记录仪，每次保存都会留下痕迹，随时能翻回前面的版本；Gitee是你上传到云文档的公共副本，解决了两件事：一是电脑坏了代码不丢，二是别人想参与你的文档，不用在微信上传来传去，直接从云文档拉下来改完再传回去就好。
理解这层关系很重要，因为后面所有操作都围绕两条线索展开：
- 本地通过Git把代码提交到本地仓库（
commit） - 再把本地仓库推送到远程Gitee仓库（
push）
反过来，别人或者另一台电脑改过代码，你需要先拉取远程的更新（pull），再合并到自己的代码里。
这套流程跑通之后，你会形成肌肉记忆：改代码、提交、推送，晚上下班前顺手推一把。至于分支管理、合并冲突、多人协作，都是建立在这套基础之上的进阶能力。
开始之前，顺手检查下系统环境。Windows版本建议Win10及以上，Win7老系统虽然也能装老版本Git，但Gitee的某些接口和SSL协议对老环境兼容性越来越差，别在这个环节浪费精时。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Windows端安装Git：下载、安装选项、验证三步走
2.1 下载版本怎么选
Git官方专门维护了Windows版本，项目名叫Git for Windows，直接访问官网下载即可。注意区分两个版本：
- 64-bit Git for Windows Setup：绝大多数现代电脑选这个
- 32-bit Git for Windows Setup：只有旧电脑、内存小于4G的才需要
下载时认准Standalone Installer（独立安装包），不要下载Portable版。Portable版是免安装的便携版，适合装在U盘里临时用，日常开发还是老老实实装系统版，右键菜单、文件关联、环境变量都自动配好，省心得多。
下载速度如果提不上去，可以考虑用国内镜像站下载，版本同步基本是实时的。我习惯直接用镜像，一分钟内就能拿到安装包。
2.2 安装选项里哪些该勾，哪些要改
安装包是标准的Next式向导，大部分选项保持默认即可，但有几步值得多看一眼：
第一处是“Select Components”，默认勾选了Git Bash Here和Git GUI Here，这两个建议保留。它会在右键菜单里加上“Open Git Bash here”，在文件夹里直接打开命令行，做本地操作极其方便。别把它取消，这是很多人用Git最顺手的一个入口。
第二处是“Choosing the default editor”，默认是Vim。老手无所谓，但新手在提交代码时万一触发Vim界面，会卡在“怎么退出”的绝望里。直接在选项框里选Nano，或者选VS Code（前提是装了）都可以。我个人推荐选VS Code，因为提交信息编辑、代码冲突解决都更图形化，适合所有人。
第三处是“Adjusting the PATH environment”，默认选项是“Git from the command line and also from 3rd-party software”，保留这个。它会把Git自动加进系统PATH，让你在CMD、PowerShell、VS Code终端里都能直接用git命令。
第四处是“Choosing the SSH executable”，默认是“Use OpenSSH”，不要改成“Use Bundled OpenSSH”。Windows自带的OpenSSH和Gitee配合得很稳，这里动一下反而容易出怪问题。
后面还有“Checkout line endings”“Choose terminal emulator”等选项，全部保持默认即可。前者Windows默认按CRLF转换，实际用下来团队之间配合没出过问题；后者默认Windows Console即可，如果是新版Git for Windows默认是MinTTY，也问题不大。
2.3 安装完的验证动作
装完之后，立刻验证。快捷键Win + R输入cmd回车，或者直接右键桌面打开终端，输入：
bash复制git --version
能输出版本号如git version 2.44.0.windows.1，就说明安装成功、环境变量也没问题。
顺手再配一个高频验证命令，看当前用户信息是否被正确识别：
bash复制git config --global --list
此刻还没配置，应该没有任何输出，或者只显示系统级参数，这是正常的，下一步就来配它。
注意：安装完Git后，某些老进程里可能还没刷新环境变量。如果明明装了却提示
git不是内部或外部命令，关掉当前CMD重新开一个即可。
3. 初始化配置与SSH免密登录：git config和密钥那些事
3.1 为什么必须先配置user.name和user.email
很多人直接跳过这一步，结果推送代码的时候就蒙了。Git每次提交代码，都会在提交记录里记录“谁在什么时候做了什么修改”。这个身份信息不是从系统用户名里自动读的，必须手动配置。
在终端里执行下面两条命令，替换成自己的信息：
bash复制git config --global user.name "yourname"
git config --global user.email "youremail@example.com"
--global的意思是对当前Windows用户全局生效，之后这台电脑上所有仓库都默认用这个身份。如果某个项目想用不同的身份（比如工作和私人分开），可以去掉--global，在项目目录下单独设置。
邮箱建议用Gitee注册时用的邮箱，这样Gitee后台能识别出提交者对应的是哪个账号，贡献度、动态展示才会正常。
3.2 SSH密钥的生成流程
Gitee支持两种远程访问方式：HTTPS和SSH。HTTPS每次推送都要输用户名密码，虽然可以通过Windows凭据管理器缓存，但SSH才是用起来最顺的方式，配置一次永久免密。Gitee对这两种方式的详细说明在README里讲得也很清楚，但这里把实操路径给你梳理通。
打开Git Bash，执行：
bash复制ssh-keygen -t ed25519 -C "youremail@example.com"
这里用的是ed25519算法，比传统的rsa 2048更短更安全，GitHub、Gitee都支持。执行后会有三次提示：
- 第一个是问保存路径，默认
~/.ssh/id_ed25519，直接回车 - 第二个是设置密钥密码短语，直接回车留空即可，否则每次用密钥都要输一次密码，反而违背了免密初衷
命令跑完，会在C:\Users\你的用户名\.ssh\下生成两个文件：id_ed25519是私钥，绝不能外泄；id_ed25519.pub是公钥，需要贴到Gitee上。
查看公钥内容：
bash复制cat ~/.ssh/id_ed25519.pub
输出结果是一行以ssh-ed25519开头、以你邮箱结尾的字符串，把它完整复制。
3.3 在Gitee上添加公钥
登录Gitee，右上角头像下拉菜单找到“设置”，左侧菜单进入“SSH公钥”。标题随便填，比如“我的Windows电脑”，公钥框粘贴刚复制的内容，提示文字里Gitee给出了详细的公钥生成方法，可以对照确认，然后确认添加。
比HTTPS方式舒服的地方在于，SSH公钥添加完成后，整个推送拉取过程完全不需要再输入口令，而且比HTTPS方式更稳定，不容易因为网络代理或密码策略问题导致推送失败。
3.4 验证SSH连接是否打通
配置完别急着推代码，先验证连通性：
bash复制ssh -T git@gitee.com
第一次连接会提示确认密钥指纹，输入yes回车。如果配置成功，会返回类似“Hi xxx! You've successfully authenticated, but GITEE.COM does not provide shell access.”的信息，看到这句话就安心了，SSH通道已经打通。
有个小坑提醒一下：如果你电脑上之前装过其他Git客户端，或者用过其他工具生成过SSH密钥，~/.ssh/目录下可能已有多个密钥文件。SSH默认会按顺序尝试加载，如果第一个私钥匹配不上Gitee，后面容易出错。排查方式是在验证前先跑：
bash复制ssh-add -l
如果列出了多个密钥，而验证失败，可以通过~/.ssh/config文件指定使用哪个私钥，或者把无关密钥移出目录。
4. 本地代码推到Gitee：两种路径的完整操作流程
4.1 路径一：本地已有代码项目，推到新建的Gitee仓库
这是最常用的场景。假设你本地有个项目文件夹叫my-project，里面已经有了代码，现在想把它托管到Gitee。
第一步，在Gitee上新建仓库。右上角“+”号选择“新建仓库”，仓库名称填项目名，比如my-project。开源许可证和说明文件可以留空，因为本地已经有项目了，如果勾选了“初始化仓库”反而会造成后面合并冲突。路径走通之后再补README、.gitignore这些是更稳的节奏。
第二步，在本地项目目录里打开Git Bash，初始化本地仓库：
bash复制git init
这个命令会创建一个隐藏的.git目录，Git的所有版本信息都存在这里面。注意：一个项目只能有一个本地Git仓库，不要在一个大文件夹下乱git init，否则层级关系会很混乱。
第三步，把所有文件加入暂存区，并提交到本地仓库：
bash复制git add .
git commit -m "init project"
git add .会把当前目录下所有文件加入暂存区，也就是“告诉Git这些文件我要开始跟踪了”。然后commit把暂存区内容正式提交，-m后面写提交说明。
此时如果执行git status，会提示“nothing to commit, working tree clean”，说明本地仓库已有了第一次完整快照。
第四步，关联远程仓库地址：
bash复制git remote add origin git@gitee.com:你的用户名/my-project.git
地址在Gitee仓库页面的“克隆/下载”按钮里可以复制，务必选SSH协议的地址，不要选HTTPS。origin是Git约定的默认远程仓库别名，可以理解为“给远程仓库起的名字”，后续推送拉取都通过这个别名引用。
第五步，推送：
bash复制git push -u origin master
这里注意分支名。Gitee新建仓库时默认分支推荐设为master还是main，看你建仓时怎么填的。如果本地分支名和远程默认分支名不一致，推送时会报错或者推到了不同的分支，最好提前在仓库设置里把默认分支名统一。
-u参数的作用是建立本地分支和远程分支的追踪关系，之后直接执行git push就可以，不用再带参数了。
提示：如果项目里包含
node_modules、target、bin这类生成目录，推上去会让仓库体积爆炸。正确的做法是创建.gitignore文件，把这些目录排除掉。.gitignore的具体写法后面单独讲。
4.2 路径二：先在Gitee建仓库，再从空目录克隆到本地
如果你打算从零开始一个新项目，更推荐倒过来操作：
在Gitee上新建仓库，这次可以勾选“使用Readme文件初始化这个仓库”，顺便选好开源许可证。
然后本地执行克隆：
bash复制git clone git@gitee.com:你的用户名/my-project.git
执行后会生成一个my-project文件夹，里面已经是一个Git仓库，远程地址也自动关联好了。往里面加文件，然后：
bash复制git add .
git commit -m "add src"
git push
直接从本地提交推送到远程，省掉了手动关联远程仓库、处理分支名不一致这些麻烦。新项目我基本都推荐这个路径，简单又不容易出错。
4.3 首次推送后，Gitee仓库里的文件结构确认
推送成功后，刷新Gitee仓库页面。你会看到代码文件、提交记录，以及一个“克隆/下载”按钮。点开提交历史，能看到刚才提交的说明文字和提交者身份信息，和本地git log看到的一致，说明双向同步成功。
到这一步，最基础的本地到远程链路已经彻底打通。
5. 日常使用高频命令与撤销回滚细节
5.1 每天都在用的三个命令
学习Git最忌讳背一堆命令。日常开发真正高频的就三个：
bash复制git status
git add .
git commit -m "提交说明"
git status是永远的安全网，随时查当前工作区状态：哪些文件改了、哪些没跟踪、当前在哪个分支。我自己的习惯是：改完代码先git status，确认改动符合预期再git add，提交完再git status确认干净。
git add支持精确添加单个文件：git add src/main.py；也支持添加某一类文件：git add *.py。新手阶段用git add .最省心，但注意它会把当前目录下所有未忽略的文件都加进去，如果项目里混入了不该提交的文件，就是这一步造成的。
git commit -m提交说明是给未来的自己看的，也是给团队看的。写得清楚一点，比如“修复登录页面密码框样式错位”，好过“update”这种空话。
5.2 推送后发现写错了怎么办：reset和revert的区别
用Gitee图形界面的人可能注意到，仓库页面上有“撤销上次提交”的按钮。很多人在VSCode里也见过类似功能，热搜里就有人问“撤销上次提交可以回滚吗”。这里把底层原理说透——注意，在推送代码到远程仓库之后，如果别人已经拉取过你的最新提交，随意撤销或回滚会破坏团队的历史，这时更稳妥的做法是保留之前的记录并追加一次反向提交，而不是强行删除历史。
本地提交还没推送时，想撤销最近一次提交，用：
bash复制git reset --soft HEAD~1
HEAD~1指往前数1个提交。--soft会保留所有改动在暂存区，也就是文件内容没丢，只是“提交”这个动作被撤销了，你可以重新修改后再提交。
如果不想保留在暂存区，想回到工作区，用：
bash复制git reset --mixed HEAD~1
如果想把改动彻底扔掉，回到上一次提交的干净状态，用：
bash复制git reset --hard HEAD~1
--hard很危险，改了文件之后执行它会彻底丢失工作区改动，别在没确认的情况下用。
但假如已经推送到了远程，又需要撤销，有两种选择：
git revert HEAD：生成一个新的反向提交，把这次改动抵消，历史完整保留，适合团队协作- 本地
git reset --hard后git push -f强制推送：会改写远程历史，适合个人维护、没人拉取过的仓库
关于热搜里提到的VSCode“撤销上次提交”，它默认执行的是git reset，所以只影响本地。如果代码已经推上去了，需要先拉取或者用revert，VSCode会给出相应提示。别一看到“撤销”就点，先想清楚是否已推送到远程。
5.3 分支是什么，为什么推荐用分支
分支是Git里面被神化了的概念，本质上就是一个可移动的指针。默认主分支叫master或main，你要开发新功能时，可以创建一条新分支：
bash复制git checkout -b feature-login
这行命令会基于当前代码创建一个叫feature-login的新分支，并切换过去。之后在新分支上做的所有提交，都不会影响主分支。等功能开发完，再切回主分支合并：
bash复制git checkout master
git merge feature-login
分支的好处是隔离风险。主分支保持可用状态，新功能在分支上天马行空，出问题也不波及主分支。对于学习阶段，其实单分支跑通就够用了，但理解分支概念之后，看网上各种Git协作流程图会轻松很多。
6. 推送经常遇到的几个难受问题：免密、gitignore与文件状态
6.1 明明配了SSH，怎么推送还要输密码
排查思路分三步。
第一步，确认远程地址用的是SSH还是HTTPS。执行：
bash复制git remote -v
如果输出是https://gitee.com/xxx.git，那说明走的是HTTPS协议，配再多的SSH公钥也没用。修正方法：
bash复制git remote set-url origin git@gitee.com:xxx.git
第二步，如果远程地址确实是SSH，但每次推送还是要求输入密码，那可能是连接时没有使用默认私钥。在Gitee的设置页面里确认公钥是否已经添加正确，并检查~/.ssh/id_ed25519.pub是否还有空格或换行符被误复制。
第三步，检查多密钥场景下的~/.ssh/config文件配置。如果多个平台用不同密钥，必须显式指定：
code复制Host gitee.com
HostName gitee.com
User git
IdentityFile ~/.ssh/id_ed25519
保存后重新验证ssh -T git@gitee.com，这时候Gitee才能准确识别你的身份。
6.2 .gitignore的正确使用姿势
.gitignore文件的作用是告诉Git：“以下这些文件我这次托管不需要跟踪”。每行一个忽略规则，支持通配符。
一个典型的Windows+Java项目忽略文件长这样：
gitignore复制target/
*.class
*.log
.idea/
*.iml
.DS_Store
一个前端项目：
gitignore复制node_modules/
dist/
.vscode/
*.local
写好之后，git status里就不会再出现这些目录了。这里有个细节：.gitignore只对“尚未被Git跟踪”的文件有效。如果某个文件已经被git add过，后面再在.gitignore里加它也没用，需要先：
bash复制git rm -r --cached node_modules
--cached的意思是只从Git索引中移除，不删除本地文件。执行完再提交一次，文件就不再被跟踪了。很多新手遇到“我明明写了node_modules忽略，怎么还能推上去”，就是这个原因。
所以新建项目时，最好第一时间把.gitignore配好，然后再开始写代码。Gitee在新建仓库时也提供了常用语言的.gitignore模板，选一个即可，比手写快也规范。
6.3 提交信息规范
Gitee上的提交信息是给人看的，也是给自动化工具看的。现在很多团队会按约定式提交来写提交信息，格式大致是：
code复制<type>(<scope>): <subject>
常用的type有：
feat新功能fix修复Bugdocs文档变更style格式调整refactor重构test测试相关chore构建或工具调整
示例：
bash复制git commit -m "fix(login): 修复密码错误提示不展示的问题"
好处是看了提交历史就能快速定位改动性质，配合Gitee的提交记录搜索，效率翻倍。个人项目也建议养成这个习惯，等以后项目大了写changelog，会发现每一步都清清楚楚。
7. 仓库设置里值得花时间的几个功能：开源许可证与Pages托管
7.1 开源许可证怎么选
建仓库时Gitee会要求选开源许可证，很多人直接跳过或者手滑选了一个。许可证不是可有可无的选项，它决定别人能不能合法使用你的代码，以及以什么方式使用。
个人学习项目随代码量很小，选不选影响不大，但如果代码托管在Gitee上且公开，建议至少了解三种最常见的选择：
- MIT License：最宽松，别人可以随便用、改、商用，只需保留版权声明。适合想被广泛使用的工具库、个人作品
- Apache License 2.0：比MIT稍严格，多了一条专利授权保护，对企业和开源项目更友好
- GPL License：传染性最强，如果有人用了你的代码，他的项目也必须开源且同样使用GPL。适合不想让代码被闭源商用的项目
选哪个取决于你对代码的期望。如果你做的是一个教学示例，想让大家随便拿去参考，选MIT；如果是想推动生态、也希望自己用的其他GPL项目有来有往，选GPL。
注意GPL对商用不友好，很多公司对GPL项目会专门禁用。如果未来可能进企业，选MIT或Apache2.0更稳妥。
7.2 Gitee Pages还有吗，怎么托管静态网页
有网友问“Gitee Pages没有了吗”，这里说明一下：这项服务的开通入口一直存在。Gitee Pages是官方提供的静态网页托管服务，能把仓库里的静态网页直接发布成可访问的网址，适合个人博客、项目介绍页、前端Demo展示。
使用方式是在仓库页面找到“服务”菜单，进入“Gitee Pages”，选择部署分支和目录，点击启动部署即可。如果部署后访问提示报错，多数是页面路径问题或引用了本地资源，需要在仓库根目录准备index.html等入口文件。
常见限制是把静态托管这类场景当作生产环境的人要注意：站点内容需要符合平台服务协议，同时若仓库停止更新，Pages也可能被暂停，所以平时Git推送保持活跃最重要。
7.3 一台电脑的全局配置和多个Gitee账号的取舍
最后聊一个容易被忽略的场景：很多人工作用公司Gitee账号，自己也有私人账号。为了切换方便，网上有些教程建议修改全局user.name和user.email，或者用多个SSH密钥反复切换，实际体验很差。
我的做法是：公司项目单独用git config user.name（不带--global）配置项目级身份，个人项目用全局配置。多个Gitee账号也同理，不同账号生成不同SSH密钥，用~/.ssh/config里的Host别名区分，而不是反复切换全局配置。这套思路在HTTPS和SSH两种访问方式下都适用，关键是不要把所有身份信息堆在全局里。
8. 在实际操作中最想提醒你的几件事
教程写到这，核心链路已经完整。最后分享几个我在实际使用中反复踩过的坑，不说出来总觉得这篇教程少了点什么。
第一件事：Windows系统对大小写不敏感，但Linux和Git对大小写敏感。代码里import Main和import main在Windows本地可能没区别，推送后在Gitee服务器上构建时就会报错。所以项目命名、包名、文件名，从一开始就统一用小写加连字符的格式，避免跟着平台习惯走。
第二件事：不要随便删除.git文件夹。有时候代码状态混乱到不可挽救，新手的第一反应是删掉.git目录重新git init，这相当于把完整历史一把火烧了。真有这种极端情况，先git log看看能不能恢复，实在不行也可以用git reflog找回之前的分支和提交记录。
第三件事：推送大文件要谨慎。Gitee免费仓库有大小限制，单文件超大或仓库体积过大时，推送会失败。大文件（比如数据集、安装包、图片素材）不要直接提交进Git仓库，优先考虑放到对象存储或其他文件共享服务，然后通过脚本或说明文件引导下载。如果实在需要版本管理，可以了解Git LFS这类大文件扩展方案，但个人项目通常没必要引入。
第四件事：网络问题导致的推送失败，别反复硬试。推送时报错Failed to connect或Connection timed out时，先确认网络环境是否能正常访问Gitee。如果网络本身不稳定，频繁重试只会让仓库状态更乱。可以检查代理设置，或者换时间段再试。
第五件事：提交说明里写清楚“为什么”而不是“做了什么”。单看代码差异，别人能知道代码改了什么，但通常不知道为什么要改。“修复重复ID导致页面锚点失效的兼容问题”远比“update id”有价值。
把这些细节捡起来，Git的日常使用基本不会再有让你卡住的坎。工具本身不复杂，复杂的是一开始没建立正确的操作习惯。按照这篇教程的顺序走一遍，从安装到推代码再到回滚撤销，你就能把基础链路吃透，剩下那些更高级的分支策略、Rebase、Stash，遇到具体场景再去查，都不算晚。