企业官网建设流程全解析

跑了几年项目，我见过太多“手工作坊”式的代码管理方式：代码靠压缩包备份，文件名永远带着日期后缀；某天改崩了想回退，只能凭记忆一条条改回来；给同事传代码用聊天软件发压缩包，传完再手动对比差别。后来我强迫自己把Git和Gitee这套组合真正用起来，才发现代码管理从手工作坊升级到正规军，效率差距真的不是一星半点。这篇文章就是一份从零到一的Gitee和Git超详细实战指南，覆盖Git安装、SSH配置、创建仓库、上传拉取、分支合并、IDE集成到常见报错排查，适合刚接触编程的学生、需要交代码的毕业生，以及刚入职想把本地项目推到公司仓库的新人。全程没有艰深的术语轰炸，都是我在实际开发里反复踩坑后验证过的路径，照着走就能跑通。

1. 为什么要告别“手工作坊”：先弄清楚Git和Gitee帮你解决了什么

1.1 “手工作坊”式代码管理的几种死法

我见过三种最典型的翻车现场。

第一种是“改崩了回不去”。前一天功能还正常，今天连续调了十几处，突然整个页面变成白屏。你想着“回到昨天下午那个能跑的状态”，翻开文件夹，最快只能找到前天中午的压缩包，昨天下午的没有备份。于是只能对着代码一点点打补丁，后悔自己为什么不多存几次。

第二种是“多设备不同步”。办公室里改了登录模块，回家想继续，发现U盘里是三天前的版本。回头把两台机器的代码拷到一起，同名文件互相覆盖，哪个新哪个旧只能靠肉眼猜。很多个人开发者其实是被这个问题逼到用Git的——不是因为协作，而是因为自己都要被自己搞疯了。

第三种是“协作靠发压缩包”。带实习生或者结对开发的时候，经常出现A把整个项目压缩包发给B，B改完再打包发回来。一来二去五六个版本，没人说得清哪个是最新的，某个修复是不是已经被合进去了。这种模式就算项目只有两个人也容易乱，更别提多人协作。

这些场景的本质都一样：缺少一套记录改动、随时回溯、多人同屏的版本管理机制。Git就是专门解决这个问题的，而Gitee是让这个机制跑在云端的落脚点。

1.2 Git是什么，Gitee又是什么：别再混为一谈

新手最容易混淆的点是：Git和Gitee到底谁是谁？

做个不太严谨但好懂的类比。Git是一个分布式版本控制系统，装在你电脑上，负责为你的代码每一次改动生成一条历史记录。它像一个自带翻页索引的账本：谁改的、改了什么、什么时候改的、因为什么理由改，全部写得清清楚楚。而Gitee是一个托管Git仓库的云端平台，你把本地仓库推到Gitee，等于把账本的副本放进了云端保险柜，换电脑、换同事、想展示代码，随时可以从保险柜里取出来。

可以这样记：Git是引擎，Gitee是停车场。引擎没有停车场也能转，但有了停车场，车才能停稳、才能给别人看。

为什么会选Gitee而不是GitHub，原因也很实际：国内访问速度对新手更友好，全中文的交互界面，个人仓库免费，私有仓库创建门槛低。很多学校和企业内部项目也都用Gitee，学会了基本操作，以后换GitLab、GitCode，底层都是同一套Git命令，熟悉成本很低。

1.3 先记住核心工作流：本地仓库、远程仓库、克隆、推送、拉取

网上教程一上来就铺开一堆概念，很容易把人劝退。其实新手只需要理解一条链路：本地仓库、远程仓库、克隆、推送、拉取。

本地工作目录就是眼前的项目文件夹。执行git init后，这个目录会多出一个隐藏的.git文件夹，本地仓库就诞生了。之后每做一次修改，通过git add把变更放进暂存区，再通过git commit生成一个带说明的版本记录。commit就是账本里的一条记录，记录了改动的完整快照和作者信息。

远程仓库就是你在Gitee上创建的仓库。把本地commit通过git push推上去，别人或另一台机器就能看到。反过来，你需要在另一台电脑上继续工作时，用git clone把远程仓库整个复制到本地，之后用git pull把远程新增的提交拉下来。

那一开始到底要背哪几个命令？我建议先背这六个：git init、git add、git commit、git push、git pull、git clone。它们之间的关系见下表：

