Gitee上传文件实战：从Git基础到命令行推送全流程

1. 从零开始认识代码托管和上传的本质

很多刚接触开发的朋友第一次听到"上传文件到Gitee"时，会下意识觉得这和把照片传到网盘差不多。其实两者有着本质区别：网盘强调的是"存文件"，而代码托管平台强调的是"管版本"。Gitee（国内开源社区常用的代码托管平台）基于Git版本控制系统，它记录的不只是文件的最新状态，而是每一次修改的历史轨迹。换句话说，你每次上传文件，本质上是在写一条"项目变更记录"。

这个区别带来了一个很实际的后果：上传文件到Gitee，并不是简单地把文件"丢"到网站上，而是需要理解仓库（Repository）、提交（Commit）、推送（Push）这三个核心概念。仓库是你的项目在服务器上的存储空间；提交表示你本地完成的一次修改快照；推送则是把本地的提交记录同步到远程仓库。这个流程一开始会觉得绕，但一旦理解了，就会发现它比网盘式的文件管理可靠得多——文件丢失了可以找回，改错了可以回滚，多人协作时也不会互相覆盖。

我在给团队新人做培训时，几乎每次都遇到同一个问题：新人把Gitee账号注册好了、仓库也建好了，但下一步就卡住了——他们不知道"上传"这个动作到底应该在哪里完成、用什么方式完成。其实Gitee支持两种上传路径：一种是通过网页端直接拖拽上传，适合零基础和小文件场景；另一种是通过Git命令行或图形化工具完成标准流程，适合项目级开发场景。本篇文章会把这两条路都走一遍，并重点讲解Git命令行方式，因为这才是开发工作中真正高频使用的技能。

无论你是因为课程作业需要提交代码，还是团队协作项目要管理分支，又或者只是想把本地的一个项目做个云端备份，这篇文章都适用。我会从注册登录开始，一直讲到分支切换、常见报错排查，全程使用最通俗的表达，同时保证每一步都有足够的细节支撑，让你能照着操作就能成功。

2. 准备工作：账号注册、仓库创建与本地环境配置

2.1 注册账号与创建第一个仓库

Gitee的注册流程非常简洁：打开官方网站，点击右上角的注册按钮，支持手机号或邮箱注册两种方式。考虑到账号安全，建议完成实名认证，这一步在创建私有仓库时是必备条件。注册完成后进入首页，右上角有一个"+"号按钮，点击后选择"新建仓库"，这时会进入仓库信息填写页面。

仓库名称建议使用能清晰表达项目用途的英文短词组，例如 demo-project、data-analysis-tool、blog-backup。路径名会作为仓库访问URL的一部分，创建后不建议频繁修改。仓库介绍可以简单填写一两句话，说明这个仓库是干什么的。可见级别有私有和公开两种：私有仓库只有你和被邀请的协作者能看到；公开仓库所有人都可以访问。企业内部项目或作业代码通常建议选私有，开源项目则选公开。初始化仓库时，建议勾选"初始化仓库"选项中的README文件，这样仓库会自带一个说明文件，在后续操作中更方便验证上传是否成功。

注意：仓库一旦创建，其路径名和可见级别可以修改，但修改路径名会导致旧的克隆地址失效。团队协作时，尽量在项目启动前确定好仓库名称，避免中途更改。

2.2 安装Git并完成基础配置

网页端上传可以处理零散的小文件，但一个结构化项目动辄几十上百个文件，这时就必须借助Git客户端了。Git的安装对系统有不同路径：Windows用户可以在Git官网下载安装包，一路默认选项即可；macOS用户建议先安装Homebrew，然后通过 brew install git 安装；Linux用户在自己的发行版软件源中直接安装，Debian/Ubuntu系用 sudo apt install git，RedHat/CentOS系用 sudo yum install git。

安装完成后，打开终端（Windows用户打开Git Bash），第一件事是配置用户名和邮箱。这个步骤不是可选的——Git在每次提交时都会把这两条信息写入提交记录，没有配置的话，推送操作会被直接拒绝。

