企业官网建设流程全解析

1. 为什么是 Gitee：国内团队协作的真实场景里，它是绕不开的一环

我见过太多新手的第一堂 Git 课是从 GitHub 开始的，注册账号、建仓库、推送代码，一切顺利。可一旦回到现实工作环境，问题就来了：访问速度时快时慢，私有仓库要收费，同事之间的协作延迟高得让人抓狂。这时候 Gitee（码云）就成了一根非常务实的救命稻草。

Gitee 是国内团队和开源社区里使用频率极高的代码托管平台，核心价值就三个：快、稳、不折腾。它提供的服务覆盖了 Git 仓库托管、代码审查、项目管理、CI/CD（持续集成）等环节，日常开发需要的功能基本都有。尤其是对国内中小团队、高校学生、个人开发者来说，Gitee 的免费私有仓库额度相当大方，不用担心写了一半的项目被围观。

这篇内容我打算从零开始，把从注册到日常协作的完整链路走一遍。哪怕你之前完全没碰过 Git，只要照着操作，也能把本地代码稳稳地托管到 Gitee 上。如果你已经用过一段时间但总在各种报错里打转，那也建议耐心看完全文，我在后面单独整理了一章踩坑实录，每一个问题都是我实际遇到并排查过的。

2. 开工前的三步准备：账号、空仓库和本地 Git 环境

2.1 注册账号与实名认证

这一步没什么技术含量，但有个细节值得注意。打开 Gitee 官网，点击注册，建议直接使用手机号注册，因为后续的实名认证、两步验证（2FA）绑定都和手机号挂钩。邮箱注册也可以，只是在找回密码和接收仓库相关通知时，响应路径会比手机号长一点。

注册完成后进入个人设置页面，建议优先完成实名认证。Gitee 对实名认证的要求相对宽松，但对于需要创建组织、开通企业版或参与某些开源项目贡献的场景，没有实名认证会卡住。认证过程就是填姓名和身份证号，几分钟就能过。这里没有隐私风险，平台本身的合规要求，放心填。

2.2 创建一个"干净"的远程仓库

登录后在页面右上角找到"新建仓库"入口。这一步很多人会纠结：要不要勾选"初始化仓库"选项？我的建议是：在刚开始学习 Git 或准备托管一个已存在的本地项目时，什么都不要勾选。

新建仓库页面有几个字段需要理解：

• 仓库名称：必填，建议使用小写字母和连字符组合，比如my-blog-system，不要用中文名和空格。原因是 Git 仓库名会出现在克隆地址里，中文名字在部分终端和 CI 工具中会引发编码问题。
• 路径：自动生成，一般和仓库名一致，因为它是仓库在 Gitee 服务器上的实际访问路径。
• 是否开源：勾选公开，其他人可见但不可直接修改；不勾选则只有你和被你添加的成员可见。个人练习项目建议先私有，等整理好了再改为公开。
• 初始化仓库：如果勾选了"使用 Readme 文件初始化"、"初始化 .gitignore"或"选择许可证"，Gitee 会自动创建一次提交（commit）。对于纯粹从零开始的场景这没什么问题，但如果你本地已经有一个完整项目准备推送，这个默认提交就会造成历史分叉，后面推送时大概率碰到冲突。

我第一次使用 Gitee 时就踩过这个坑，本地项目是一个做了一半的博客系统，远程勾选了 README 初始化，结果第一次推送就被拒绝。第一次接触 Git 的话，请记住：远程仓库最好保持完全空白。

2.3 本地 Git 环境安装：macOS、Windows、Linux 一套讲完

Git 的安装是分水岭操作，不需要复杂的配置，但环境装不好，后面所有命令都会报错。

Windows 系统：去 Git 官网下载 Windows 安装包，安装过程中所有选项保持默认即可。唯一需要注意的选择是默认编辑器，如果你不想用 Vim，可以选 Notepad++ 或 VS Code。安装完成后打开命令行，输入git --version验证是否成功。

macOS 系统：在终端里输入git --version，如果你的 Mac 没装过 Git，系统会弹出提示，按引导安装 Command Line Tools 即可。也可以用 Homebrew 安装最新版：brew install git，推荐这种方式，版本更新更方便。

Linux / Ubuntu / Debian 系：直接运行：

sudo apt update sudo apt install git

CentOS / RHEL 系则用：

sudo yum install git

安装后先做一次全局身份配置，这个步骤很重要却总有人跳过。Git 在你每一条提交记录中写入的用户名和邮箱，是团队协作中识别"谁写了这段代码"的依据。设置命令如下：

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