理解一遍这张表，后面所有操作都围绕它展开。

2. 从零装好环境：Windows下Git安装与基础配置

2.1 Git下载与安装：三个关键选项别乱动

在Windows上装Git，我推荐直接用官网的安装包：git-scm.com，下载Windows版本，然后一路Next。但我不会告诉你“闭着眼点就行”这种不负责任的话，因为有几个选项有必要解释一下。

第一个是安装路径。默认C盘完全没问题，如果你喜欢改到D盘，注意路径里不要出现中文和空格，避免后面某些工具路径解析出问题。第二个是“Adjusting your PATH environment”，选默认的“Git from the command line and also from 3rd-party software”即可，这一项保证了Git在CMD和PowerShell里也能直接敲出来。第三个是“Checkout Windows-style, commit Unix-style line endings”，默认就好。这个选项处理换行符问题，Windows用CRLF，Linux/Mac用LF，Git会自动转换，新手保持默认最省事。

装完打开一个CMD或者PowerShell，敲一下这个命令验证是否成功：

git --version

能输出版本号，比如git version 2.43.0.windows.1，就说明安装成功。同时你也会发现开始菜单里多了Git Bash、Git GUI这几个程序，其中Git Bash是我们接下来要用的主力终端。

2.2 安装后的第一件事：配置user.name与user.email

Git装好之后，第一件事不是急着建仓库，而是先告诉Git你是谁。git commit生成记录时需要作者信息，不配置的话，提交要么失败，要么显示一串系统默认的“unknown”。

打开Git Bash，执行：

git config --global user.name "你的用户名" git config --global user.email "你注册Gitee用的邮箱"

--global的意思是全局配置，对这台机器上的所有仓库生效。如果你在公司项目里想用另一个身份，可以在项目目录里不带--global再设置一遍，该仓库内的配置会覆盖全局配置。

查一下配置是否写对了：

git config --list

会列出user.name、user.email等一堆配置项。这里给个真诚的建议：user.name最好跟你的Gitee账号用户名一致，user.email用Gitee注册邮箱。这样将来提交记录能正确关联你的Gitee账号，头像、提交数统计都能对上；如果随便起个名字，提交记录里就是一个陌生人，以后想认领非常麻烦。

2.3 Git Bash：一个比CMD更顺手的新手终端

装完Git，你会看到安装包附带了一个叫Git Bash的终端。它的外观和Linux终端很像，支持ls、cd、cat这些Unix命令，在Windows里提供接近Linux命令行的体验。对于平时只用CMD的小伙伴来说，Git Bash最大的优点是“跟网上的教程不容易产生歧义”，因为大多数Git教程的命令都是基于Unix风格写的，两边的回车键、引号、粘贴快捷键习惯都不一样，混着用很容易踩坑。

更好用的一个入口是右键菜单。在任意文件夹里点右键，选择“Git Bash Here”，终端打开后就直接定位到了当前目录，省去一堆cd操作。我自己的习惯是：项目文件夹右键打开Git Bash，所有Git操作全在里面执行，很少去开什么IDE内嵌终端。

这里顺便分享一个小习惯：粘贴命令到Git Bash，用Shift+Insert，或者直接点终端窗口的右键菜单选Paste，不要用快捷键Ctrl+V，后者在部分Windows终端里无效。很多人刚上手时命令老是“粘贴不进去”，其实就是这个细节。

3. 打通本地与Gitee：SSH密钥配置与仓库创建

3.1 为什么推荐SSH而不是HTTPS

Gitee上的仓库地址有两种协议：HTTPS和SSH。HTTPS地址长这样：https://gitee.com/用户名/仓库名.git，SSH地址长这样：git@gitee.com:用户名/仓库名.git。

新手阶段容易遇到一个问题：用HTTPS clone很顺利，但每次push都要输一次用户名密码，输多了就很烦。SSH方式则不同，配置一次密钥之后，以后push、pull全程免密。所以我推荐长期做开发的人直接用SSH，省下来的时间虽然看起来不多，但一旦你每天高频推送，体验差异会非常明显。

SSH原理其实也不难理解：你的电脑生成一对密钥，一个私钥（自己保存）和一个公钥（放到服务器），公钥想成一扇门锁，私钥想成一把钥匙。连接时服务器用公钥验证这把“钥匙”，配对成功就放行。整个过程不需要输入密码。

