企业官网建设流程全解析

如果你是国内开发者，相对不太依赖海外网络环境、又希望代码托管平台的访问速度足够稳定，同时保留完整的协作、发布和自动化能力，Gitee 大概率是你绕不开的那个选项。我最早是从个人博客的静态托管开始接触 Gitee 的，后来逐步把模拟项目和团队内部工具都迁了过来，前后也踩过不少坑，比如 push 被拒、换行符告警、保护分支误伤自己这类问题，都遇到过。这篇文章就结合我自己的实际操作经历，从账号配置、日常 Git 工作流、团队协作、自动化流水线到高频问题排查，尽量把 Gitee 讲透一点，适合刚上手 Git 的新手，也适合准备把团队项目整体迁到国内平台的技术负责人参考。

1. Gitee 在国内开源协作中的角色定位

1.1 为什么选择 Gitee 而不是其他平台

很多人第一次接触代码托管，首选是 GitHub，但实际用下来会发现几个现实问题：访问速度不稳定、中文社区讨论氛围不够浓、部分插件和镜像服务偶尔不可用。Gitee 作为国内开发者常用的代码托管平台，最大的三个优势就是：访问快、中文友好、平台功能更贴合国内团队的使用习惯。

这里说的“快”不只是网页打开快，更重要的是git clone、git push这类高频操作在境内网络环境下的延迟表现。以我实际测试为例，同一份仓库，在某个海外平台上 clone 可能需要几十秒甚至更久，而在 Gitee 上基本就是秒级完成。对日常开发和持续集成来说，这个差距直接影响了开发体验。

Gitee 的协作模型和 GitHub 类似，都围绕仓库、分支、Pull Request 展开，但 Gitee 在开源运营层面做了不少本地化设计，比如 Gitee 推荐、开源组织认证、项目看板等。如果你准备做一个面向国内用户的开源项目，或者企业内部需要一个访问稳定的代码托管系统，Gitee 都是很合适的选择。

1.2 Gitee 的功能全景：不只是代码仓库

很多人对 Gitee 的印象还停留在“国内版 GitHub”，但其实它的功能已经非常庞杂了。我常用到的有这么几块：

• 代码托管：Git 仓库管理、分支管理、Tag/Release 发布，支持 HTTP/HTTPS/SSH 协议。
• 项目协作：Pull Request、Issue、Wiki、里程碑、任务看板、代码审查，基本覆盖了小型团队的完整研发流程。
• 文档与展示：Gitee Pages 可以挂载个人博客、项目文档站，支持 Jekyll、Hexo 等静态站点生成器。
• 自动化：Gitee Go 提供持续集成/持续部署流水线，支持编译、测试、构建镜像、部署到服务器。
• 安全与质量：代码扫描、敏感信息检测、安全漏洞检测、质量分析报告。
• 企业服务：企业版支持私有化部署、权限细粒度管理、审计日志。

这些能力组合起来，一个团队其实可以完全脱离海外平台，只用 Gitee 就完成从需求管理、代码开发、测试发布到文档展示的整个闭环。

1.3 什么样的项目最适合用 Gitee

不是所有项目都适合放在 Gitee，我个人的判断标准是：

• 主要用户和贡献者在境内，访问速度敏感。
• 项目资料涉及非公开信息，但又不想自建 GitLab。
• 团队规模不大，希望免费获得整套协作工具。
• 需要一个稳定可访问的静态站点托管方案，比如个人博客、开源文档。

反过来说，如果你的项目需要大量海外开发者参与，或者重度依赖海外生态插件，那 Gitee 做镜像同步会是更合理的用法，而不是完全替代。我自己就是采用“Gitee 作为主仓库、海外平台做同步镜像”的策略，两边都能覆盖到。

2. 从零到一：账号创建与开发环境配置

2.1 注册账号与仓库创建

注册流程没什么好说的，一个手机号或邮箱就行。注册完成后建议第一时间补充个人资料、设置头像，并开启两步验证，密码安全和登录保护都别跳过。因为仓库一旦涉及公司业务代码，账号被盗不只是丢代码的问题，还可能泄露内部敏感信息。

创建仓库时需要注意几个字段：

