企业官网建设流程全解析

1. 2021年重新认识Gitee：为什么越来越多人转向它

1.1 “2021年最新”到底新在哪里

先说结论：2021年的Gitee跟两三年前相比，已经不是同一个量级的工具了。以前很多人对它的印象停留在“国内能用的大码云”“GitHub的备胎”，但这一两年它明显在往“一站式软件研发平台”的方向走，把仓库托管、代码评审、项目管理、文档管理、静态站点部署和CI/CD流水线串到了一起。

我实测下来的几个重要变化：一是界面改版，仓库详情页的模块排布更接近主流海外平台的体验，导航层级更清晰；二是Gitee Go流水线正式向更多普通用户开放，可以直接在仓库内配置构建规则，跑完单元测试再交付产物，不再需要另外折腾一套CI工具；三是Pages服务对个人项目很友好，一个静态博客、一个前端Demo，推上去就能生成访问链接，整个过程不用买服务器；四是仓库的附件、Release、里程碑、Issues这些协作模块补齐了，团队内部管理需求和缺陷完全能在一个平台上闭环。

所以这篇教程没有按“怎么注册、怎么建仓、怎么push”的老套路逐一背书，而是以2021年实际能用的功能为准绳，把一套完整的项目托管和协作流程讲清楚。适合刚接触Git的初学者，也适合以前只用了上传下载功能、想看看新功能的老用户。看完之后你拿一个模拟项目X从头到尾走一遍，基本就能把Gitee用出生产力，而不是只当一个网盘。

提示：全文以网页版Gitee 2021年的界面和主流Git命令为准，个别按钮位置可能因版本迭代略有差异，但操作逻辑是通用的。

1.2 账号注册与主页设置里的几个小细节

注册流程本身没什么好说的，手机号或者邮箱都行，这里提醒几个容易踩的坑。

第一，用户名一定要认真想。Gitee的用户名会体现在你的个人主页URL里，也就是别人看到你项目链接时的那段英文标识。很多早期用户随手填了一串乱码，后面想改虽然能改，但已经发出去的链接全得跟着变。注册时尽量用姓名拼音或者英文ID，保持简短好记。

第二，完成注册后先去做实名认证。2021年的Gitee对代码仓库本身没有强制要求实名，但如果你想用Gitee Pages部署静态站点，或者需要用到更高额度的 API 调用，实名认证是关键前置条件。这个认证在“个人主页 → 账号设置 → 实名认证”里，按提示上传相关信息即可，审核速度实测挺快。

第三，设置SSH密钥之前，先确认邮箱。Gitee会根据你在“账号设置 → 邮箱管理”里绑定的邮箱来关联Git提交记录。如果你本地Git的user.email跟Gitee邮箱不一致，提交记录里会显示成一个未知用户，头像也不会正确关联。这个不影响代码安全，但看着很别扭，而且会给协作时的贡献统计带来麻烦。

第四，主页的个人简介和常用语言标签虽然不影响功能，但如果你要做开源项目，一个写清楚项目方向、技术栈的主页更容易吸引到贡献者。这个属于公共形象层面的建议，成本极低，收益长期看是正的。

2. 仓库创建与本地环境配置

2.1 新建一个仓库的正确姿势

在Gitee首页左上角找到“新建仓库”按钮，进入创建页以后不要急着点提交，先想清楚几个选项。

仓库名称是项目链路里最外露的标识，建议跟本地项目目录同名，且统一用小写字母加连字符。比如my-springboot-service，而不是MySpringbootService。原因很简单：URL大小写敏感，团队里一旦有成员用了不同大小写去克隆，容易凭空多出“仓库不存在”的问题；另外很多构建工具对项目名的规范化也有要求，小写连字符最稳妥。

“路径/名称”一栏默认会跟着仓库名走，也可以单独指定，用途是最终访问路径。这个一旦创建后修改代价高，想好了再填。