bash复制git config --global user.name "你的名字"
git config --global user.email "你的邮箱@example.com"

--global 参数表示全局生效，意味着这台机器上所有仓库都会使用这套身份信息。如果你的不同项目需要不同身份，可以在具体仓库目录下去掉 --global，单独配置局部身份。验证配置是否生效，可以直接输入 git config --list，会输出所有已生效的配置项。

2.3 配置SSH密钥：实现免密推送的关键

在第一次推送代码之前，需要解决一个"身份认证"的问题。Gitee支持HTTPS和SSH两种远程连接协议。HTTPS方式每次推送都需要输入账号密码；SSH方式则通过密钥对完成认证，配置一次之后彻底免密，效率大大提高。我个人的建议是：哪怕你只打算传一两次文件，也值得花五分钟配置SSH，因为后续每次 git push 都会感谢这个决定。

生成密钥的标准命令是：

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

命令执行后，终端会询问保存路径和密码短语（passphrase），直接回车接受默认路径即可。密码短语建议不要设置——虽然设置后更安全，但每次SSH操作都会要求输入，反而降低使用频率。生成的默认位置在用户目录下的 .ssh 文件夹中，其中 id_rsa 是私钥，绝不能泄露给别人；id_rsa.pub 是公钥，需要配置到Gitee后台。

查看公钥内容用这个命令：

bash复制cat ~/.ssh/id_rsa.pub

会输出一串以 ssh-rsa 开头、邮箱结尾的长字符串，复制全部内容。然后打开Gitee网页端，进入个人设置 → 安全设置 → SSH公钥，把复制的内容粘贴进去，标题可以随便填一个方便识别的名字，比如"我的办公电脑"。这里特别提醒：公钥可以随便给，私钥一旦泄露就等于把仓库的写权限交给了别人，所以私钥文件绝对不要上传到任何地方。

配置完成后，可以先测一下连通性：

bash复制ssh -T git@gitee.com

如果看到欢迎语并提示你的用户名，说明SSH密钥配置已经成功，可以进入下一步了。

3. 网页端上传文件：零基础场景的快速路径

3.1 单文件上传：最快的一次提交体验

如果是零散的小文件上传，比如一个课程作业的说明文档、一份配置文件、一张项目架构图，网页端是最省事的选择。进入仓库页面后，找到文件列表上方的"上传文件"按钮，点击后会打开一个上传页面。这里支持直接把文件从本地文件夹拖拽到浏览器窗口，松开即可完成上传；也可以点击选择文件走传统的文件选择器。

上传页面的下方有提交信息输入框，这里填写的文字会作为本次提交的备注说明。很多初学者不知道这个框有什么意义，实际上Git的每次提交都应该有清晰的说明，方便日后回溯。比如上传第一个版本的说明文档，可以填"初始化项目说明文档"，不要填"上传文件"这种没有信息量的描述。填好后点击提交按钮，刷新仓库页面就能看到新文件出现在列表中。

实战建议：在提交信息中遵循一些常见规范，例如使用 feat:（新功能）、fix:（修复）、docs:（文档）等前缀。这种习惯在个人项目里就能带来很大便利，团队协作时更是基本要求。

3.2 批量文件上传的局限与场景判断

网页端也支持批量上传，一次可以上传多个文件，甚至可以上传整个文件夹的压缩包后在线解压。但这里我不推荐把网页端当作主要的上传工具，有两个原因。

第一，网页端无法保留完整的目录结构。如果你尝试把 src/components/Button.js 和 src/components/Input.js 这类深层目录通过网页端上传，会发现需要先在仓库中手动创建逐级目录，再逐层进入后上传文件，操作成本随文件层级急剧上升，还容易漏传。

第二，网页端上传的文件默认只有一次提交，无法精细控制"哪个文件属于哪一次改动"。而对于一个持续迭代的项目，提交粒度直接决定了你能否精准回溯历史。Git 的历史记录就像项目的日志和账本，一次提交只应该对应一个逻辑变更。