常见选择对比如下：

篇幅有限，这篇文章后面都以SSH为主讲。

3.2 生成SSH密钥：一条命令搞定

在Git Bash里执行：

ssh-keygen -t ed25519 -C "你注册Gitee的邮箱"

如果环境比较老、不支持ed25519算法，可以改用RSA：

ssh-keygen -t rsa -b 4096 -C "你注册Gitee的邮箱"

执行后一路回车即可，密钥文件会默认保存在用户主目录的.ssh目录下，文件名是id_ed25519和id_ed25519.pub。中间如果问“Enter passphrase”，可以留空，直接回车，配合免密操作更顺滑；如果设置密码短语，安全性会更高一点，但没配好反而容易忘记。

完成后，查看公钥内容：

cat ~/.ssh/id_ed25519.pub

屏幕上会出现一串以ssh-ed25519开头（或ssh-rsa开头）的长文本，这就是要复制粘贴到Gitee上的内容。

提示：.pub文件是公钥，可以给任何人看；同目录下的id_ed25519没有后缀，是私钥，绝对不能发给别人。把这个私钥文件保管好，就相当于保管好自己仓库的钥匙。

3.3 在Gitee上添加公钥，并验证连接

接下来登录Gitee，鼠标移到右上角头像，进入“设置”，左侧菜单找到“SSH公钥”，把刚才cat出来的公钥内容复制粘贴进去。“标题”随便填，比如“我的Windows电脑”，方便以后识别是哪台设备的密钥。填完点确定。

然后回到Git Bash，验证是否打通：

ssh -T git@gitee.com

第一次会弹出一句“Are you sure you want to continue connecting”，输入yes回车。如果配置成功，终端会显示类似“Hi 你的用户名! You've successfully authenticated, but Gitee does not provide shell access.”的信息，意思是认证通过。

如果报Permission denied，先回头检查公钥是不是复制完整了、有没有多余的空行，再检查一下本机加载的私钥：

ssh-add -l

如果列表里没有你的私钥，执行：

eval "$(ssh-agent -s)" ssh-add ~/.ssh/id_ed25519

再重新ssh -T验证。这一步也是很多人忽略的坑：公钥配在Gitee上了，但Windows的SSH agent没加载私钥，死活认证不过。

3.4 创建Gitee仓库：仓库名与开源许可证怎么选

登录Gitee，右上角“+”号，选“新建仓库”，进入创建页。

仓库名这一步我建议养成好习惯：用全小写英文加短横线组合，比如my-first-project。不要用中文，虽然Gitee支持中文仓库名，但在Git命令行里输入中文路径名很容易出幺蛾子，连复制粘贴都容易带乱码。仓库“路径”会自动根据名称生成，可以手动改。

创建页面里有一组选项：是否初始化仓库，是否添加.gitignore，是否加开源许可证。如果此时本地已经有写好的项目，我推荐不勾选初始化，等本地代码直接推上来；如果本地是空目录，可以勾选初始化，顺手生成README，仓库页面不至于一片空白。

开源许可证怎么选？如果仓库设置为公开，而且你有意让别人使用、分发你的代码，建议选一个。MIT协议最宽松，使用者几乎可以做任何事，只要保留版权声明，最适合个人工具和学习项目。Apache License 2.0相对更规范，额外包含了专利授权条款，适合准备长期发展的小组项目。GPL系列带有“传染性”，要求衍生项目也必须开源，适合希望社区回馈的场景。如果只是私有仓库自用，许可证可以先不选，以后开源时再补。

3.5 一个仓库能包含子项目吗

这个我经常被问到，答案是能，但要看你说的“子项目”是什么含义。

如果你的意思是，一个Gitee仓库里放几个小工具模块，每个模块有独立的目录，那完全没问题。Git仓库本身就是按目录组织的，你可以建一个仓库叫my-tools，下面放tools-a、tools-b两个目录，各自提交互不影响，远程仓库里也都是整体展示。这其实是很多开源项目的做法，叫单仓多包，管理成本最低。

如果你的意思是，两个子项目要各自独立版本历史、独立issue和独立权限，那就要考虑git submodule或者直接把仓库拆分成多个仓库。submodule是Git提供的一种引用方式，让一个仓库里嵌入另一个仓库的特定版本，适合像公共库、SDK这种跨项目复用的场景。但它的操作复杂度明显更高，新手不建议一上来就用。