“开源许可证”建议非个人隐私项目都选上，最简单的是默认的MIT License，含义是别人可以用、可以改、可以商用，只要保留版权声明。如果你不希望别人商用你的代码，可选GPL-3.0，但要注意GPL感染性比较强，混入GPL代码的整个项目都得开源。这个属于法律边界问题，团队项目务必提前确认，别等发了仓库再换协议。

初始化仓库时有一个“使用Readme文件初始化”的勾选项，2021年的默认行为是建议勾选，它会帮你生成一个常见的README骨架。如果你本地已经有项目代码，建议不勾，直接推代码上去；如果是空仓起步，勾上可以少两步操作。

.gitignore的模板选择也别忽略。Gitee内置了各主流语言的ignore模板，选一个合适的可以避免之后把node_modules、target、.idea这类目录误提交上去。这个文件越早进仓库越好，因为一旦垃圾文件已经被提交过，清理起来需要重写历史，对协作项目来说非常麻烦。

2.2 SSH公钥配置：一次配置，长期省心

说完建仓，说连接方式。2021年Gitee支持HTTPS和SSH两种远程协议，我强烈建议你花五分钟配置SSH。

HTTPS的优点是零配置，复制链接就能用；缺点是每次push都需要输入用户名密码，虽然Gitee支持在个人设置里生成私人令牌代替密码，但使用流程总归多一步。SSH配置好之后，git与远端通信走密钥认证，不需要每次输密码，长期体验最顺手。

配置步骤分四步，这里按Windows、macOS/Linux通用流程走：

第一，打开终端，执行ssh-keygen -t ed25519 -C "你的邮箱"。ed25519是2021年推荐使用的算法，比传统的RSA密钥更短且安全强度足够，Gitee支持这种密钥格式。一路回车到底，会在~/.ssh/目录生成一对文件，私钥id_ed25519和公钥id_ed25519.pub。

第二，查看公钥内容。Windows下执行cat ~/.ssh/id_ed25519.pub，macOS/Linux也一样。复制整段内容，注意不要多复制换行符。

第三，登录Gitee网页端，进入“账号设置 → SSH公钥 → 添加公钥”，把复制的内容粘贴进去，标题可以随便填，比如“我常用的笔记本”。保存后一般立即生效。

第四，验证是否配置成功：ssh -T git@gitee.com。第一次执行会提示确认远端指纹，输入yes即可。如果看到欢迎语和你的用户名，说明SSH链路已经通了。

注意：私钥文件id_ed25519一定不要泄露，不要提交到代码仓库，不要发到聊天工具里。如果怀疑私钥泄露，立刻删除Gitee后台的公钥记录并重新生成一对。

2.3 Git安装与初始配置：新用户最容易漏掉的一环

如果你本机还没装Git，直接到官网下载对应系统的安装包。Windows用户注意安装时勾选“添加到PATH”，否则后续在终端里找不到git命令。安装完重新开一个终端，执行git --version能看到版本号就OK。

这一步之后有一组全局配置经常被忽略，却是后续所有提交正确归属的基础：

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

我见过不少新手第一次push后，Gitee仓库里显示的贡献者全是乱码或者“unknown”，原因就是没做这两行配置。另外顺手建议设置默认分支名和推送简化规则：

git config --global init.defaultBranch main git config --global push.default simple

init.defaultBranch main会让新建仓库的默认分支是main而不是master。Gitee新仓库默认分支名也是main，保持一致能减少心理负担。push.default simple是更符合直觉的推送策略，指定当前分支推送到同名远端分支，避免一条命令引发不必要的结果。

3. 把项目放到云端：完整的上传与迭代流程

3.1 本地仓库初始化与首次推送

假设你手头有一个项目目录，里面已经有了业务代码，现在要托管到Gitee。首先在项目根目录打开终端，执行：

git init git add . git commit -m "init: 初始提交"

这里有个细节：2021年Gitee新建空仓库时，通常会提供一个带SSH链接的“已有仓库”推送命令块，类似下面这样：

git remote add origin git@gitee.com:你的用户名/仓库名.git git push -u origin "main"

直接照着执行就行。注意-u参数的作用是把本地分支与远端分支建立关联，之后在这个分支上执行git push就不用再写完整的远端分支名了。