那么什么场景适合网页端？我认为是：文件数量少（个位数）、层级简单、不需要精细化版本管理的临时需求。只要文件规模超过两位数，或者存在目录嵌套，就应果断切换到Git命令行或图形化客户端。

3.3 在线编辑与新建文件

除了上传已有文件，网页端还支持直接在线新建文件、在线编辑已有文件。进入仓库目录后，点击文件列表上方的"新建文件"按钮，输入文件名和内容，填写提交信息后提交即可。这种方式适合快速修改README、微调配置文件等轻量操作。

需要注意，网页编辑器的功能有限，没有代码高亮、没有语法检查、没有自动补全。对于几行配置的改动来说足够，但对于成规模的代码编写，请回到本地编辑器完成，再通过Git推送上去。在线编辑保存后，也会生成一次新的提交，同样建议填写有意义的提交说明。

4. 命令行上传全流程：从本地目录到远程仓库

4.1 初始化仓库：git init 与本地目录的绑定

现在进入正题，这部分是开发场景中最常用的标准流程。不管你的项目是已经写了一万行代码，还是只有个空文件夹，流程从本地目录开始。打开终端，用 cd 进入项目根目录，然后执行：

bash复制git init

这个命令会在当前目录下创建一个隐藏的 .git 文件夹，它是Git的"大脑"，存放着这个仓库的全部元数据：提交历史、分支指针、配置信息等。执行完该命令后，当前目录就变成了一个Git仓库。注意，.git 文件夹存放在哪个位置，对应的仓库根目录就是哪个位置，不要把 git init 执行在错误的层级。

一个容易踩的坑：如果把项目放在桌面或文档目录下，锅里的各种系统文件、临时文件都可能被 git status 检测到。Git Kohärent 的机制是"提交什么由你决定"，而不是"目录里有什么就提交什么"，所以并不存在"多传了系统文件"的问题，但工作区会显得很乱。这也是为什么正式项目通常会准备一个 .gitignore 文件，把不必要的文件排除在版本控制之外。想省略这个纠结，最稳妥的做法是给每个项目单独建一个干净的目录。

4.2 远程仓库关联：git remote add 与地址选择

本地仓库创建好之后，需要把远程仓库地址告诉Git。远程仓库地址有两种格式：HTTPS格式是 https://gitee.com/用户名/仓库名.git，SSH格式是 git@gitee.com:用户名/仓库名.git。在Gitee仓库页面的"克隆/下载"按钮里，可以切换选择这两种协议。

关联远程仓库的命令：

bash复制git remote add origin git@gitee.com:用户名/仓库名.git

这里 origin 是远程仓库的默认别名，你可以理解为给远程地址起的一个小名。一个本地仓库可以同时关联多个远程仓库，分别用不同名字区分，这在需要往两个平台同时推送代码时非常有用。查看当前仓库关联了哪些远程地址，用 git remote -v，会输出每个远程别名对应的完整地址。

提示：如果你之前已经用HTTPS方式关联过远程仓库，现在想改成SSH方式，可以用 git remote set-url origin git@gitee.com:用户名/仓库名.git 直接修改，不需要删除后重新添加。

4.3 添加暂存区与首次提交：git add 和 git commit

这是整个流程中最核心、也最容易被新手上手时弄混的两个命令。先明确它们的分工：git add 把文件从工作区加入暂存区，git commit 把暂存区的内容固化成本地仓库的一次提交。可以把这个过程类比成超市购物，git add 是把货物放进购物车，git commit 是收银台结账——放进购物车不代表就是你的了，只有结了账才真正完成购买。

添加全部文件到暂存区：

bash复制git add .

这个命令会把当前目录下的所有变更（包括新建、修改、删除的文件）都加入暂存区。如果你只想添加某几个文件，可以用 git add 文件名1 文件名2 精确指定。添加之后，建议先看一眼状态：

bash复制git status

