企业官网建设流程全解析

说实话，我见过太多人卡在“会用Git”和“会上Gitee”中间那道坎上——本地仓库建得明明白白，代码写了一堆，一说到“推送到远程仓库”就开始手忙脚乱。尤其是点开Gitee官网之后，面对那一堆按钮和选项，第一反应往往是“这跟GitHub怎么长得不太一样”。作为一个把Gitee当主力代码托管平台用了好几年的开发者，我可以负责任地告诉你：Gitee的实战使用真没你想的那么复杂，你需要的只是一条清晰的操作路径和几个关键概念的正确理解。这篇内容不会给你堆砌命令大全，而是从零开始，讲清楚每步操作背后的原因，让你看完之后不光知道“怎么点”，更知道“为什么这么点”，这样以后换任何代码托管平台，你都能举一反三。

这篇文章适合几类人看：刚入行没多久、项目一直只存在本地硬盘里的新手；被公司或团队要求把代码迁到Gitee但不太熟悉整套流程的同学；还有那些想在Gitee上部署一个静态网站却始终没搞明白Pages功能的开发者。我会把注册配置、建仓库、代码上传、Pages静态托管这些高频场景全部拆开揉碎，最后再给你一份常见问题排查清单，基本都是我实际踩过的坑。

1. 先把Gitee到底做什么说清楚

1.1 为什么我建议把Gitee当成第一个代码托管平台

如果你第一次接触代码托管，我真心建议从Gitee开始，而不是直接冲去注册GitHub。原因很简单：一个是访问速度，Gitee服务器在国内，clone和push代码基本是秒级响应；另一个是中文界面，所有按钮、提示、文档都是中文，对新手极其友好。很多教程一上来就让你敲git命令操作GitHub，结果因为网络问题卡在第一步，体验非常劝退。

GitHub当然很好，全球最大的开源社区，但这不意味着它是唯一选择。Gitee的定位是“国内 GitHub”，它在国内环境下做了大量针对性优化。比如私有仓库免费、容量限制宽松、支持一键导入GitHub仓库，这些功能对个人开发者和小团队来说非常实用。我自己的经验是：先在国内平台把Git操作练熟，搞清楚工作流，之后再接触GitHub会轻松得多，因为底层逻辑是完全一致的。

还有一点容易被忽略——Gitee的社区氛围其实更贴近国内开发者的实际需求。你在上面能找到大量中文注释的项目源码、针对国内业务场景的工具库、还有不少技术博主把教程和代码放在一起维护。这种“代码+文章”的组合，对学习型开发者来说价值很高。

1.2 本地仓库和远程仓库，一张图记住它们的关系

很多教程在讲Gitee的时候，默认你已经理解了Git的核心概念，但实际很多人的困惑恰恰出在这里。我用大白话帮你理一遍：本地仓库就是你电脑上那个隐藏的.git文件夹，它记录了你所有代码的版本历史，相当于你项目的“时光机”；远程仓库就是Gitee服务器上为你这个项目单独开辟的一块存储空间，相当于你把“时光机”备份了一份放到云端。

两者之间的关系可以这样理解：你平时在本地写代码、提交（commit），这些操作只影响本地；当你准备把某个阶段的成果拿给别人看，或者怕本地硬盘坏了代码丢失，你就执行“推送”（push），把本地提交同步到Gitee；别人改了代码，或者你在另一台电脑上继续开发，就执行“拉取”（pull），把远程最新的内容同步回本地。

这个“本地-远程”双轨制的设计，就是Git一切操作的核心逻辑。搞清楚这个，后面所有命令你都能猜到大概意思：git init是创建本地仓库，git remote add是给本地仓库绑定一个远程地址，git push是上传，git pull是下载。

2. 注册、配置，把钥匙配好

2.1 注册账号时的几个小细节

注册Gitee账号本身没什么好说的，手机号或者邮箱都可以。但有几个小细节值得你注意：用户名（个人空间地址）一旦确定，后面会显示在你所有仓库的URL里，尽量选一个和你的技术ID一致、好记的英文名；实名认证建议直接做掉，虽然不实名也能用基础功能，但后续开启Pages、增加仓库容量这类操作都会受到限制，早晚要认证，不如一开始就办好。