我给的建议很明确：能放一个仓库就放一个仓库。真到了性能瓶颈或协作边界清晰的那天，再拆不迟。过早拆分只会让仓库管理和协作流程翻倍变复杂。

4. 第一行代码上云：把本地项目推到Gitee

4.1 初始化本地仓库

本地项目已经在电脑上了，现在要把它变成Git仓库。找到项目文件夹，右键点击“Git Bash Here”，然后执行：

git init

这条命令会在当前目录下创建一个隐藏的.git文件夹，里面存放仓库全部版本记录。执行后一般会提示“Initialized empty Git repository in ...”，项目就正式获得了Git身份。

这里要提一个在第3.4节埋下的坑：如果你在Gitee创建仓库时勾选了“初始化仓库”，远程仓库就有了一个初始的README提交。本地仓库此时是从空开始init的，两边每个commit的历史是完全独立的。本地第一次push时，Git会拒绝推送，因为远程有本地没有的提交。临时解决办法很简单——如果本地已经有内容，创建Gitee仓库时就不要选初始化；如果选了，就用4.3节的方法合并。

4.2 添加、提交、推送到远程：第一次push全程

在项目目录里，把文件加入暂存区并生成第一次提交：

git add . git commit -m "first commit"

第一句git add .会把当前目录所有未被忽略的文件放入暂存区。第二句commit则生成一条带说明的版本记录。

接着关联远程仓库。回到Gitee仓库首页，复制SSH地址，然后执行：

git remote add origin git@gitee.com:你的用户名/仓库名.git

把远程仓库命名为origin是Git约定俗成的名字，也可以叫别的，但新手照默认识别起来最方便。最后推送：

git push -u origin master

-u参数第一次使用，会把本地的master分支和远程的master分支绑定起来，之后只需要敲git push就能推送。如果远程仓库默认分支是main，先把本地分支改名再推送：

git branch -M main git push -u origin main

看到进度条走完，输出类似“master -> master”的信息，说明第一次推送成功。打开Gitee仓库页面，代码已经躺在云端了。

4.3 第一次推送时最常见的报错

很多新手第一次push都会看到一个吓人的红色报错：

To gitee.com:用户名/仓库名.git ! [rejected] master -> master (non-fast-forward) error: failed to push some refs to ... hint: Updates were rejected because the remote contains work that you do

翻译成人话就是：远程仓库里有你没有的提交，拒绝合并。出现这个报错，要么是创建远程仓库时勾选了初始化，要么是别人或另一台机器已经往仓库推送过代码。

解决办法是先把远程的最新提交拉下来，让本地和远程历史重新对齐，再推送：

git pull --rebase origin master git push -u origin master

git pull的--rebase参数会把本地提交“接”到远程历史之后，整体提交线更干净，不会多出一条合并提交。新手直接采用这个姿势，能少踩很多坑。

4.4 从Gitee拉取项目到本地

在另外一台电脑上，或者想重新下载自己的项目，最简单的方式是git clone：

git clone git@gitee.com:你的用户名/仓库名.git

执行后，当前目录下会生成一个以仓库名命名的文件夹，里面包含了完整的代码、.git仓库历史，并且自动配置好了origin远程地址。clone完成直接就可以继续开发，不需要再git remote add。

这里插一句：为什么不要用网页上的“下载ZIP”？因为ZIP包是代码的静态快照，没有任何Git历史，不能pull不能push，拿到手等于回到了手工作坊。git clone虽然第一次耗时多一点，但换来的是完整的版本演进。

如果clone一半断了，多数情况是网络不稳定，重新执行一次git clone即可。如果网络环境实在不好，也可以改用HTTPS地址clone，连上后把远程地址再换成SSH，方法见5.4节。不要因为一次失败就放弃git clone，多试几次或者换个时段，成功率都会高很多。

5. 日常开发核心操作：提交、回滚、分支合并

5.1 git add、commit、push的黄金节奏

仓库跑通后，日常开发就在几个命令里循环。我给新手一个每次改代码都适用的节奏：