首次推送如果提示“远端未包含任何分支”，很正常，说明远端是空仓库，push过去即是初始化。如果远端已经有Readme或其他文件，而本地历史跟远端不相关，push会被拒绝。这种情况不要硬推，最常见且安全的办法是先把远端内容拉到本地合并：

git pull origin main --allow-unrelated-histories

然后解决可能出现的冲突，再重新push。这个参数的含义是允许两个没有共同祖先的历史进行合并，只在初始合并场景下使用，常规开发不要乱加。

3.2 日常提交流程：让提交记录变成可检索的工作日志

项目进入稳定迭代后，反复用到的工作流是一组固定命令。我自己的习惯是每天早上先把自己负责的任务在Gitee的Issue里登记，然后开始开发，完成后执行：

git pull origin main git add . git commit -m "feat: 增加用户登录接口" git push origin main

先说git pull，很多人忽略它。团队协作时，远端main分支上可能已经有别人推上去的代码，直接commit会导致本地与远端分叉，push时才会被拒，然后又得临时处理合并，心态容易崩。先pull再commit，虽然不能完全避免冲突，但能把冲突控制在最新代码之上，解决起来直观得多。

再说commit message的规范。我之前也写过“改了一下”“update”这类信息，等到三个月后回看提交记录，完全不知道当时改了什么，只能一行行看diff。建议至少按这个格式来：

• feat: 新功能
• fix: 修复缺陷
• docs: 文档变更
• refactor: 重构
• chore: 杂项，如依赖升级

这个格式不是Gitee强制要求的，但配合Gitee的提交信息展示，能让整个协作过程的回溯成本大幅降低。

3.3 Release发行版与里程碑：让版本管理不止于分支

很多人以为版本管理就是打Git标签，但在Gitee的日常使用里，Release功能更贴近实际交付流程。在仓库的“发行版”页面，你可以把一个标签关联的代码包发布出来，配上发布说明、附件清单，别人下载你的项目时，看到的是清晰的历史版本列表，而不是一坨不知道能不能跑的源码。

操作上，发布一个Release之前先在本地或网页端打好标签。命令行方式更快：

git tag v1.0.0 git push origin v1.0.0

然后到网页端“发行版 → 新建发行版”，选择刚才的标签，填写标题和更新日志，就可以直接发布。如果你做的是二进制工具或前端打包产物，可以在Release里上传附件，Gitee会帮你托管，特别适合给用户提供免编译版本。

里程碑功能跟Issue强相关。一个严谨的团队可以在“里程碑”里定义v1.0、v2.0这类目标，把该版本要处理的Issue和PR都挂上去，版本进度一目了然。个人项目没必要用，但团队项目强烈建议启用。

4. 团队协作与项目管理：不只是放代码的地方

4.1 Pull Request工作流：怎么提、怎么审、怎么合

Gitee的协作核心是Pull Request机制。跟直接往main分支push不同，PR要求你先在一个独立分支上修改，再把改动提交为一次“请求合并”，由仓库管理员或其他成员评审后再合入主干。

一个标准的PR流程是这样的：假设你接到一个需求，要修改登录模块。

第一步，从最新main分支拉出一个功能分支：

git pull origin main git checkout -b feat/login-optimize

第二步，在功能分支上完成开发并提交。这里注意，提交message不必追求一次成型，可以多提交几次，但要让评审者能看懂每次提交的目的。

第三步，把功能分支推到Gitee远端：

git push -u origin feat/login-optimize

第四步，到网页端仓库页面，新建Pull Request，源分支选feat/login-optimize，目标分支选main，填写标题和描述。描述里建议写清楚“为什么做这个改动”“测试情况如何”，关联对应的Issue编号，比如“关联 #12”。

评审者可以在PR页面的逐行评论功能里给具体代码位置提建议，这比在聊天工具里口头review高效得多。2021年Gitee的PR页面还支持直接在线查看修改文件的diff，评论后提交者可以直接在本地继续修正并推送，PR会自动更新。