登录之后先别急着建仓库，先做一件事：设置SSH公钥。这是新手最容易忽略、也是后面所有上传操作能否顺利的关键。Gitee支持HTTPS和SSH两种协议访问仓库，HTTPS每次push都要输入账号密码，虽然可以靠记住密码功能省事，但换台电脑又得重新配置；SSH则是一劳永逸，配置一次密钥，后续所有仓库的推送拉取都不需要再输入任何凭证。

2.2 SSH密钥生成与配置实操

先说原理：SSH密钥就是一对加密文件，一个私钥（默认叫id_rsa）留在你电脑上，绝对不能泄露；一个公钥（id_rsa.pub）可以随意分发，把它填到Gitee后台，相当于告诉Gitee“持有这把私钥的人是我的电脑”。以后你电脑访问Gitee时，服务器会用公钥验证你的身份，验证通过就放行。

生成密钥的步骤非常简单。打开终端（Windows用户建议直接用Git Bash，别用自带的cmd），输入以下命令：

ssh-keygen -t rsa -C "你的邮箱@example.com" -b 4096

注意把邮箱换成你注册Gitee用的邮箱。执行之后一路回车即可，它会默认把密钥保存到用户目录下的.ssh文件夹，并且不设置密码短语（passphrase）。如果之前已经生成过密钥，它会提示你是否覆盖，根据你自己情况选择，覆盖之后旧密钥就失效了。

然后查看公钥内容：

cat ~/.ssh/id_rsa.pub

如果你用的是Windows Git Bash，路径一般是/c/Users/你的用户名/.ssh/id_rsa.pub。用鼠标选中整段输出并复制，注意别漏掉结尾的邮箱号。

接下来登录Gitee，点击右上角头像进入设置，找到“安全设置”里的“SSH公钥”选项卡，把复制的内容粘贴到“公钥”输入框里，标题可以随便填，比如“我的MacBookPro”或“公司台式机”，方便以后区分多台设备。保存之后，在终端里输入：

ssh -T git@gitee.com

第一次连接会提示是否确认指纹，输入yes回车。如果看到欢迎信息，类似“Hi 用户名! You've successfully authenticated, but GITEE.COM does not provide shell access.”，说明密钥配置成功，整套流程走通了。

2.3 实操心得：HTTPS和SSH怎么选

我见过很多教程直接让新手用SSH，理由是不用输密码，但对完全没接触过终端的人来说，ssh-keygen这个命令本身就有门槛。所以我的建议是分情况：如果只在固定的一台电脑上开发，而且嫌配置麻烦，直接选HTTPS也完全没问题，第一次push输一次账号密码，后面用Git的credential存储机制也能自动记住；如果需要在多台电脑上协作、或者担心密码明文存储的风险，那就老老实实配SSH，一次性投入换来长期省心。

说实话，实际工作中把两种方式混用的人特别多——公司电脑配了SSH，个人电脑用HTTPS——Git本身完全支持，远程地址里写哪种协议就用哪种方式验证，互不影响。确定一种方式之后，远程地址的格式要注意：HTTPS地址是https://gitee.com/用户名/仓库名.git，SSH地址是git@gitee.com:用户名/仓库名.git，很多人push报错就是因为两种协议地址用混了。

3. 建仓库：注意几个容易选错的选项

3.1 创建仓库时的字段逐个说

登录Gitee之后，点击右上角的“+”号，下拉菜单里选“新建仓库”，就会进入仓库信息填写页面。看到那一堆字段别慌，真正影响使用体验的其实就几个。

仓库名称必须填，尽量用小写字母、数字和中横线，比如my-blog、mall-server，不要用中文名、不要有大写字母。路径（Path）会自动根据名称生成，一般不用改。仓库介绍和标签可以填也可以不填，不影响功能，但建议随手写上，毕竟开源项目有个好描述能增加曝光。