• 仓库名称：建议全小写，用连字符-分隔单词，比如my-blog，比下划线更通用，也方便 URL 访问。
• 仓库描述：一两句话说明项目是干什么的，这个描述会显示在个人主页和仓库列表里。
• 私有/公开：如果项目还没准备好公开展示，先选私有，等代码稳定了再改公开。Gitee 的私有仓库对普通用户也有数量限制，需要留意是否符合需求。
• 初始化文件：建议勾选 README 和 .gitignore，License 按项目实际情况选。我一般会勾选 README，方便 clone 下来直接看到项目说明。

创建完成后，页面会直接展示 git 操作命令提示，这时候本地还没配置好，先别急着抄命令，下一步把本地环境收拾干净再说。

2.2 Git 本地环境配置与换行符问题的提前规避

无论是 macOS、Windows 还是 Linux，都需要先安装 Git。Windows 用户安装时注意选择“调整 PATH 环境变量”的选项，否则命令行里找不到git命令。安装完成后，打开终端做全局配置：

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

这两条配置会写入提交记录，以后每次 commit 都会带上这些信息。Gitee 的贡献统计也是靠这个识别的，所以务必和你 Gitee 账号绑定的邮箱保持一致，否则提交虽然能推上去，但不会关联到你的 Gitee 账号头像和贡献图。

接下来建议顺手设置一下换行符处理和默认分支名，这两个是新手最容易忽略的坑：

git config --global core.autocrlf input git config --global init.defaultBranch main

第一条配置是为了避免 Windows 和 Linux 之间换行符差异导致的“整个文件被修改”假象。第二条配置是让新仓库默认分支叫main，和 Gitee 创建仓库时的默认分支保持一致的节奏。等到后面团队协作时，分支命名混乱的问题会少很多。

2.3 SSH 密钥和 HTTPS 令牌：两种认证方式的取舍

Gitee 支持 HTTPS 和 SSH 两种推送协议，我推荐优先配置 SSH，尤其是经常从命令行操作的用户。HTTPS 虽然第一次用起来简单，但每次 push 都要输入账号密码，而且密码输入得多了很容易被终端记录历史，安全性和便利性都一般。

生成 SSH 密钥的命令：

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

一路回车，密钥默认生成在~/.ssh/目录下。然后用下面的命令查看公钥内容：

cat ~/.ssh/id_ed25519.pub

把输出的全部内容复制，打开 Gitee 的“安全设置 -> SSH 公钥”页面，粘贴保存。之后本地 clone 仓库时选择 SSH 地址，例如：

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

第一次连接会提示确认主机指纹，输入yes回车即可。如果用了多个平台账号（比如 Gitee 和 GitHub 同时用），可以在~/.ssh/config文件里配置不同 Host 使用不同密钥，避免互相干扰。

如果实在想用 HTTPS，建议在 Gitee 后台生成私人令牌，用它代替密码。令牌的好处是可以精确控制权限范围和有效期，泄露了也可以在后台单独吊销，不用改密码。

2.4 第一次推送代码到 Gitee

本地已有项目目录，但没有和 Gitee 关联时，操作流程是这样的：

cd 项目目录 git init git add . git commit -m "feat: 初始化项目" git branch -M main git remote add origin git@gitee.com:用户名/仓库名.git git push -u origin main

这里解释一下每一步的意图：git init是初始化本地仓库；git add .把当前目录所有文件放进暂存区；git commit生成一个提交记录；git branch -M main把当前分支重命名为 main；git remote add origin是把本地仓库和远端仓库建立关联，origin是远端仓库的默认别名；git push -u origin main则是把本地 main 分支推送到远端，同时记录上下游关联关系，以后直接敲git push就能推送。

如果你在 Gitee 创建仓库时已经勾选了 README，那么本地仓库和远端仓库的历史是不一致的，直接 push 会被拒绝。这种情况建议先拉取合并：

git pull origin main --allow-unrelated-histories

代码仓库的完整历史是开发过程中最有价值的资产，尽量不要用git push -f强行覆盖远端记录，除非你清楚知道自己在做什么，并且团队只有你一个人。

3. 日常开发中的 Git 工作流实战

3.1 一套适合 Gitee 的日常分支模型

带团队之后，分支模型和建议策略是特别重要的基础规则。Gitee 本身不限制分支怎么建，但团队协作如果没有约定，很容易出现直接在 main 上开发、提交信息混乱、版本发布没有记录的情况。

我建议个人项目或小团队采用一套简化的 Git Flow：