身份配置只影响提交记录，不影响 Gitee 账号的登录认证，也就是说邮箱可以不完全和 Gitee 一致。但建议保持一致，因为 Gitee 的个人主页会通过邮箱关联你的提交记录，一致后会自动在贡献日历上显示小绿点。

3. SSH 密钥：让电脑和 Gitee 免密互认的关键环节

3.1 为什么不用账号密码，而用 SSH

新手常常会问：Git 推送代码时不是输入 Gitee 的账号密码就行了吗？理论上可以，但 HTTPS 方式每次推送都要输入用户名密码。虽然可以设置凭据管理器记住密码，但很多时候到了陌生环境、换了电脑或使用 CI 工具，HTTPS 的密码验证就会变成障碍。另外，密码直接在终端输入存在被记录的风险，而 SSH 密钥是基于非对称加密的验证方式，安全性高得多。

SSH 密钥的工作原理可以用一个类比来理解：公钥是锁，私钥是钥匙。你把锁（公钥）放到 Gitee 服务器上，你本地的 Git 工具拿着钥匙（私钥）去开门，服务器验证锁和钥匙匹配，就放你进出。全程不需要传输密码。

3.2 生成密钥并添加到 Gitee

在终端输入以下命令生成密钥：

ssh-keygen -t ed25519 -C "你的邮箱"

推荐使用ed25519算法，比传统的rsa算法生成的密钥更短、安全性更高、验证速度也更快。一路回车即可，如果担心安全性可以设置一个 passphrase（口令），这样即使私钥文件泄露，别人也无法直接使用。生成完成后，终端会显示公钥的存放路径，一般在用户目录下的.ssh文件夹里。

然后查看公钥内容：

cat ~/.ssh/id_ed25519.pub

复制输出的全部内容，登录 Gitee，进入 设置 > 安全设置 > SSH 公钥，粘贴并起一个方便识别的标题，比如"我的工作电脑"。保存后，在终端验证是否生效：

ssh -T git@gitee.com

如果看到类似"欢迎使用 Gitee"的提示，就说明密钥配置成功了。这一步一次做完，之后这台电脑上所有 Git 操作都不需要再输密码，非常顺手。

4. 把本地代码送到远端：核心命令的完整闭环

4.1 初始化本地仓库：init 还是 clone，看场景选

现在开始正式的核心操作——让本地项目跟远程仓库建立联系。这里分成两种场景：

场景一：本地已有项目，Git 还未初始化

比如你正在写的某个项目，文件夹里已经有很多文件了，此时在项目根目录执行：

git init

这个命令会在当前目录下创建一个隐藏的.git文件夹，它就是 Git 的"记忆库"，所有版本历史都存在里面。该命令只初始化本地仓库，不产生任何远程关联。

场景二：从 Gitee 上复制一个已有项目到本地

这种场景直接用克隆（clone）：

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

克隆会同时完成两件事：拉取远程代码到本地，并自动配置好远程仓库地址。使用 clone 拉下来的项目，Git 已经把远程仓库地址存在了本地的.git/config里，不需要手动添加远端。新手最建议先走一遍这个流程，因为省去了remote add的环节，不容易出错。

4.2 三个核心命令：add、commit、push 是在做什么

如果你选择了 init 场景，上面这三条命令是必须理解的。很多新人一上来就只记住push，结果报错后一脸茫然，就是因为不理解这三个命令的分工。

git add是把"修改"加入暂存区（stage），可以理解为挑选要提交的文件。常见用法：

git add .

.表示把当前目录下所有改动过的文件都加入暂存。也可以精确指定文件：

git add src/main.py README.md

git commit是把暂存区的内容固化成本地的一次提交记录。这次提交是"本地"的，还没有上传到任何远程仓库：

git commit -m "完成登录功能开发"

git push才是把本地提交推到远程仓库：

git push -u origin master

-u参数的作用是建立本地分支与远程分支的关联，这样以后只需要输入git push或git pull，Git 就会自动关联。origin是远程仓库在本地 Git 中的默认别名，master是分支名。

4.3 第一次推送失败？多半是远程仓库不是空的

如果是本地已有项目、远程仓库也已经有内容（比如勾选了 README 初始化），推送时会报这样一个错误：

! [rejected] master -> master (fetch first) error: failed to push some refs to 'git@gitee.com:...'

这是因为远程和本地各自有独立的提交历史，它们没有共同祖先。解决办法有四条，按推荐顺序执行：

1. 远程仓库里没有任何有价值内容，直接删除远程仓库重新建一个空的，最干净。
2. 对远程内容不在意，又不想重新建仓库，强制推送：

git push -u origin master -f