归属选择“个人空间地址”即可，除非你加入了某个企业或组织。初始化仓库这一栏有三个选项：红框里的“初始化仓库”（自动生成README文件）、.gitignore模板（自动生成忽略规则文件）、选择开源许可证。我的建议是新手先勾选“初始化仓库”和.gitignore模板，这样仓库建好之后不是完全空白，可以直接clone下来开始干活，也可以避免很多刚上手时容易踩的坑。比如.gitignore可以自动帮你排除掉target、node_modules这类不应该提交的文件，不然下次本来想提交全部代码，结果把几千个依赖包全传上去了，手忙脚乱，得不偿失。

3.2 开源许可证到底选哪个

“开源许可证选什么”一直是新手纠结的重点。我在Gitee上见过很多仓库完全没有许可证文件，这样做其实是有问题的：别人看到你的开源项目，想用又不敢用，因为不确定你的授权范围。如果你只是想公开代码，不关心别人怎么用，最省事的是选“MIT License”，它几乎是所有开源许可证里限制最少、最通俗易懂的，别人想商用、想修改、想闭源都行，只要保留你的版权声明即可。

如果你的目标是希望代码永远保持开源，别人改了也必须开源，那就选GPL-3.0，它对版权保护更严格——如果有人基于你的代码做了修改再分发，那他的项目必须也开源，且必须以同样的许可证方式发布。这一点很关键，很多小白选了这个却不知道自己签了“互相传染”的协议，直到某天商业合作时才尴尬。

如果只是想把代码挂出来给团队内部或几个朋友用，不想选择任何许可证，那就用“自定义许可证”或者暂时不选，把仓库设为私有（Private）就行，完全不会有版权争议。许可证选择我个人推荐一个原则：MIT是个人项目默认项，Apache-2.0适合想同时保留专利授权的开源项目，GPL-3.0适合希望强制保持开源的场景。

3.3 私有和公开，先别急着决定

仓库可见性有“私有”和“公开”两个选项。公开仓库任何人都能看到和clone，私有仓库只有你自己和被你授权的协作者能访问。许多新手一开始就把项目设为公开，以为能获得关注，但代码质量、注释、敏感信息（比如数据库密码、API Key）都没清理，结果惹来一堆麻烦。

我的习惯是：刚开始写的个人项目一律私有，等代码稳定、README写完整了、确定不包含敏感信息之后再切换为公开。Gitee支持在仓库的“管理”页面随时切换可见性，这点非常灵活，不需要一开始就做决定。另外注意，Gitee的私有仓库对个人用户有协作人数限制，但自己用完全足够。

4. 代码上传：命令行和IDE两种方式都给你

4.1 命令行，最通用的方案

不管你用什么开发工具，命令行那套流程永远应该先掌握，因为它不依赖任何IDE，在服务器上、在远程开发环境里都能用。假设你本地已经有一个项目文件夹，里面有一堆代码，现在要把它们提交到Gitee仓库里。

进入项目目录，初始化本地仓库：

cd 你的项目目录 git init

这个命令会在当前目录下生成一个.git隐藏文件夹，表示本地仓库已就绪。

把项目所有文件加到暂存区：

git add .

你可能会疑惑这个“暂存区”是什么。可以这样理解：Git把所有待提交的文件分成了三步——工作区（你实际改动的文件）、暂存区（你决定本次要提交的文件清单）、版本库（已经生成快照的记录）。git add就是把文件从工作区挪进暂存区，git commit则是把暂存区内容正式存档。

提交到本地仓库并附上说明：

git commit -m "第一次提交，初始化项目"

双引号里的内容建议写清楚本次提交做了什么，方便以后回溯。

把本地仓库和Gitee远程仓库关联起来。打开你的Gitee仓库页面，找到“克隆/下载”按钮，复制SSH地址。然后执行：

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

这里的origin是一个默认的远程仓库别名，相当于给那一长串地址起个好记的名字。以后凡是看到origin，就知道指的是Gitee上的这个仓库。

推送本地代码到远程：

git push -u origin master

如果分支不是master而是main（新版Gitee仓库默认分支名可能是main），把命令里的master换成main。-u参数表示第一次推送时建立本地分支和远程分支的关联关系，以后直接输入git push就能推送，不用再带完整参数。