1. git status先看当前状态，了解哪些文件被改动过，哪些是新增的。
2. 有选择地把本次涉及的文件加入暂存：git add 具体文件。谨慎使用git add .，尤其多人协作时，容易把无关文件甚至敏感文件一次性带进去。
3. git commit -m "清晰说明这次改动"，信息写清楚点，别人看历史能直接知道这一条提交干了什么。
4. push之前先git pull --rebase，把远程的新提交拉下来对齐。
5. git push推送到远程。

为什么要小步提交？因为commit是回溯的单位。假设你今天写了三个功能，中途第二个写坏了，如果三个功能是三个commit，你可以只回退第二个；如果全混进一个commit，神仙也难精准恢复。给commit写信息时，参考这种格式：“feat: 增加登录页验证码”、“fix: 修复订单列表分页错乱”、“docs: 更新README部署步骤”，一看就懂。

补充一个新手必知的概念：.gitignore。项目里那些不该进仓库的文件，比如编译产物target/、依赖目录node_modules/、IDE配置.idea/、日志文件，都可以写在.gitignore里。写好后Git会直接忽略这些路径，add .也不会误加入。一个简单的Java项目示例：

target/ *.class .idea/ *.iml

5.2 分支是什么，怎么合并

分支是Git里最强大的设计之一。你可以把它理解成平行世界：主分支master/main放稳定代码，开发分支随便折腾，等新功能验证通过了，再把开发分支合并回主分支。

实际的场景是这样：周一开工，你准备做用户中心模块。先创建并切换分支：

git switch -c feature/user-center

这条命令一步完成“创建+切换”。以后你在feature/user-center分支上随便写代码、随便提交，都不会影响master分支。等模块写完了，先切回主分支：

git switch master

然后把开发分支合并进来：

git merge feature/user-center

合并完成后，开发分支可以删除：

git branch -d feature/user-center

合并冲突是最常见的新手焦虑来源。两个人或者其他分支改了同一文件的同一行，merge时Git会停下，在文件中插入类似这样的冲突标记：

<<<<<<< HEAD 你当前分支的内容 ======= 被合并分支的内容 >>>>>>> feature/user-center

处理冲突不是用命令，而是手动编辑文件：把中间内容改成最终想要的样子，删掉<<<<<<<、=======、>>>>>>>这些标记，再add、commit。冲突本身不可怕，可怕的是没看清楚就乱提交。我的习惯是冲突文件全部打开，逐段确认，再统一提交。

5.3 commit写错了怎么办：git commit --amend

commit提交完了，才发现信息写错、或者漏了一个小文件，怎么办？不用急，commit还没推送的情况下，有一个专用的补救命令：git commit --amend。

改提交信息：

git commit --amend -m "正确的提交信息"

想补一个漏掉的文件：

git add 漏掉的文件 git commit --amend --no-edit

--no-edit的意思是保留原有提交信息，只是把漏掉的文件吸进上一次提交里。

原理上讲，amend会创建一个新的提交对象，替换掉原来那一次提交，提交哈希会改变。所以它有两条使用规则要记住：一是只在commit尚未推送时使用；二是如果已经推送了，又非改不可，可以用git push --force-with-lease强制更新，但该操作会改变共享历史，只能在极短时间窗口内、确认没有别人拉取时才做。平时最好不要碰强推，这也是团队协作的基本礼貌。

5.4 免密推送的收尾：把HTTPS仓库换成SSH

很多新手第一反应是直接选HTTPS clone，顺手嘛。结果推送几次后就被“每次输密码”折磨到不行。这时其实不需要重新clone，只需要把远程地址从HTTPS换成SSH。

查看当前远程地址：

git remote -v

修改origin的地址：

git remote set-url origin git@gitee.com:你的用户名/仓库名.git

改完再git remote -v确认一下，下次push就能享受SSH免密了。

另一个“免密”的实现方式是让Git记住HTTPS账号密码，比如Windows Credential Manager。但我不推荐多人共用电脑时这么做，凭据管理器里存的是固定账号密码，串号排查起来很麻烦。相比之下，SSH密钥的归属更清晰，换设备、删权限都可控，这也是我整篇文章始终推荐SSH的原因。

6. IDE无缝衔接：IDEA和VSCode里的Gitee

6.1 IntelliJ IDEA连接Gitee远程仓库

不少同学用IDEA写代码，但只在命令行里push，其实IDEA自带的Git集成已经做得很完整，把Gitee接进来后，commit、push、pull都可以点按钮完成。