-f（force）会强制覆盖远程的历史记录。但请只在确定远程内容不需要保留时使用。 3. 把远程仓库先拉取下来合并（merge），再推送。第一次出现分叉时合并很麻烦，新手不建议在这里浪费情绪。 4. 先把本地仓库的 Git 历史删掉，重新 init 后推送，效果和方案二类似，稍显繁琐。

实际操作中最推荐第一条：新建空仓库再推送。等以后真正理解了分支和合并，再处理分叉也不迟。

5. 托管只是开始：日常开发中真正高频的工作流操作

代码推送上去只是第一步，托管平台更大的价值在于让多人协作变得有序。这里分享几个日常开发中使用频率极高的操作，它们才是 Gitee 真正发光的场景。

5.1 拉取最新代码：pull 到底做了什么

团队合作时，别人的代码会不断推送上去。如果你还在本地基于旧版本修改，很容易产生冲突。保持本地代码同步的标准操作是：

git pull

git pull实际上执行了两个动作：从远程仓库拉取最新提交（fetch），再把远程的改动合并到当前分支（merge）。有些场景下，比如只想看远程更新了什么内容但还没决定要不要合并时，可以分开执行：

git fetch origin

fetch 只更新本地记录的远程分支状态，不影响当前工作区内容，是更保守的选择。

5.2 分支：让每个人都在自己的航道上干活

分支是 Git 用得最多的一个机制，不理解分支的 Git 使用是"残缺的"。场景化地讲：你要开发一个新功能，直接在主分支上改，万一改到一半发现思路错了，主分支就乱了。正确做法是开一条独立的分支：

git checkout -b feature-login

这行命令会创建并切换到一个名为feature-login的分支。你在该分支上提交的所有代码都不会影响主分支，等测试通过后再合并回主分支。合并操作在 Gitee 上通常是基于网页操作的，流程是：推送分支到远程后，在 Gitee 仓库页面的"合并请求"（Pull Request）里发起请求，指定要合并到哪个目标分支。

这个过程有一个明显的优势：代码审查。团队成员可以在网页上看到你改动的每一行代码，提出修改意见，确认无误后再合并。即使你是个人开发，也建议走一遍这个流程，模拟团队协作的节奏，对形成良好的代码习惯非常有帮助。

5.3 查看仓库全貌和提交记录：这些命令建议背下来

• git status：查看当前工作区的状态，比如哪些文件被修改了、哪些还没暂存。每次提交前务必先跑一下。
• git log --oneline --graph：查看提交历史，图形化展示分支走向和合并结构。
• git branch：列出本地的全部分支，当前分支前面会标星号。
• git remote -v：查看远程仓库地址，排查联想错误或用错仓库时非常管用。

这四组命令覆盖了日常 90% 的管理需求。它们不需要记死，用多了自然熟练。

6. 我踩过的坑：推送失败、密钥失效与空仓库的尴尬

6.1 密钥突然失效的排查链路

有一次我换了新电脑，把之前备份的密钥文件放到了~/.ssh目录，结果推送时一直提示权限不足。当时花了不少时间排查才确认，问题出在备份密钥文件的权限过于宽松。SSH 对私钥文件权限要求很严格，如果私钥文件对"组用户"或"其他用户"也有读权限，SSH 会直接拒绝使用。

解决方案是收紧权限，Linux / macOS 下执行：

chmod 600 ~/.ssh/id_ed25519

Windows 系统的用户可能需要检查文件属性，确保只允许当前用户读取。这个问题不常见也不容易想到，建议遇到密钥类报错时先检查文件权限。

另一个导致密钥失效的常见原因是：曾在多台电脑上生成过不同密钥，Gitee 上只添加了最后生成的公钥。换电脑后，新电脑上没有对应私钥，自然验证不过。解决办法是在每台需要推送代码的设备上单独生成密钥并分别添加到 Gitee。Gitee 支持同时维护多个公钥，按设备命名区分即可。

6.2 推送被拒绝不是世界末日：non-fast-forward 错误详解

前面提到过第一次推送时的! [rejected]错误，这里展开讲讲原因。Git 的推送本质上是把本地的提交记录追加到远程分支的末端。如果发现远程分支上有本地没有的提交记录，而且是"分叉"状态（即双方从某一个共同祖先开始各自产生了新提交），Git 会拒绝推送以保护远程数据。

表现就是non-fast-forward错误。处理思路是先拉取再推送：

git pull origin master git push origin master