会以绿色显示已暂存的文件，红色显示尚未暂存的文件。养成每次提交前先看 git status 的习惯，能避免把不该提交的文件带进去。

确认暂存区内容无误后，执行提交：

bash复制git commit -m "初始化提交：添加项目基础结构和说明文档"

-m 参数后的引号内是提交信息。一次规范的提交信息应该说明"这次改动做了什么"，而不是简单的"更新"。如果提交后发现漏了几个文件，可以用 git commit --amend 把漏掉的文件补充到上一次提交中，但要特别注意，这个命令会改写提交历史，如果已经推送到了远程仓库并且是多人协作，就不要使用 --amend 来修改已推送的提交。

4.4 推送远程：git push 与首次推送 -u 参数

本地提交完成之后，代码还存在你的电脑上，只有执行推送命令，才会真正上传到Gitee服务器。首次推送的命令是：

bash复制git push -u origin master

注意这里的 -u 参数，它会把本地 master 分支和远程 origin/master 分支做绑定，建立"跟踪关系"。设置之后，后续再推送时就直接 git push，不需要重复指定远程仓库和分支名。就好比第一次见面交换了联系方式，之后就不用每次自报家门了。

执行该命令后，如果之前配置了SSH密钥且没有设置密码短语，推送过程是完全静默的，不会有任何交互提示，直接显示对象统计信息和写入完成信息。推送成功后，可以在本地执行 git status，会看到提示你的分支已与 origin/master 保持同步。

如果推送时看到类似 fatal: The current branch master has no upstream branch 的错误，说明本地分支和远程分支之间没有建立跟踪关系，用 git push --set-upstream origin master 就能修复。这个错误在从旧仓库迁移到新仓库时很常见。

4.5 日常更新的标准操作节奏

仓库建立并推送过一次之后，日常的文件修改就进入了一个固定循环：改文件 → 添加暂存 → 提交 → 推送。用一个真实场景来说明：我在本地写了一个数据分析脚本，今天对数据预处理部分做了优化。

bash复制cd ~/projects/data-analysis-tool
# 修改了 process.py 文件

git status          # 查看改动状态
git diff            # 查看具体改了什么内容

git add process.py  # 只提交这一个文件的改动
git commit -m "feat: 优化数据预处理流程，增加空值过滤"

git push

这里有一个值得养成习惯的细节：每次只提交逻辑相关的文件。比如你同时修改了一个脚本和一份文档，但两者的改动逻辑不同，就应该分成两次提交，而不是一次 git add . 全提交上去。这样后续定位问题时，能精确知道代码的哪个版本对应哪次历史记录。

5. 图形化工具与分支管理：提升上传效率的进阶技能

5.1 用SourceTree等图形化工具降低操作门槛

虽然命令行是能力上限最高的方式，但我理解有一部分读者对黑底白字的终端天然存在心理门槛。如果你觉得命令行的概念太抽象，完全可以借助图形化Git客户端。SourceTree（SourceTree是常见的Git图形客户端之一）、Tower、VSCode内置的Git面板都可以选用。SourceTree免费且支持Windows和macOS，加上Gitee的集成支持，个人体验下来是最友好的选择。

用SourceTree管理上传的流程很简单：先选择"Clone"输入Gitee仓库的SSH地址，把远程仓库克隆到本地。"Clone"与"init"的区别在于，clone会把远程已有的文件和历史记录完整复制到本地，相当于在一张已有内容的白纸上继续画；init则是从全空白开始。之后本地做的任何改动，SourceTree的界面都会实时显示哪些文件有变，勾选要提交的文件，填写提交信息，点击"提交"按钮，再点击"推送"按钮，两步操作即可完成。

图形化工具特别适合刚入门的同学观察Git的运行逻辑：界面上会直接展示本地分支和远程分支的位置关系，提交历史以图形化时间线的形式呈现，推拉操作变成直观的按钮点击。但我不建议长期停留在只用图形工具的阶段，原因在于：很多故障场景（合并冲突、误操作回滚、分支间同步异常）的最终解决都离不开命令行，图形工具在异常场景下的提示信息往往不够直观。最理想的路径是先通过图形工具建立全局认知，再逐步过渡到命令行。