• main：长期稳定分支，始终是可发布的版本。
• dev：日常开发集成分支，所有新功能先合到这里。
• feature/*：功能分支，比如feature/login。
• fix/*：修复分支，比如fix/header-bug。

日常开发流程是：从dev拉一个新分支，开发完提交，然后向dev发起 Pull Request。确认代码没问题后再合并。发布时再从dev合并到main，并在 main 上打 Tag。

这套流程的好处是 main 分支永远干净，任何时候都能拉出来发布；feature 分支之间互不干扰；代码审查有明确的对象。坏处是多了几个分支管理动作，但对团队来说，这部分成本远小于直接提交 main 带来的混乱。

3.2 保护分支与提交信息的规范化

Gitee 的仓库设置里可以配置“保护分支”，被保护的分支不能被直接 push，只能通过 Pull Request 合并。这个功能我强烈建议开启，尤其是 main 分支。

开启保护后的效果是：团队成员无法绕过审查直接改动主干代码，所有改动都有提交人、审查人和合并记录，后续追溯问题会非常容易。

提交信息规范同样重要。我团队内部约定的是：

feat: 新增用户登录页面 fix: 修复列表在移动端样式错乱的问题 docs: 更新 README 使用说明 refactor: 重构用户信息查询逻辑 style: 调整代码格式，无逻辑变化 test: 补充登录接口单元测试 chore: 更新依赖版本

这种统一格式用git log --oneline查看时非常清晰，配合 Gitee 的提交动态，review 代码的人也更容易理解改动意图。

3.3 Tag 和 Release：版本发布的完整记录

版本发布如果只用 commit 记录，时间久了很难快速定位某个版本对应的代码快照。我每次发布版本都会打 Tag，并在 Release 页面补充发布说明。

打 Tag 有两种方式，推荐带注释的格式：

git tag -a v1.0.0 -m "版本 1.0.0：正式发布基础功能" git push origin v1.0.0

推上去之后，Gitee 仓库右侧会出现 Tags 列表。然后在 Releases 页面新建一个 Release，关联这个 Tag，填写标题和说明。

Release 页面还可以上传二进制包、安装包。比如我做过一个跨平台的桌面工具，就是把 Windows、macOS、Linux 三个平台的压缩包直接传到 Release 附件里，使用者不用自己编译，下载解压即可运行。对个人开发者来说，这等于免费拿到了一个简单的软件分发渠道。

版本号建议采用语义化版本规则：主版本号.次版本号.修订号。有破坏性变更时升主版本号，新增功能向后兼容时升次版本号，只修复 bug 时升修订号。

3.4 维护 CHANGELOG 的实用方法

很多项目 README 写得很漂亮，但 CHANGELOG 是空的。我建议每个项目维护一份 CHANGELOG.md，格式参考：

# Changelog ## [1.1.0] - 2025-01-15 ### Added - 新增用户注册功能 ### Fixed - 修复登录失败后页面无提示的问题 ## [1.0.0] - 2024-12-01 ### Added - 初始版本

如果一个版本改动很多，写起来确实费时间，但发布时面对用户反馈和技术支持，这份文档的价值会立刻体现出来。Gitee 的 Release 说明也可以直接从 CHANGELOG 里复制，一次维护，多处使用。

4. 团队协作与开源协作深度玩法

4.1 Pull Request 流程：从提交流到审查通过的完整闭环

Pull Request（PR）是 Gitee 协作的核心。它的本质是“请求仓库维护者把你分支上的改动合并进目标分支”，所有改动内容、评论、审查意见都集中在这个请求里，比直接 push 到共享分支安全得多。

一个标准的 PR 流程是这样的：

1. 基于目标分支（一般是 dev 或 main）拉出新的功能分支。
2. 编码、本地提交、推送分支到 Gitee。
3. 在 Gitee 仓库页面的“Pull Requests”标签页发起新的 PR。
4. 填写标题和描述，说清楚这次改了什么、为什么改、怎么测试。
5. 邀请团队成员进行代码审查，审查者可以在具体代码行上留言。
6. 根据审查意见修改代码，重新 push 到同一分支，PR 会自动更新。
7. 审查通过后点击合并，并选择合并方式。

Gitee 的 PR 描述支持 Markdown，我一般会写一个简单模板，包含“需求背景”、“改动文件”、“测试验证”、“相关 Issue”四个部分。模板可以在 Gitee 的仓库设置里配置，团队所有人发起 PR 时自动带上，能有效减少无效沟通。

合并方式需要注意的是：普通合并会保留所有提交记录，适合功能分支；Squash 合并会把多个提交压缩成一个，适合把一堆小修小改汇总成一条有意义的记录。我个人的习惯是 feature 分支用 Squash 合并，dev 合并到 main 时用普通合并，保留完整的发布记录。

4.2 Issue 驱动的开发模式：需求、任务和里程碑

Gitee 的 Issue 不只是“报 bug”的地方，它完全可以作为需求管理系统使用。我给团队定了一套简单的规则：

• 每个需求或 bug 建一个 Issue。
• Issue 标题用简洁的动宾短语，比如“用户登录页面增加验证码”。
• 描述部分写清楚操作步骤、期望结果、实际结果。bug 附带截图或报错信息。
• 通过标签分类：bug、enhancement、documentation、question。
• 通过里程碑把 Issue 关联到版本，比如“v1.1 迭代”，便于跟踪每个版本的交付范围。
• 开发者在建 PR 时在描述中关联 Issue 编号，比如“Fix #123”，合并后 Issue 会自动关闭。

跨部门和多人协作时，这个模式能减少大量“你是不是在改那个东西”的确认成本，所有任务状态在 Gitee 项目页面上一目了然。

除了 Issue 标签，Gitee 还提供“任务看板”，以卡片形式把 Issue 或任务排列在“待办 / 处理中 / 已完成”等列表中。看板对迭代规划特别直观，适合可视化地追踪一两个星期内要交付的任务。

4.3 Wiki：让项目文档跟着仓库走

Gitee 每个仓库都有一个 Wiki 空间。很多人忽略这个功能，但实际上它是项目文档最合适的位置。比起把文档丢在团队聊天软件里，Wiki 的优势是：和代码仓库强关联、天然支持多人编辑、有历史记录可以回滚。

我建议 Wiki 至少维护这几类内容：

• 项目架构说明：整体模块划分、技术栈选择。
• 开发环境搭建指引：依赖安装、本地启动步骤、常见报错解决。
• 部署上线手册：环境变量说明、构建命令、服务器目录结构。
• 常见问题 FAQ：把团队日常问得最多的问题沉淀下来。

Wiki 的编辑支持 Markdown，内容多了以后建议左侧目录层级按章节组织。和 README 的分工是：README 面向外部用户，写清楚项目是做什么的、怎么跑；Wiki 面向团队内部，写清楚架构细节和协同约定。

4.4 Gitee Pages：零成本挂载博客和文档站

Gitee Pages 是 Gitee 提供的一个静态站点托管服务，可以把仓库里的静态 HTML 文件直接暴露成一个可访问的网址。对于个人开发者来说，这是挂载博客、文档站、项目展示页最省事的方案。

我实际搭过一次 Hexo 博客，流程大概是：

1. 创建仓库，本地初始化 Hexo 项目，写好第一篇文章。
2. 执行hexo generate，生成静态文件到public目录。
3. 把public目录内容推送或者部署到仓库的 pages 分支。
4. 在 Gitee Pages 页面选择部署分支、目录，点击“启动”。

需要注意的是，Gitee Pages 部署可能需要实名认证，操作前先确认账号处于可用状态。另外，如果部署的是 Vue、React 这类单页应用，记得处理路由的base路径，否则刷新页面会出现 404。

Pages 服务还支持自定义域名，只要在仓库设置里绑定域名，再到域名服务商解析一条 CNAME 记录即可。我自己的一个项目文档站就是这么做的，整个部署过程十分钟内能完成，维护成本基本为零。

5. 自动化与进阶玩法：Gitee Go、Webhook、OpenAPI

5.1 Gitee Go：用流水线替代手动编译部署

团队项目一旦开始频繁迭代，手动编译、打包、上传服务器的路子就明显跟不上节奏了。Gitee Go 是 Gitee 提供的持续集成服务，可以监听仓库事件，自动运行流水线。

一个典型的前端项目流水线包括以下几个阶段：

1. 代码检出。
2. 安装依赖，比如npm install。
3. 运行测试，比如npm run test。
4. 构建产物，比如npm run build。
5. 部署产物，通过 SSH 上传到服务器，或者推送到对象存储。

Gitee Go 的配置文件是.workflow/pipeline.yml，写到仓库里就能被识别。我随手写过一个简化示例：

version: '1.0' name: frontend-build displayName: 前端构建流水线 triggers: push: branches: - main stages: - name: build displayName: 构建阶段 steps: - step: build displayName: 构建项目 type: Shell script: - npm install - npm run build - echo "构建完成"

配上流水线之后，每次 push 到 main 分支，Gitee 会自动构建，构建失败会立刻在仓库页面标红并通知到人。相比等团队成员手动报告“我这里编不过”，这套机制能提前拦截一大半质量问题。

Gitee Go 对普通用户的免费构建时长有限，但不复杂的项目基本够用。如果需要更大并发，可以考虑升级套餐，或者用流水线的 webhook 能力触发外部构建服务器，把负载转移到自己的机器上。

5.2 Webhook：让服务器自动同步最新代码

Webhook 的原理是：仓库发生事件（push、PR 合并、Issue 更新）时，Gitee 向指定 URL 发送一个 HTTP POST 请求，携带事件数据。我常用它来做服务器代码自动同步。

比如一个个人网站的源码放在 Gitee 私有仓库里，服务器想要每次更新后自动拉取最新代码。做法是：

1. 在服务器上写一个接收 webhook 的小服务，验证请求后执行git pull。
2. 在 Gitee 仓库设置里添加 webhook，填写服务器 URL。
3. 选择触发事件，比如 push。
4. 往仓库 push 一次，看服务器有没有自动拉取。

这里要注意两个点：一是 webhook 地址不要暴露给无关人员，否则别人可以恶意触发你的构建或部署流程，建议加一个自定义密钥验证；二是 webhook 请求是同步的，如果仓库很大或服务器网络慢，Gitee 可能会超时重试，所以 webhook 处理逻辑里建议先记录事件、返回成功，再在后台任务里执行拉取操作，避免同一事件被重复处理。

5.3 OpenAPI：用脚本批量管理仓库和成员

Gitee 提供了 OpenAPI 接口，可以获取仓库信息、创建 Issue、管理 PR、获取用户信息等。这意味着很多重复操作可以用脚本自动化。

举个例子，我需要批量查看一个团队全部公开仓库的最近提交时间，手动点开会很烦，用 API 就是几行脚本的事：

import requests headers = {'Authorization': 'token 你的私人令牌'} url = 'https://gitee.com/api/v5/user/repos' resp = requests.get(url, headers=headers) for repo in resp.json(): print(repo['full_name'], repo['updated_at'])

这类脚本的价值在于：它可以整合到自己的日常巡检工具里，定期检查仓库活跃度、分支清理情况、Issue 未关闭数量。合理的自动化不是炫技，而是把维护成本降下来，让你把精力花在实际开发上。

Gitee 的 API Key 可以在个人设置里生成，注意只授予必要的权限范围，不要把带全部权限的令牌写进公开仓库里的脚本中。

5.4 代码质量检测与安全扫描：上线前多一道防线

质量检测通常放在流水线里做，Gitee 也有对应的代码分析服务。我实际使用后最大的感受是：它能发现一些肉眼很难发现的低级错误，比如未定义变量、重复代码块、潜在的空指针风险。

安全扫描主要用于检测仓库里的敏感信息泄露，比如代码里硬编码的账号密码、密钥、Token。我见过不止一次开发者把数据库密码直接写在配置里然后推到公开仓库，这是极其危险的操作。Gitee 的敏感信息检测能把这些风险提前暴露出来，这和“上了生产环境出了问题再补救”是两套逻辑。

使用建议是：公开仓库一定开启安全扫描；私有仓库建议也开启，尤其是包含数据库配置、支付配置、鉴权相关代码的项目。检测不是万能的，它会漏报，也会误报，但作为第一道过滤网是称职的。

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

6.1 push 被拒、认证失败这一类高频问题

我在实际使用中遇到最多的几个错误，整理成一个速查表供参考：

这些错误绝大多数不是代码问题，而是 Git 工作流细节。排查的思路是：先看你用的协议是 SSH 还是 HTTPS；再看远端地址是否拼写正确；接着检查本地当前分支名和远端目标分支是否一致；最后看有没有未拉取的远端提交。

6.2 冲突解决：别慌，按步骤来

合并分支或 pull 时出现冲突是正常现象，我第一次遇到时也紧张过，后来发现流程固定了就好办。举个实际场景：两个开发者同时改 README 文件的不同段落，后 pull 的那个人肯定会看到冲突提示。

解决过程分三步：

git pull origin main # 提示冲突的文件，比如 README.md

第一步，打开冲突文件，搜索<<<<<<<、=======、>>>>>>>标记。<<<<<<< HEAD到=======之间是当前分支内容，=======到>>>>>>>之间是远端分支内容。

第二步，手动保留想要的内容，删除所有冲突标记符号。

<<<<<<< HEAD 当前分支的内容 ======= 远端分支的内容 >>>>>>> main

比如这段内容，要么全保留、要么选择其一、要么拼接成一个完整版本，删掉标记行。

第三步，保存文件，重新添加到暂存区并提交：

git add README.md git commit -m "merge: 解决 README 冲突" git push

冲突解决的关键是：一个文件一个文件处理，不要用自动合并方案直接全部覆盖，因为自动方案可能导致原本有意保留的内容被丢弃。如果实在拿不准，就先备份整个文件，再开始改动。

6.3 超大文件和 LFS 大文件存储

Git 本身不太适合存二进制大文件，一个几十兆的文件会让.git目录迅速膨胀，每次 clone 都要下载这些历史版本，团队速度会被拖垮。Gitee 对大文件有单个文件大小限制，超出限制的推送会被拒绝。

解决方案是 Git LFS（Large File Storage）。它的思路是：用 Git 维护一个文本指针，真正的二进制内容存储在 LFS 专用空间里，clone 时按需下载。针对设计稿、安装包、模型文件这类资源很适用。

启用流程：

git lfs install git lfs track "*.psd" git add .gitattributes git commit -m "chore: 启用 LFS 管理设计文件"

之后正常 add、commit、push 即可。Gitee 对 LFS 也有容量配额，免费档不能满足的需求要考虑清理历史大文件，或者把大文件放到对象存储，用链接引用，而不是塞进仓库。

6.4 从其他平台迁移到 Gitee 的踩坑记录

从 GitHub 迁移到 Gitee，最直接的方式是走 Gitee 的“导入仓库”功能。导入后建议检查四件事：

第一，分支保护规则是否保留。导入可能只会迁移代码和 Issue，分支保护、PR 审查规则这类设置要重新配。

第二，Git LFS 关联是否完整。如果原仓库用了 LFS，导入之后要重新检查 LFS 文件有没有被正确拉取。

第三，Webhook、流水线这些配置通常不会自动迁移，需要在新仓库里重新创建。

第四，本地origin远程地址要更新。迁移之后如果本地还是指向原来的平台，push 就等于推回了旧仓库，容易造成两边不一致。

我的建议是：正式切换前先在 Gitee 导入一份，本地git remote set-url origin切到新的地址，先跑通整个流程，再对旧仓库做只读处理，避免迁移过程中两边同时改动。

还有一个容易忽略的细节：迁移之后的提交记录会保留原来的作者邮箱和用户名，这没有问题。但如果原来的邮箱和你的 Gitee 账号邮箱不一致，Gitee 会显示不出头像，代码贡献统计也可能失败。可以通过git rebase全量重写作者信息，但会影响历史提交时间戳和哈希值，建议在项目发布稳定后谨慎操作。我个人遇到这类情况时，一般只在少数几个项目上重写过，并不会漫无目的地使用强制手段。

结尾：我的实际使用体会

用了几年 Gitee 之后，我对它的定位有了比较清晰的判断：它不一定比海外平台更花哨，但在“国内团队协作”这个场景下，它确实是最顺手的工具之一。我自己的项目几乎都是 Gitee 做主仓库，配合 Pages 挂文档、Gitee Go 跑构建，微信通知绑定在 webhook 上，整个协作链路完全跑在国内网络环境里，稳定省心。分享一个我自己的小习惯：每次新建项目，一定先把 README、CHANGELOG、LICENSE 和 .gitignore 这四个文件整理好，再开始写业务代码。一个仓库的门面，往往就决定了别人愿不愿意使用和贡献。最后提醒一点，无论用 Gitee 还是其他平台，做好权限管理、备份机制和敏感信息保护，比学会任何高级命令都重要。