合并方式要选好。Gitee常见的合并方式有三种：“合并分支”保留所有提交记录；“压缩合并”把功能分支的所有提交浓缩成一个提交；“快进合并”只移动指针。对团队而言，压缩合并能让main分支历史保持整洁，每个PR对应一个提交，回溯时非常舒服。

4.2 看板与Issue：需求的落脚点和缺陷的登记簿

Gitee的“任务”功能其实就是看板，位置在仓库页面顶部导航。默认会有“待办、进行中、已完成”几个列表，你可以根据团队需要增减。把需求、缺陷、技术任务分别建卡片，拖拽流转，比用Excel记录强很多。

但我更想强调的其实是Issue的细节。Issue不仅是提bug的地方，更是一个团队的知识库入口。一个合格的Issue至少包含：问题描述、复现步骤、期望行为、实际行为、环境信息、相关日志。Gitee支持在Issue正文里添加标签、指派人、截止日期，也支持关联分支和PR。

一个常用技巧：提交代码时在commit message里写fix #12，Gitee会自动把该提交关联到Issue #12，当这个提交合并到默认分支时，Issue会进入待确认状态。这套联动逻辑跟主流平台一致，用好了可以省去大量手工同步成本。

4.3 分支保护与代码评审：防住手滑的最后一道闸

团队人数超过三个之后，直接往main分支push的风险就明显上升了。某位成员一次误操作，轻则需要回滚，重则覆盖别人的改动。Gitee的“分支保护”功能能限制普通成员对受保护分支的写入权限。

在仓库的“管理 → 分支保护”里，新增保护规则，选择main，勾选“不允许直接提交”或“必须发起Pull Request才能合并”。这样所有人修改main都必须走PR评审流程，等于给主干分支上了一把锁。

“必需评审数量”可以设为1，也就是至少有一个非作者身份的评审者通过才能合并。这个配置对小型团队尤其合适，既能保证关键代码有人看过，又不至于流程繁重到影响效率。

注意：分支保护规则对仓库管理员同样生效，如果你把自己锁在外面，可以在分支保护设置里临时调整规则。这属于管理操作，记得改完再改回来。

5. 高效使用Gitee的两个加分项：Pages部署与Go流水线

5.1 Gitee Pages：三分钟上线一个静态站点

2021年的Gitee Pages已经支持自定义域名、HTTPS证书自动配置和绑定多级路径。对于个人博客或者前端Demo来说，这是一个近乎零成本的托管方案。

用法非常简单：仓库根目录放好静态文件，比如index.html、assets/目录等，然后把代码推到Gitee。进入仓库的“服务 → Gitee Pages”，启动服务，选择部署分支和目录根路径，点更新即可。第一次部署会在几分钟内生成https://你的用户名.gitee.io/仓库名/这样格式的访问地址。

如果你用Hexo、Hugo这类静态博客框架，部署方式是在项目目录构建出静态文件目录，比如Hexo的public，然后把这个目录推送到Pages仓库的对应分支，目录设置里选public。注意Pages服务部署的必须是构建产物，框架源码不需要部署上去。

个人体会最深的坑：Pages站点域名变了或者想换绑自定义域名，要在Gitee Pages设置里配置CNAME文件并再次执行部署，而不是只在DNS解析里改。我遇到过一次设置完自定义域名但没更新仓库内CNAME文件，导致访问404的情况，排查了半天才反应过来。另外Pages服务需要实名认证，这个在1.2节已经提醒过了。

5.2 Gitee Go：轻量级CI流水线入门

Gitee Go是2021年对个人开发者非常重要的一个变化。以前想在Gitee上跑持续集成，必须接第三方CI平台，配置麻烦不说，构建记录还没有跟仓库深度融合。Gitee Go内置在仓库里，可以在每次push和PR时自动触发构建，跑测试、做检查、产出构建物。

配置入口在“服务 → Gitee Go”，第一次进入会引导你创建一个工作流文件。工作流文件放在仓库的.workflow目录下，格式是YAML，核心概念有三个：Job（任务）、Step（步骤）、Trigger（触发器）。

