你有没有经历过这种场景：电脑硬盘突然坏了，写了几个月的项目代码全没了；或者同一个项目，在办公室电脑和家里电脑各存一份，来回拷贝之后，连自己都分不清哪份才是最新版。如果你也和当时的我一样，被这类问题折腾到怀疑人生，那 Gitee（码云）托管代码是目前最省心的解决办法之一。这篇文章我会从注册账号开始，把“本地Git + Gitee云端仓库”这套工作流完整拆开，按实操顺序一步步讲清楚，适合刚接触代码托管的新手，也适合想把手头项目从“业余管理”切到“正规管理”的团队参考。
先明确一个概念：Gitee 是一个基于 Git 的代码托管平台，你可以把它理解成本地 Git 仓库的“云端集合点”。本地写代码，用 Git 管理版本，再把任意一个版本推送到 Gitee，这就算完成了一次托管。相比单纯放在网盘里，托管的优势是随时随地能同步、能回溯、能拉取，多人协作时还能清清楚楚看到每一行代码是谁改的。
1. Gitee到底是什么，为什么我们离不开它
1.1 托管代码的本质：给本地Git加一个“云端共用的中枢”
很多人第一次接触 Gitee，容易把它等同于“代码网盘”——传上去存个档。其实它的核心价值不是“存储”，而是“协同”。Git 本身是分布式的，每个开发者本地都有一份完整仓库，但如果没有一个公共的远程仓库，大家各自为政，“谁改了哪里”只能靠嘴对。而 Gitee 承担的就是那个“公共中央仓库”的角色：你本地提交后推送到远程，同事再把远程内容拉到自己本地。每一次同步都带着完整的历史提交记录，出了问题可以顺着提交记录往回找，随时恢复到任何一个历史版本。
这个过程和“网盘同步”有本质区别。网盘同步的是文件最终状态，而 Git 托管同步的是“文件的演化过程”。哪怕是半年后，你也能翻出某一天某一次提交中具体改动了哪些代码、提交说明是什么、作者是谁。这种可追溯性是代码托管最值钱的部分，项目越大越能体会到。
1.2 怎么选Gitee和GitHub：速度、私有仓库与协作场景都有哪些不同
很多人会问：GitHub 不是更主流吗，为什么还要用 Gitee？我的回答是：看主要场景。衡量时重点看三点。
第一是访问速度。在我们日常的网络环境下，访问境内平台的延迟通常更低，尤其是 clone 大仓库、频繁 push/pull 的时候，速度体感差别非常明显。Gitee 的服务器和文档都是中文，遇到英文不顺畅的开发者，光这一条就能省下很多时间。
第二是私有仓库的成本。个人开发者需要用到私有仓库时，Gitee 对个人项目基本是免费开放的，这一点对学习、做毕设、做内部工具的人来说很友好。你可以放心把不想公开的代码放上去，不用为“藏代码”付费。
第三是开源氛围的差异。GitHub 是全球开发者主要聚集地，如果你想把项目交给全世界的人看、接受国际社区的贡献，那它更合适。而 Gitee 在中文开发者圈子里有自己的一套生态，比如中文文档、国产开源项目、企业内网部署方案等。实际选择并不冲突，我认识不少开发者会把开源项目同时镜像到两个平台，各自承担不同角色。
2. 起步准备：注册账号、安装Git并完成初始配置
2.1 注册Gitee账号并绑定手机号
打开 Gitee 官网，右上角有“注册”入口。流程很常规，填写手机号、验证码、设置密码就行。这里想提醒一句：手机号尽量填经常能用到的，因为后续找回密码、二次验证都会用到。注册成功并登录后，如果平台提示你补充实名认证信息，按页面要求完成一次即可，通常一次认证后很多功能都能直接启用。
登录后的第一件事，我建议先完善个人资料，尤其是用户名和邮箱地址。Gitee 的仓库路径都会用到用户名，比如你的用户名是 zhangsan，那么仓库地址会类似https://gitee.com/zhangsan/demo-project.git。而邮箱地址关系到 Git 提交记录的归属识别，后面配置 Git 时要用同一个邮箱，否则你在本地提交了代码，推到 Gitee 后，贡献图和个人主页不显示提交记录，排查起来很麻烦。
如果想长期用 SSH 方式免密推送，这个阶段顺手把 SSH 公钥加上最好。在“安全设置”里找到“SSH 公钥”入口，然后打开本地终端生成密钥。
2.2 安装Git并配置用户名邮箱
Gitee 仓库本身跑的是 Git 技术，所以本地必须要装 Git 客户端。Windows 用户直接去 Git 官网下载安装包，一路下一步；macOS 用户可以用 Homebrew，一条命令brew install git；Linux 用户则用各自发行版的包管理器，比如apt install git或dnf install git。
安装完成后，打开终端（Windows 上叫 Git Bash 或 PowerShell），先确认安装结果：
git --version如果能输出版本号，说明安装成功。接下来做两个全局配置：
git config --global user.name "你的名字" git config --global user.email "你注册Gitee用的邮箱"这里--global的意思是这台电脑上所有 Git 仓库都默认使用这个身份。如果你工作需要区分不同身份，可以去掉--global，在具体某个仓库目录里单独配置。邮箱这里卡住过不少人，建议直接复制注册 Gitee 时填的邮箱，别随手敲一个，否则后面贡献图不亮真的会让人抓狂。
3. 从零建仓：网页端创建仓库、本地初始化到首次推送
3.1 在Gitee网页端创建仓库的关键选项
登录 Gitee 后，点击右上角的“新建仓库”，进入创建页面。需要填几个关键项，逐个说。
仓库名称建议用英文小写字母加短横线，比如demo-project，不要带空格，不要带中文，也不要随手写demo这种过于含糊的名字。仓库名称会体现到访问 URL 中，是团队里所有人每天都能看到的东西，尽量一眼能看出项目用途。
可见范围这里，“私有”和“公开”要提前想好。私有仓库只有你和被邀请的成员能看到，适合项目初期、课程设计、公司内部工具；公开仓库所有人都能浏览和下载，适合开源分享。公有转私有、私有转公开在 Gitee 上都可以调整，但公开仓库被别人 fork 之后，再转私有的操作会触发平台规则，很麻烦，所以初期宁可先设为私有，等确定可以公开了再改。
初始化仓库那三个选项，我建议新项目直接勾选“初始化仓库”并在下拉框里选好.gitignore模板。.gitignore的作用是让 Git 自动忽略指定文件和目录，比如.idea、node_modules、target这类“不该提交”的内容。如果是 Java 项目选 Java 模板，Python 项目选 Python 模板，没有匹配的语言就选空。开源许可证则按需选择，不想现在就定志愿也可以不选。
3.2 本地关联远程仓库：常用命令完整走一遍
仓库创建完成后，Gitee 会给你一个远端地址，通常有两种格式：HTTPS 地址和 SSH 地址。HTTPS 地址适合第一次用、不想折腾密钥的新手，缺点是每次推拉都可能要输入账号密码；SSH 地址需要提前配好公钥，配好后全程免密。
假设你本地已经有一个项目目录，还没有 Git 管理，初始化流程是这样：
cd 你的项目目录 git init git add . git commit -m "first commit" git remote add origin https://gitee.com/你的用户名/demo-project.git git push -u origin master分步拆开理解：git init是把当前目录变成 Git 仓库，会生成一个隐藏的.git目录；git add .是把当前所有文件加入暂存区；git commit -m "first commit"是把暂存区内容提交成一条版本记录；git remote add origin是把本地仓库和远程仓库关联起来，origin是远程仓库的默认别名；最后的git push -u origin master，-u表示把本地的 master 分支和远程 master 分支建立追踪关系，以后直接敲git push就能推送。
如果你在网页端创建仓库时勾选了“初始化仓库”（也就是自动生成了 README、.gitignore 等文件），那本地 init 提交完之后，先别急着 push，先拉一次远程内容，把两边的历史合并到一起：
git pull --rebase origin master git push -u origin master不加--rebase直接git pull也能合并，但很容易生成一条多余的“Merge remote-tracking branch”提交记录，新手看着乱，我习惯用--rebase让本地提交“叠”到远程提交后面，历史更线性整洁。
4. 日常提交和分支操作的完整流程
4.1 add、commit、push、pull：标准提交流程与暂存区原理
把代码托管到 Gitee 之后，后续的工作流程基本就是“本地改代码 → 提交 → 推送 → 拉取同事的更新”这个循环。刚开始用 Git 的人最容易迷惑的是：既然有commit直接保存版本，为什么还需要add？
这就要讲到 Git 的“暂存区”概念。Git 的工作流程分三个区域：工作区（你日常改文件的地方）、暂存区（通过git add把改动放进去）、版本库（通过git commit把暂存区固化成一个版本）。这样设计的好处是，你可以把“文件改动”和“提交哪些改动”分开控制。比如同时改了好几个文件，修复 bug 的和调整格式的混在一起，就可以只把修复 bug 的逻辑add进去先提交，格式调整的留着下次提交，保证每一条提交记录主题单一、便于回溯。
完整的日常提交流程，我习惯这样走：
git status git add . git commit -m "fix: 修复任务列表在移动端显示错乱的问题" git pull --rebase origin master git push origin master每次提交前先git status看一遍改动清单，心里有数再add。git pull --rebase放在push之前，是为了把别人新推上去的远程提交先合并到本地，这样你的提交永远是在最新代码基础上产生的，能最大程度减少冲突。我见过不少新手改完代码直接 push 被拒，提示“远程有本地没有的提交”，就是因为少了这一步。
4.2 分支管理实战：创建、切换、合并与冲突处理
分支是 Git 的看家本领，逻辑上可以理解成“从主线上分出来的一条平行时间线”。你在分支上随便折腾，不会影响主线的任何内容。等代码完事了，再把分支合并回主线。
日常我常用的分支命令：
git branch # 查看本地所有分支 git branch feature-login # 创建新分支 git switch feature-login # 切换到新分支，老版本用 git checkout feature-login git switch -c feature-login # 创建并切换一步到位，老版本用 git checkout -b推荐用git switch系列命令，语义更清晰：checkout同时承担“切分支”和“恢复文件”两个职责，新手容易混淆。如果本地 Git 版本偏旧不支持switch，也可以用checkout -b。
分支开发完成后，切回主线，合并分支：
git switch master git pull --rebase origin master git merge feature-login git push origin mastermerge会把分支里的改动合并进当前分支。合并时有可能会遇到冲突，最常见的是两个人同时改了同一个文件同一行，Git 无法自己决定保留谁，只能罢工让你人工裁决。冲突提示长这样：
CONFLICT (content): Merge conflict in src/App.vue打开冲突文件，会看到类似<<<<<<< HEAD、=======、>>>>>>> feature-login这样的标记。<<<<<<< HEAD和=======之间是当前分支的内容，=======和>>>>>>> feature-login之间是合并进来的分支内容。你需要手动决定保留哪一份，或两份都整合，然后把标记行删掉，再执行：
git add 冲突文件 git commit -m "merge: 解决登录页样式冲突"解决冲突没有标准答案，但有一条经验很关键：遇到冲突先别慌，也不要一股脑全选“别人的”，分清楚到底是需要“并集”还是“替换”。改完以后最好立刻git log看一遍提交记录，确认没有丢失任何一方的修改。
5. 团队协作场景：仓库成员、权限与Pull Request
5.1 添加仓库成员并设置角色权限
一个人用 Gitee，只会用到“推送”和“拉取”；但一旦两个人以上协作，权限管理就必须认真设置。入侵仓库设置页面，找到“成员管理”分类，可以通过用户名或邮箱把同事加进仓库。
常见的角色权限大致分为几档：管理员能修改仓库设置、删除分支、管理成员；开发者能推送和拉取代码；评论者只能看代码、提评论，不能直接修改；观察者则基本只有一个只读权限。具体名称以仓库设置页面的实际展示为准，但概念大体相同。
小团队刚开始协作时，通常给核心开发者“管理员”权限，给外围协作者“开发者”权限。企业项目如果要走严格的代码审查流程，甚至可以规定主分支禁止直接推送，所有改动必须经过 Pull Request 合并。这样权限划分能避免“十几个人都有管理员、谁都能动主分支”的失控局面。
5.2 用Pull Request来规范代码评审和合并
Pull Request（简称 PR）是 Gitee 上非常实用的协作功能。它的使用场景是：开发者不要直接把代码推到主分支，而是推到一个功能分支，然后发起一个合并请求，由指定的人审查，确认没问题后再合并到主分支。
完整流程是：
- 从最新主分支切出功能分支，命名比如
feature/payment； - 在功能分支上完成开发并提交、推送；
- 打开仓库页面的“Pull Request”入口，选择要合并到主分支的功能分支；
- 填写标题和描述，说明这次改了什么、为什么改、测试情况；
- 指定审查者，等待审查反馈；
- 审查通过后点击合并，或在讨论区继续修改。
我把 PR 比喻成“代码上线的安检门”：直接推主分支就像不验票直接进场，出了问题只能来回猜；走 PR 则会把每一次修改放在阳光下，审查者能看到改动范围、提交历史、评论记录。对团队协作来说，这比事后看聊天记录找人是谁改的强太多了。哪怕你的项目只有两个人，我也建议从初期就养成“功能分支 + PR 合并”的习惯。
6. 高频问题排查与避坑实录
6.1 账号认证和仓库访问问题
在实际使用中，遇到最多的异常都出在“本地身份没对上”。下面这张表格是我根据多年实践经验整理的排查速查表，遇到问题可以按图索骥。
| 现象 | 最常见原因 | 解决方式 |
|---|---|---|
| push 时提示 Permission denied | SSH 公钥没配好或本地使用 HTTPS 但账号密码错误 | 检查ssh -T git@gitee.com是否能通；HTTPS 则确认账号密码 |
| 提示 Please tell me who you are | 没有配置 user.name 和 user.email | 按第 2.2 节执行git config --global两行命令 |
| Gitee 贡献图不亮，个人主页没有提交记录 | 本地提交邮箱和 Gitee 账号邮箱不一致 | 用git log检查提交作者邮箱，改成一致的邮箱后再提交 |
| 添加 SSH 公钥后仍然要输密码 | 使用了 HTTPS 地址而非 SSH 地址 | 修改远程地址：git remote set-url origin换成 SSH 格式 |
| 403 权限错误 | 你不是仓库成员，或成员角色只有只读权限 | 在远程仓库成员管理中调整自己的角色 |
需要特别注意的一点：SSH 地址和 HTTPS 地址是不同的认证体系。本地仓库已经绑定了一个地址，想换认证方式，可以用git remote set-url origin 新地址来替换，不需要删除重加。
6.2 本地与远程状态不一致、误操作恢复问题
另一类高频问题来自“本地历史和远程历史对不上”。最典型的就是第一次推送时，远程仓库已经被初始化了 README，本地也提交过一次，两边都是“第一次提交”，Git 会认为这是两个完全不同的根，直接拒绝合并。
解决办法也很直接：
git pull --rebase origin master ./允许无关历史 git push -u origin master如果执行过程中提示“refusing to merge unrelated histories”，说明两边确实没有共同祖先，在git pull命令后面加一行参数：
git pull --rebase origin master --allow-unrelated-histories这类问题教训就一条：创建仓库时可以初始化 README，也可以不初始化，但必须在团队里定好规矩，避免一些人从空仓库开始推，另一些人从带 README 的仓库开始推，导致两边历史永远合不拢。
还有一类误操作让人心态崩——辛苦改的代码被撤销了。比如执行了git checkout .，所有工作区改动被还原。这种场景下，第一反应是看git reflog，Git 会记录 HEAD 每次移动的历史，通过它找到你改动前的提交编号，再用git reset恢复到对应状态。reflog我愿称之为“后悔药”，越早学会越好。
最后分享一个我自己的操作习惯：每次提交前我都会git status和git diff先看一遍改动范围，确认没有误伤文件，再执行add。提交信息我习惯写“动词 + 对象”的格式，比如fix: 修复登录页在手机端样式错乱的问题，这样月底回看提交历史，一眼就能知道每一条到底做了什么。代码托管这件事，坚持用简单可维护的规范，带来的收益远大于一开始花费的那点成本。希望这篇文章能帮你顺利把项目托管到 Gitee，少踩我踩过的这些坑。