如果拉取时出现合并冲突（两个人都改了同一个文件的同一行），Git 会中止合并，该文件会带有冲突标记（<<<<<<<、=======、>>>>>>>）。这时候需要手动编辑文件：保留你想要的内容，删除冲突标记，然后重新git add和git commit。有冲突不丢人，处理冲突本身就是 Git 日常的一部分，遇到一次就会了。

6.3 .gitignore 没配好：把 Node 依赖卷进仓库的尴尬

还有一种托管时的常见麻烦，是把不该管理的文件推上去了。比如 Node 项目的node_modules文件夹、Python 项目的venv虚拟环境目录、编译产生的.class文件。这些文件体积大且每次都在变化，如果推送到 Gitee 会造成仓库臃肿、每次 clone 都痛苦万分。

解决办法是在项目根目录新建.gitignore文件，逐行列出需要忽略的目录和文件。Gitee 在新建仓库时提供的模板可以从基础规则继承，也可以手动补充。一个经常被忽视的细节：如果你是先提交后补 .gitignore，之前已经加入版本控制的文件不会自动被忽略。此时需要把已跟踪的缓存清除：

git rm -r --cached node_modules git commit -m "移除已跟踪的依赖目录"

--cached参数表示只从 Git 索引中移除，不会删除工作区文件。补完这一步，仓库会瞬间清爽很多。

6.4 大型文件不能硬推：了解 Gitee 的仓库容量边界

Gitee 对单仓库容量有明确限制，免费用户一般有 1GB 上下（具体以平台最新规则为准）。某些文件，比如打包好的安装包、视频素材、设计原稿，一旦加入 Git 历史，即使后面删除了，历史记录里的"大块头"依然占用容量。

如果项目包含大文件，建议优先考虑 Gitee 提供的 Git LFS（Large File Storage）扩展。启用方式是安装 Git LFS 后，在项目中指定哪些类型的大文件走 LFS 存储：

git lfs install git lfs track "*.psd" git lfs track "*.zip"

然后正常 add、commit、push 即可。LFS 的文件内容会被 Gitee 单独存储，不会直接撑爆你的 Git 历史，clone 速度也会变快。这个习惯越早养成越好，等仓库膨胀到几 GB 再来处理就非常被动了。

7. 从托管到管理：在 Gitee 上维护一个健康项目的几个习惯

代码托管不是终点，仓库维护才是持续的过程。根据我和团队多年使用 Gitee 的实际经验，有几个习惯建议大家从第一次创建仓库时就建立起来。

习惯一：写好 README。README 是仓库的门面，也是协作的入口。一份合格的 README 至少包含：项目简介、运行环境要求、安装启动步骤、目录结构说明。如果你做的是开源项目，还要写清楚如何参与贡献。Gitee 会自动渲染 markdown 格式的 README 文件，效果很直观。

习惯二：提交信息要有规范。提交信息（commit message）不是写给自己看的，是写给未来所有维护者看的。建议格式为"类型 + 简要描述"，比如feat: 新增用户注册接口、fix: 修复登录状态失效问题、docs: 更新 API 文档。这样通过git log --oneline就能快速检索到每次改动的意图。

习惯三：设置分支保护。在 Gitee 仓库的"管理"页面可以设置分支规则。建议把主分支设为"受保护分支"，这样任何人的推送都必须通过合并请求来合入，防止直接推送脏代码。个人项目可能觉得没必要，但团队协作时这几乎是必须的，它能让每行代码都经过确认。

习惯四：关注 Gitee 的自动部署能力。Gitee 内置了 Gitee Go 持续集成服务，配合 WebHook 可以在每次推送到指定分支后自动触发构建和部署。对个人开发者来说，这意味着托管代码之后，还能免费获得一条轻量级的自动化部署流水线。配置方式不算复杂，官方文档有详细说明，这里不详细展开了。

习惯五：定期清理已合并分支。功能分支合入主分支后，远程分支就没有保留价值了。本地删除用git branch -d 分支名，远程删除用git push origin --delete 分支名。保持仓库分支列表干净，多人协作时能找到目标分支，也避免误用旧代码。

这些习惯没有一项是复杂设置，但它们组合起来的效果，是让你的 Gitee 仓库从"一个存代码的地方"变成"一个可以长期维护、协作顺畅的项目载体"。

我个人的实际体会是，Gitee 最舒服的地方不是某个特定功能多强大，而是整套流程对国内网络环境和团队协作习惯都很友好。从最初创建空仓库的手忙脚乱，到后续每天稳定地 pull、push、开分支、提合并请求，这套工作流已经成为日常开发中最顺手的部分。如果你目前还在用网盘或 U 盘备份代码，看完这篇就动手搭一个仓库吧，代码托管这个习惯，坚持一个月后你会觉得完全离不开了。