一个最简单的Java Maven项目的流水线配置文件可以长这样：

version: 1 jobs: build: steps: - init: commands: - echo "构建开始" - build: commands: - mvn clean package - upload: artifacts: - target/*.jar

每一步的含义：init负责准备环境，build执行实际构建命令，upload把产物保存到平台。配置好并提交后，每次push到远端，Gitee Go会自动运行该流水线，构建结果直接展示在仓库的“Gitee Go”标签页里。

我建议普通个人项目别一上来就搭复杂流水线，先跑通“构建→打包→上传产物”这条最小路径。等习惯了，再加测试步骤和通知配置。持续集成这东西，最怕一开始就设计过度，还没体验到便利，先被配置文件吓退。

6. 常见报错与排错经验速查

6.1 高频报错集合

以下是我在各个交流群里看到、以及自己踩过的常见问题汇总，按出现频率排序。

第一，Permission denied (publickey)。SSH密钥对不上。检查公钥是否已添加到Gitee后台，检查本地git是否用了正确的私钥，可以用ssh -T git@gitee.com排除。如果之前配过多把密钥，检查~/.ssh/config是否把特定域名指到了错误密钥，路径写错也是常见原因。

第二，Repository not found。仓库地址写错了、仓库是私有的而你没有权限、或者用了HTTP但没有正确带上用户名。SSH方式尤其要注意URL里的用户名和仓库名大小写是否完全匹配。

第三，failed to push some refs。远端有本地没有的新提交，常见的正确姿势是先git pull --rebase，把远端提交变基到本地之后再次push。--rebase比默认合并生成的提交历史好看，适合个人分支；如果是多人协作的共享分支，还是用普通pull比较保守。

第四，提交后Gitee的贡献图不显示。原因基本是本地Git的user.email与Gitee账号邮箱不一致。改回一致后，只对之后的新提交生效，历史的贡献记录需要用工具改写作者信息，操作成本高，所以从一开始就配好全局邮箱才是最优解。

第五，网页端编辑文件后本地push冲突。2021年Gitee的网页编辑功能确实方便，但远端修改和本地修改同时发生时，冲突无法绕过。除了常规解决冲突，也可以考虑约定：简单文案修改才用网页端，逻辑改动一律走本地+PR。

6.2 个人实操心得与建议

最后分享几条长期使用Gitee沉淀下来的习惯，谈不上标准答案，但确实帮我省了不少事。

一是推荐把常用的远端操作命令做成速查表贴在身边。不是说记忆不重要，而是Git命令太多，日常用得到的就那二三十条，与其死记硬背，不如随用随查。用得多了自然就记住了。

二是仓库的README文档不要偷懒。README不只是给开源用户看的，也是给自己三个月后回看的索引。开头的技术栈、运行方式、目录结构说明，全部写清楚，能极大降低维护成本。Gitee的README预览支持Markdown渲染，排版别堆大段文字，适当用标题、表格和代码块。

三是Issue优先于聊天工具。很多团队习惯在IM里发现问题、沟通需求，消息一多就沉淀不下来。我个人的转变是：凡是可以文字化描述的需求和缺陷，一律开Issue；IM里只讨论过程，结论必须回填到Issue。配合Gitee的看板和PR关联，整个研发过程都会有迹可循。

四是关注Gitee官方更新日志。2021年以来，Gitee的功能迭代明显加速，比如Gitee Go、Go+仓库、组织版、企业版的一些能力都在逐步开放。主动了解新特性，往往能发现一些之前绕路才能实现的场景，现在平台内置了。

五是定期手工备份重要仓库。虽然Gitee有稳定的云端托管，但“本地裸仓库备份+重要分支定时push”仍然是一个廉价且有效的容灾手段，尤其是那些不可再生的个人项目。备份不费什么事，但能在意外发生时救你一把。

这个平台用顺了之后，你会发现“代码托管”只是起点，围绕仓库的整个研发管理才是它真正值钱的部分。从2021年这个时间点开始用Gitee，正好能赶上它功能最完善的一段时期。