第一种方式，从Gitee直接把项目克隆到IDEA。打开IDEA，选择File -> New -> Project from Version Control，在URL框粘贴Gitee仓库的SSH地址，选择存放目录，点Clone，IDEA会自己识别出项目结构并打开。

第二种方式，本地项目要关联远程仓库。打开项目后，在顶部菜单Git -> Manage Remotes里添加origin，把SSH地址填入；然后在Git菜单里选择Commit，勾选要提交的文件，填好提交信息；再点Push，推送框中确认目标仓库和分支即可。

有两点要提醒：IDEA本身不内置Git，需要系统里先装好Git；IDEA默认使用SSH连接，密钥配置请参考第3节。如果你发现IDEA里每次push都弹窗口要账号密码，检查Settings -> Version Control -> Git，把SSH executable改成Native，一般就能识别到本地密钥了。

6.2 VSCode使用Gitee：可视化操作同样够用

VSCode的Git集成也很方便，左侧的“源代码管理”面板（Ctrl+Shift+G）就是日常操作入口。

要在VSCode里克隆Gitee仓库，先打开命令面板Ctrl+Shift+P，输入Git: Clone，回车后粘贴仓库地址，选择本地目录，VSCode会自动打开这个项目。

日常提交只需要三步：在源代码管理面板里，点击文件右侧的“+”号将文件暂存，在上方输入框填写提交信息，然后点击“提交”按钮；提交完成后，再点一下“同步更改”，VSCode会执行pull然后push，把本地提交推送到Gitee。

如果想看某一行代码是谁写的、哪次提交改的，推荐安装GitLens插件，直接在编辑器里提供逐行归属信息，非常实用。如果VSCode里push时一直弹出账号密码，大概率又是仓库地址用了HTTPS，改用SSH即可，方法见5.4节。

6.3 再说一句：命令行值不值得学

每当我推荐直接在IDE里操作Git时，总担心新手会因此完全绕过命令行。我的看法是：IDE可以成为你的主操作台，但命令行绝对值得掌握基础的那十来条。

原因很简单，形态各异的报错、突如其来的冲突、需要精准回退的复杂操作，最终都会回到命令行。你见过谁用可视化工具解一个rebase冲突比命令行快的？可能也有，但少数。而且学会命令行之后，换任何一套IDE、换任何平台，你都不会有迁移成本，因为命令是到处通用的。

心态上不妨放宽：只要本地有push过的版本，Git里干错事都能恢复。删了分支？有reflog。commit不见了？有reset。放心大胆地试错，这才是学Git最快的路子。

7. 疑难杂症与排查实录

7.1 fatal: not a git repository (or any of the parent directories): .git

这个报错我几乎每个月都会看到有人问。出现它的场景通常是：打开某个文件夹，执行git status或git log，结果终端甩你一句fatal: not a git repository (or any of the parent directories): .git。

意思就是：当前目录不是Git仓库，父目录也不是。原因通常是这个目录根本没执行过git init，或者没在clone下来的项目根目录里。

排查顺序很固定：

• 先pwd看当前路径。
• 再ls -a看看有没有.git目录。
• 如果确定在仓库里但没有.git，八成是.git被误删，那只能重新git init，版本历史丢了没办法。
• 如果还没进仓库，cd到项目根目录再操作。

新手容易犯的小错误：在项目子目录里执行Git命令，而Git是在项目根目录init的。子目录本身如果是仓库内的一部分，Git向上查找.git是没问题的；但如果这个子目录并不在任何仓库里，自然就报错。

7.2 SSH认证失败：两个高频场景

SSH配好后，push/pull偶尔会冒出来两种“认证失败”，但人话完全不同。

第一种是Connection timed out。报错样式：ssh: connect to host gitee.com port 22: Connection timed out。这是22端口连不上，多半是当前网络环境限制或封锁了22端口，常见于公司网络、校园网络。Gitee对此有官方解法：用443端口访问SSH服务。先用以下命令验证：

ssh -T -p 443 git@ssh.gitee.com

能认证通过的话，把远程地址改成ssh://git@ssh.gitee.com:443/用户名/仓库.git，或者在用户目录的~/.ssh/config里配置Host段，把Hostname指定为ssh.gitee.com、Port指定为443。要是懒得折腾，临时把远程地址切回HTTPS也完全合法。