5.2 理解主分支与功能分支的关系

当项目不再是一个人独享的玩具，而是多人协作的工程时，分支管理就变成了核心竞争力。这里讲一个最基础、但足以覆盖大多数协作场景的分支策略。

以主分支（通常是 master，Gitee新仓库默认为 master）作为稳定版本线，所有已经验证过的代码才允许合入主分支。开发新功能时，从主分支拉出一个功能分支：

bash复制git checkout -b feature-user-login

checkout -b 的含义是创建并切换到新分支。此时无论你在功能分支上如何折腾，都不会影响主分支的代码。功能开发完成并验证通过后，再合并回主分支：

bash复制git checkout master
git merge feature-user-login

合并完成后，把主分支的新变化推送到远程。之后删除功能分支，保持仓库清爽：

bash复制git branch -d feature-user-login

这套流程天然避免了"直接在主线冒充修改，改坏了所有人的代码"的局面。我在某高校的一个课程项目管理里看到过反面教材：五个助教直接在主分支上各自提交作业代码，完全平行无协作，结果代码风格混乱、功能互相覆盖，合并冲突每天都在爆发。后来花了一下午把几个人的代码分别迁到功能分支，冲突基本绝迹。

5.3 拉取远程更新：git pull 的正确姿势与冲突预防

多人协作时，"拉取"和"推送"同样重要。别人推送到远程的代码，你需要先同步到本地，再基于最新代码做修改。拉取命令：

bash复制git pull origin master

git pull 等价于 git fetch 加 git merge 的组合：先从远程下载最新提交，再把远程分支合并到当前分支。如果本地和远程在同一个文件的同一处都有修改，合并就会产生冲突，Git会在文件中标注冲突区域，形如：

code复制<<<<<<< HEAD
本地的修改内容
=======
远程的修改内容
>>>>>>> origin/master

这时候需要手动打开文件，选择保留哪部分内容，然后保存文件，再执行：

bash复制git add 冲突文件名
git commit -m "解决合并冲突"

一个可以大幅减少冲突的实操技巧：每次开始修改文件前，先执行一次 git pull 让本地代码同步到最新。修改完成推送到远程时，如果推送被拒绝（提示远程有本地没有的提交），不要用 git push --force 强推，而是先 git pull（或 git pull --rebase）合并远程改动，再重新推送。强推会覆盖远程历史，在协作场景下属于绝对不能碰的操作。

6. 常见问题排查：上传过程中踩过的坑与解决实录

6.1 推送被拒绝 "failed to push some refs"

这是新手遇到频次最高的错误。完整的报错通常是 [rejected] master -> master (fetch first) 或者 hint: Updates were rejected because the remote contains work that you do not have locally。原因非常简单直接：远程仓库里有你本地没有的提交记录，可能来自其他成员，也可能来自你在网页端在线修改产生的提交。Git出于安全考虑，不允许直接覆盖这些记录。

解决方案是先把远程更新合并到本地，再重新推送：

bash复制git pull origin master
git push origin master

如果是刚用网页端勾选了"初始化仓库"选项，然后又在本地执行了 git init 且做了首次提交，这个错误几乎必然会遇到。这种情况下，更推荐在本地直接完成首次提交后，再创建没有初始化内容的远程仓库，然后关联推送。

6.2 权限验证失败 "Permission denied (publickey)"

SSH密钥虽然已经在Gitee后台配置，但推送时仍然报权限错误，这通常有三种情况。

第一种是SSH协议地址写错，确认远程地址是 git@gitee.com:用户名/仓库名.git 而不是 https 开头的地址。第二种是公钥没有真正配置成功，回到Gitee后台核对公钥内容的行首是否为 ssh-rsa 且无多余空格或换行。第三种是公钥配置正确但SSH agent没有加载当前密钥，可以执行：