执行之后，在Gitee仓库页面刷新一下，你的代码就出现在上面了。整个流程我用一段话给你串一遍：git init创建本地仓库、git remote add绑定远程地址、git add和git commit在本地存档、git push推到Gitee。四步走，记住这个节奏，后面就顺了。

4.2 IDEA提交代码到Gitee

平时用IntelliJ IDEA开发的同学，完全可以在图形界面里完成上传，不一定非要切到终端敲命令。但注意：IDEA本身不带Git客户端，你需要先安装Git软件，然后在IDEA的设置里配置好路径。

用IDEA打开项目之后，菜单欄选VCS -> Enable Version Control Integration，选择Git，这相当于执行了git init。

关联远程仓库：VCS -> Git -> Remotes，点加号，把Gitee仓库的地址粘贴进来。这里建议直接选HTTPS地址，因为IDE里对SSH密钥的读取有时会跟系统配置有冲突，HTTPS反而省事。

之后每次修改代码，选中文件或整个项目，右键Git -> Commit Directory，填好Commit Message，点击Commit。如果要推送，再右键选Git -> Repository -> Push。第一次推送时IDEA会要求你输入Gitee账号密码，验证通过后会保存凭证。

4.3 PyCharm和VSCode的差异点

PyCharm和IDEA同属JetBrains家族，操作逻辑一模一样，上面那套步骤完全适用。唯一的差异是：如果用的是社区版PyCharm，功能没有专业版全，某些Git功能可能被禁用，这时就老老实实用命令行。

VSCode用起来更轻量。左侧菜单栏的源代码管理图标就可以完成提交、拉取、推送。但大部分VSCode用户还是会装一个GitLens插件，它能显示每行代码的提交者、提交时间、最近修改记录，查历史非常方便。

另外可能有人不知道，VSCode有一个专门的Gitee插件叫“Gitee”，你可以在扩展市场搜一下，装好之后能在侧边栏直接浏览Gitee仓库、创建仓库、甚至在线修改文件再提交，节省了频繁切网页的时间。不过这类插件更新速度一般，用之前先看看最近更新时间，避免版本兼容问题。

5. 静态托管：Gitee Pages 让项目直接变成网站

5.1 Pages 能做什么

Gitee Pages是Gitee提供的一个静态网站托管服务，简单说就是你把HTML、CSS、JS这些前端文件放到一个仓库里，Gitee能帮你把它们发布成一个可以通过公网链接访问的网站。很多人拿它当个人博客的免费托管，也有不少人部署纯前端的小工具，比如我就在上面跑过一个PDF转换的纯前端小工具，整个仓库只有几个前端文件，但不影响它成为一个完整可用的服务。

为什么叫“纯前端”？因为静态托管只能跑浏览器端代码，没有服务器端语言（Node.js、PHP、Java这类）的执行环境，数据库更不用提。但好处也因此很明显：没有服务器成本、没有运维负担、页面加载速度快，而且完全不需要考虑后端安全问题。

5.2 开通流程实操

在Gitee上部署Pages的完整流程是：先建一个仓库，把前端项目文件推上去；然后进入仓库的服务页面，找到Gitee Pages。第一次使用会让你上传一个身份证信息做人脸实名认证，认证过了才能开启。认证通过之后，选择要部署的分支和目录，一般选master分支和根目录，点击启动，等一两分钟它会自动生成一个形如你的用户名.gitee.io/仓库名的访问地址。之后每次更新代码，需要手动点击更新按钮重新部署，不像GitHub Actions可以全自动化。

一个需要特别注意的点：Gitee Pages对仓库容量和单文件大小有限制，项目体积超过100MB基本就别想部署了。如果项目里有大图片、视频，建议单独传到对象存储，页面里引用外部链接就好。

5.3 一个前端PDF工具上线的真实案例

我曾经在Gitee Pages上部署过一个“PDF转Word”的前端工具，源码是当时在GitHub上搜到的，一个开源项目，纯HTML+JavaScript实现，文件只有几个。部署过程本身没什么好说，真正有价值的是我踩过的坑。