第二种是Permission denied (publickey)。意思是密钥认证没通过。排查时先确认公钥已经完整粘贴到Gitee，再检查ssh-add -l，看私钥有没有被agent加载，按3.3节的方法加载后再试。别忽视最简单的一环：是不是复制公钥时漏了开头或者结尾的字符。

7.3 清除Git账号密码缓存

不小心用错误账号推送过，或者输入密码时被记住，后面怎么都切不回来，这种问题通常出在HTTPS的凭据缓存上。

Windows下最直接的操作：打开控制面板 -> 用户账户 -> 凭据管理器 -> Windows凭据，在列表里找到git:https://gitee.com这一类条目，点删除。下次push时会重新弹出账号密码输入框。

如果还不行，可能Git配置里绑定了credential.helper，执行：

git config --global --unset credential.helper

把全局的凭据助手去掉。之后再push，Git就不会再去凭据管理器里找了。

个人建议：如果这台电脑会多人使用，或者只是临时开发机，别开HTTPS的凭据保存；用SSH密钥能避免掉90%的账号串号问题。

7.4 Git LFS：上传大文件到Gitee的正确姿势

Gitee仓库里上传普通代码没什么问题，但一旦涉及几十MB甚至几百MB的数据集、安装包、视频资源，普通Git仓库会非常吃力，仓库体积滚雪球。Git LFS就是干这个的：把大文件用指针替换，实际内容存到LFS存储服务，仓库里的.git负担大幅减小。

使用前先安装：

git lfs install

然后在仓库里声明要跟踪的文件类型：

git lfs track "*.zip" git lfs track "*.mp4"

执行后仓库里会出现一个.gitattributes文件，把它一起提交到仓库里：

git add .gitattributes git commit -m "add git lfs track" git push origin master

之后凡是以.zip、.mp4结尾的文件，都会被LFS存储。其他人clone时，Git会通过LFS指针自动拉取大文件内容。Gitee对LFS有明确的仓库大小和流量限制，具体数值以官方最新说明为准，不过大多数个人项目的中型资源都够用。

遇到git lfs clone卡住的情况，不少人会愣住。我的建议：不要死磕git lfs clone，改用普通git clone，进目录后再执行git lfs pull，把大文件补齐。两个步骤分开走，哪个出问题都好排查。

另外有一个相关命令：git config --global --unset lfs.fetchexclude。如果有人之前设置过LFS排除规则，导致某个大文件类型在fetch时被跳过，后续执行该命令取消排除，再git lfs pull把缺失的大文件拉下来，仓库内容才算完整。

7.5 Gitee Pages：把仓库变成在线网页

最后聊一个有点甜头的功能：Gitee Pages。它可以把仓库里的静态文件直接部署成一个可公开访问的网页，特别适合个人主页、文档站、前端demo演示。

使用前有两个前提：要完成Gitee的实名认证，仓库要设置为公开。

操作路径不复杂：进入仓库首页，在顶部的“服务”菜单里找到“Gitee Pages”，点击新建，选择要部署的分支和目录，再点击部署即可。部署成功后，会得到一个格式类似xxx.gitee.io的访问地址。前端初学者可以把写好的HTML页面推到仓库，然后用Pages快速生成一个能展示的作品链接。

提示：Pages服务面向的是公开访问，仓库内容等于对所有人开放。部署个人主页或demo时，不要把密钥、数据库配置、联系方式这些敏感信息放进仓库里，这些内容一旦公开，即使删除历史推送也无济于事，因为别人可能已经下载过了。

Pages的具体规则和配额，以Gitee官方页面当前说明为准。有空翻一翻，比网上搬运的各种攻略靠谱。

结尾

通篇看下来，从为什么需要Git，到环境搭建、SSH打通、仓库创建、第一次推送，再到分支、IDE集成、疑难排查、大文件管理，基本覆盖了新手从零到一的全过程。我个人在实际操作中最深的体会是，Git和Gitee真正改变的不是工具，而是习惯——每个改动都留一条说明，每版代码都有一个可回退的锚点，这种安全感是手工作坊式管理给不了的。

最后再分享一个小技巧：如果你刚开始，别试图把文档读完了再动手。先建一个测试仓库，随便写几句代码，走一遍init、add、commit、push、pull的完整链路。出错了也不要紧，对照第7节的排查实录逐个解决。代码管理这种事，一旦踏出第一步，后面的路就顺了。