bash复制ssh-add ~/.ssh/id_rsa

然后重新测试 ssh -T git@gitee.com 验证。还有一种隐蔽的情况：电脑上存在多个SSH密钥，Git选择了错误的那个。排查方法是用 ssh -vT git@gitee.com 查看完整调试信息，定位实际使用的密钥文件路径。

6.3 文件大小超出限制 "File ... exceeds the file size limit"

Gitee对单个文件大小有明确限制，通常为100MB。如果你需要管理大文件，比如模型权重、游戏资源包、视频素材，不能直接按常规方式推送。Git本身的设计目标也不适合管理大型二进制文件，一个几百MB的视频被每次改动都保存完整副本，Git仓库的体积会爆炸式增长。

备选方案是 Git LFS（Large File Storage），Gitee也支持此功能。启用方式是在仓库根目录执行：

bash复制git lfs install
git lfs track "*.psd"
git add .gitattributes

之后以 psd 结尾的文件就会由LFS接管存储。但是要注意，LFS本身也有配额限制，超出后需要付费扩容。对于素材类文件，更务实的做法通常是采用云存储或网盘来托管，代码仓库只保留文本引用和说明文档。上传前，可以在本地检查文件大小，使用 ls -lh 逐个确认。

6.4 误提交密码等敏感信息怎么办

这个问题的处理没有任何"优雅"的捷径。如果你不小心把密钥文件、数据库密码、内部配置推上了仓库，即使立刻删除文件并重新推送，历史记录里依然完整保留着这些内容。任何拿到仓库访问权限的人，都能通过 git log 和 git checkout 翻出历史版本。

正确的处理流程分三步：第一步，立刻在Gitee网页端把该仓库的可见级别改为私有，同时重置所有可能在文件中出现过的密码、密钥，毫不犹豫，"可能泄露"一律当作"已经泄露"处理。第二步，在本地使用 git filter-repo 等工具重写历史，把这个文件从所有提交记录中彻底抹除。第三步，强推一次覆盖远程历史。这个操作会导致其他协作者需要重新克隆仓库，沟通成本高但必须执行。最根本的预防措施是创建 .gitignore 文件，把 .env、config.local.php 这类可能携带敏感信息的文件直接排除在Git管理之外。

6.5 冲突处理与"文件被别人删了"的场景

在协作中经常遇到这样的对话："我明明更新了代码，推送却说文件被删了，怎么办？"这通常是因为你在修改某个文件的同时，协作者把这个文件移动了位置或者改了文件名，合并时Git就认为文件产生了冲突。处理方法和前面提到的冲突流程一样，先 git pull，打开标注了冲突的文件，选择保留哪一侧的内容，然后提交并推送。

一个实用经验是：如果你们的项目是一个多人频繁修改同类文件（比如集中修改同一个配置文件）的场景，一定程度的冲突是绕不开的。减少冲突的有效方式不是技术，而是沟通——明确分工、及时同步，大家改不同区域的文件是整体最优解。

7. 上传策略与协作流程：一些个人的实际操作心得

7.1 关于首次上传方式的选择：网页端还是命令行

有一个问题我经常被问到："第一次把一个已有项目传到Gitee，到底该用网页端还是命令行？"我给的标准答案基本是：如果项目文件超过10个或存在目录结构，直接用命令行。网页端上传文件后，很多初学者会在本地又执行 git init，导致出现两份彼此没有关联的代码副本——Gitee网页上的算一份，本地Git仓库算另一份，这只会让情况更加混乱。

用命令行完成首次上传，我建议的这个流程可以稳定复现：

bash复制cd 你的项目目录
git init
git add .
git commit -m "首次提交"
git remote add origin git@gitee.com:用户名/仓库名.git
git push -u origin master

先在本地完成完整提交，再去远程仓库建立关联，这样远程仓库不会出现"空仓库+初始化文件+本地推送"叠加的复杂状态。如果你请别人帮忙或参考网上的教程，看到"上传文件"这一步被安排在远程仓库创建之后，本质上是允许你先有个空壳仓库，再从空壳出发填入内容——这和本地优先不是互斥的，只是入口不同。