第一个坑是跨域问题。纯前端PDF转换本质是在浏览器本地解析PDF文件，但某些浏览器对本地文件读取有安全限制，直接通过file://协议打开会失败。部署到Pages之后，因为通过HTTPS访问，反而规避了这个问题。所以我建议：如果你做这类纯前端小工具，别只在本地测试，老老实实丢到Pages上跑一遍，很多诡异问题都是环境差异导致的。

第二个坑是更新缓存。Pages部署完成后，你刷新网站可能还是旧版本，这是因为浏览器和Gitee CDN都做了缓存，清理缓存或者强制刷新（Ctrl+Shift+R）能解决大部分情况。如果还不行，可以给引用的JS/CSS文件加上版本号参数，比如app.js?v=20240101，强制浏览器拉取新文件。

第三个坑就是部署时间。第一次部署大概3-5分钟，更新部署大约1-2分钟。每次“更新”按钮点下去之后看到“部署成功”的绿色提示再关页面，不然可能生成的是半旧的页面快照。

6. 常见问题与排查技巧实录

6.1 push时报错、报授权失败怎么办

我见过最高频的问题是git push时报Permission denied (publickey)，这几乎都是SSH密钥没配对导致的。排查顺序如下：

ssh -T git@gitee.com

看是否显示欢迎信息，如果提示Permission denied，说明电脑上的密钥和Gitee上配置的公钥不匹配。这时候一件一件事确认：公钥有没有完整复制到Gitee后台；复制的是不是id_rsa.pub而非id_rsa；生成密钥时邮箱有没有填错；Gitee更换邮箱后旧邮箱的公钥是否被禁用。

另一个高频问题是remote: HTTP Basic: Access denied，这是HTTPS方式访问时账号或密码错误。处理办法比较简单：重新输入一次正确密码，或者在Windows的凭据管理器里删掉旧的金迪凭据再重新推送。macOS用户在“钥匙串访问”里搜索gitee，删除对应的网络密码即可，这个坑不少macOS用户都遇到过。

6.2 上传代码后Gitee页面没显示怎么办

有时本地命令执行顺畅，Gitee页面刷新后却看不到代码。先确认自己是不是推错了仓库——这个错误多到你无法想象，因为git remote -v能看到当前仓库绑定的远程地址，如果显示的是另一个项目，说明你复用错了.git配置。

还有一种很隐蔽的情况：你在项目里执行过git init，但项目本身是一个子目录，外面套着一层目录，你刚好在错误的层级执行了命令，导致提交的文件路径全不对。这种情况我的建议是清理掉所有.git文件夹重新来一遍：

find . -name ".git" -type d -exec rm -rf {} \;

然后重新git init、重新绑定远程地址。

6.3 误删仓库怎么抢救

Gitee个人版没有直接回收站功能，仓库一旦被删除，代码和提交历史会全部消失。所以我持续强调那句：本地永远留一份完整的副本，涉及重要代码，务必养成定期推送的习惯。有次我手滑在网页上删了一个demo仓库，还好本地有完整代码，但那个仓库里的Issues和Pages配置全没了，只好重建，痛了半小时。

如果你误删了仓库并且本地没有备份，不要完全绝望——Gitee客服可以尝试帮你恢复，但过程比较慢，而且不是100%保证成功。所以，最好的“抢救”是从一开始就不让这种事情发生。我现在的习惯是：重要仓库开“备份”和管理员二次确认，每次删除前至少读两遍仓库名称。

6.4 常见问题速查表

最后再分享一个小经验：Gitee的整体使用难度真的不高，真正让你感到迷茫的是操作背后的概念。你把“本地分支”“远程仓库”“暂存区”“SSH身份验证”这些词弄明白了，随便换一个平台（GitHub、GitLab、Coding）都能很快上手。我建议你找个不重要的项目，按照上面流程老老实实走一遍：建仓库、配置密钥、推代码、开Pages，整个过程半小时搞定。走完一遍之后你会发现，所谓Gitee实战，其实就那几板斧，往后就是肌肉记忆了。