7.2 一次提交只做一件事

这个原则怎么强调都不过分。我见过太多新人把"改A文件，修B bug，更新README，加了一张图"一次性提交。表面上看提交效率提高了，但半个月后回看历史时，你根本不知道这次提交到底干了什么。如果某个版本出现问题需要回滚，回滚之后又得逐项挑出哪些代码是真正需要回滚的，完全的混沌状态。

正确的做法是：改动相关、目的一致的内容放进同一次提交。比如今天修复了登录时的验证码bug，那么涉及的三个文件 login.js、verify.php、style.css 放进一个提交，提交信息写清楚"fix: 修复登录验证码不刷新问题"。如果把不相关的改动混在一起，将来做代码评审、异常定位、版本回退时都会多花数倍的时间。

7.3 临时保存工作进度：git stash 的妙用

一个真实场景：我正在功能分支上开发一个页面，改到一半，上级突然要求马上修复主分支上一个紧急bug。此时工作区还有很多未完成的改动，既不能直接提交（提交了会产生半成品记录），也不能直接切换分支（切换会导致未保存的改动交叉污染）。Git提供了 stash 命令解决这个困境：

bash复制git stash        # 把当前工作区改动暂存起来，工作区变干净
git checkout master
# 修复紧急bug并提交推送
git checkout 功能分支
git stash pop    # 恢复之前暂存的改动

stash 本质上是一个"临时寄存柜"，分分支存放，取回灵活。团队使用量并不高的一个操作，但个人效率提升的收益非常明显。它还衍生了 git stash list（查看暂存列表）、git stash drop（丢弃指定暂存）等子命令，有兴趣可以逐层挖掘。

7.4 提交信息里的常用习惯：feat、fix、docs前缀

给提交信息打"标签"这件事，看起来像是循规蹈矩的形式主义，实际坚持下来会发现回溯日志的体验差别巨大。推荐一套轻量的提交信息规范，不需要学很重的框架：

配合这套前缀，"翻阅Git日志找某次修改"就会变得非常轻松。用 git log --oneline 输出一行一条的提交记录，加上前缀的作用立竿见影。

8. 后续可以做的拓展：持续学习的几个方向

写到这一步，上传文件本身已经不是问题。但你可能已经发现，Git和Gitee的能力边界远不止"上传"这么简单。从目前这个基础出发，有四个拓展方向值得花时间去接触。

第一是Gitee的Issue和Pull Request流程。前者用于跟踪项目和需求，后者用于在分支开发完成后发起代码审查合并。这是开源协作的主流工作方式，代码不是简单地堆到一起，而是通过审查后进入主线。

第二是Gitee Pages，这个功能可以直接把仓库里的静态网页文件变成一个可访问的网站。个人博客、项目文档站、简历页都可以基于此托管。当一个项目做完之后，给它做一个Landed页面的体验会完全不同。

第三是Webhook。Gitee支持在特定事件（如push、Issue变更）发生时，向指定URL发送HTTP请求。配合自动化服务，可以实现"代码推送到Gitee后，服务器自动拉取并更新线上环境"的自动化部署链路。个人项目部署全流程打通的成就感，值得亲身体验。

第四是团队内部约定一套分支模型，从主分支 + 功能分支的基础组合，演进到包含开发分支、预发布分支、发布分支的更完整层次。项目规模和人数上来之后，这套约定会直接决定协作体验是天壤之别还是灾难现场。

最后分享一个我自己的习惯：每次新项目开始，不管最终能不能做完，都会先建立仓库并完成一次有效提交。这个动作就像给项目上了一根"存档线"。哪怕之后改得面目全非，随时可以回到初始版本，这种安全感会让人在开发时更大胆地尝试新方案。上传文件到Gitee，本质上就是给自己的代码一个安全的家，之后所有的折腾都有了兜底的退路。