1. 从「GitHub 平替」到协作平台Gitee 到底解决了什么问题1.1 Gitee 的定位不只是「国内版 GitHub」很多刚接触 Gitee 的人第一反应都是「这不就是个国内版 GitHub 嘛」。这话只对了一半。Gitee 确实在外观和核心操作上跟 GitHub 高度相似比如仓库、Issue、Pull Request、Star、Fork 这些概念几乎一模一样甚至 Git 命令本身也是通用的你在 GitHub 上怎么用git push、git pull在 Gitee 上就怎么用。如果只是图个「能放代码」那它确实是个平替。但真正把 Gitee 用明白的人会把它当作一个「研发协作中台」来看。它不只是帮你存代码而是把整个开发链条上的事都串起来了代码托管、分支管理、代码评审、任务看板、CI/CD 流水线、静态网站托管、制品管理甚至文档协作和开源社区运营都能在同一个平台里完成。我见过不少团队GitLab 和 Jenkins 都搭在自己服务器上费了很大劲维护最后迁移到 Gitee 之后反而把运维成本砍掉了大半。原因很简单这些能力在 Gitee 上是开箱即用的不需要你额外部署任何东西。另外一个不能忽略的点是速度。代码仓库这种高频读写的工具最怕网络延迟。我早期用 GitHub 的时候git push一个稍大的仓库经常卡到让人怀疑人生偶尔还会断掉重来。Gitee 在国内的访问速度和稳定性就好很多尤其是在公司网络环境下基本能做到秒开。对于大部分国内开发者、学生团队、中小企业来说这种「低摩擦」的使用体验比任何花哨功能都实在。1.2 为什么很多人会把项目放在 Gitee 上部署和维护除了速度Gitee 的另一个天然优势是「离目标用户近」。假如你做一个开源项目目标用户主要在国内那你把仓库放在 Gitee 上别人搜到的概率、点开 README 的概率、提 Issue 的概率都会高很多。国内开发者浏览代码的习惯跟国外不完全一样很多人不会特意去 GitHub 上翻项目反而会在 Gitee 的「推荐项目」和「开源软件」频道里找东西。Gitee 在中文搜索、中文文档、中文社区氛围这一块确实做得比 GitHub 接地气。还有一类人是因为「业务需要」选择 Gitee比如做外包项目、企业内部工具、课程作业演示或者给客户交付源码。这种场景下代码可能不适合公开到海外平台或者客户要求代码必须放在国内平台方便验收。Gitee 的私有仓库功能这时候就特别实用免费额度对大多数个人和小团队完全够用。另外Gitee 的「 Gitee Go 」和「静态页面托管」这两个功能是被很多人忽视但实际价值很高的点。你写一个 Vue 或 React 项目想在手机上快速演示效果直接在 Gitee 上创建一个仓库把构建产物发布到静态托管几分钟就能拿到一个在线网址。配合自动化流水线每次git push都能自动重新构建和发布做个人作品集、产品原型、团队内部文档站都相当顺手。2. 上手第一步仓库创建、密钥配置与代码推送2.1 创建仓库之前要想清楚的三件事很多人第一次用 Gitee注册完账号就兴冲冲点「新建仓库」结果仓库名乱取、开源许可证乱选后面越用越别扭。创建仓库之前有三件事值得先想清楚。第一件是可见性。公开还是私有如果你的目的是分享代码、攒 Star、开源那就选公开如果只是自己写着玩、存点不想给别人看的东西或者公司项目选私有更稳妥。这里有个细节Gitee 的私有仓库在免费版里是有人数限制的协作者数量有限超过之后需要升级套餐。个人用一般无所谓团队用就要提前规划好。第二件是仓库名和描述。仓库名最好用小写字母、数字和中划线避免出现大写字母、空格和中文。比如my-awesome-project就比My_Awesome_Project规范因为后面 clone 的时候 URL 更干净团队协作也不会因为大小写问题在本地配置里踩坑。描述这个字段很多人忽略但它直接影响别人在 Gitee 上能不能搜到你的项目建议用一句话说清楚「这项目是干什么的、用什么语言写的」。第三件是初始化选择。我强烈建议在创建页面把「初始化仓库」的选项勾上让 Gitee 自动生成 README、.gitignore和开源许可证。这三个文件在仓库刚创建时可能看着累赘但他们是一组「基础设施」README 是项目门面.gitignore能避免垃圾文件被提交许可证则决定了别人能不能合法使用你的代码。之后我会单独讲许可证怎么选。2.2 SSH 密钥配置与本地环境准备代码推送到 Gitee最常见的方式有两种HTTPS 和 SSH。HTTPS 的好处是配置简单每次 push 时输入用户名密码或私人令牌即可坏处是要频繁输入凭据虽然可以靠凭证管理器记住但在某些命令行环境下还是会莫名失效。SSH 的好处是一劳永逸配置好密钥之后push、pull、clone 都不需要再输入账号密码而且传输过程加密安全性更高。这里重点说 SSH 的配置过程因为「git配置gitee密钥」这词条搜索量一直很高说明很多人卡在这一步。我用的是最常见的一套流程Windows 和 macOS 都通用# 1. 生成本机 SSH 密钥对 ssh-keygen -t ed25519 -C 你的邮箱example.com # 2. 一路回车生成的文件默认在 ~/.ssh/ 下 # 生成的三个文件私钥 id_ed25519、公钥 id_ed25519.pub、known_hosts后续自动生成 # 3. 查看公钥内容 cat ~/.ssh/id_ed25519.pub然后把公钥内容复制粘贴到 Gitee 的「个人设置 → 安全设置 → SSH 公钥」页面标题随便填个能辨识的名字比如my-laptop。添加完成后先测试一下连通性ssh -T gitgitee.com如果返回类似Hi your_username! Youve successfully authenticated, but GITEE.COM does not provide shell access.的提示就说明密钥配置成功了。我踩过一次比较典型的坑在一台机器上同时使用 GitHub 和 Gitee 的 SSH key结果 GitHub 的 key 在 Gitee 上验证失败反过来也一样。原因是 SSH 客户端默认会用id_ed25519这个密钥去尝试所有主机而不同平台的公钥不匹配。解决办法是给两个平台分别配置不同的密钥文件然后在~/.ssh/config里指定Host gitee.com HostName gitee.com User git IdentityFile ~/.ssh/id_ed25519_gitee Host github.com HostName github.com User git IdentityFile ~/.ssh/id_ed25519_github这样两个平台就能共存互不干扰。这个技巧对多平台开发的人来说相当实用。2.3 把已有代码推到仓库两种最常见的方式用 Gitee 的人最多的诉求就是「如何把已经写好的代码文件放到 Gitee 里」。这里其实有两条路一条走网页端一条走命令行适用场景不同。网页端适合小仓库、少量文件。你可以在 Gitee 仓库页面点「上传文件」把文件拖拽进去就完事。这个方法对新手最友好但如果文件数量很多、嵌套目录很深网页端操作就非常痛苦而且容易遗漏文件。命令行是正道。假设你本地已经有一个项目文件夹想传到 Gitee 上新建的仓库我在实操中常用的是这套流程# 进入项目目录 cd /path/to/your/project # 初始化本地 Git 仓库如果还没有 .git 目录 git init # 添加所有文件到暂存区 git add . # 首次提交 git commit -m init project # 添加远程仓库地址把下面的 URL 换成你自己的 git remote add origin gitgitee.com:your_username/your_repo.git # 推送到远程仓库的 master 分支 git push -u origin master这里有两个细节容易被忽略。第一git add .之前一定要确认.gitignore已经写好否则node_modules、target、.idea这类目录会被一并提交仓库瞬间变得又大又杂。第二-u参数会把本地分支和远程分支关联起来之后你直接git push就能推不用再写完整的分支名省事很多。「gitee上传代码到仓库」和「gitee怎么上传代码到仓库」这两个热搜词本质上问的都是同一件事代码怎么从本地到远端。其实核心就这几条命令不需要背复杂参数多用几次就会形成肌肉记忆。我第一次用 Git 的时候也总记不住remote add的顺序后来发现把「本地库 → 远程库 → push」这个三步走牢记在心就够了。3. 日常开发中的高频操作克隆、分支与协同3.1 克隆项目和远程仓库同步新同事加入团队或者你在另一台电脑上想接着写代码第一件事就是克隆仓库。命令行操作很简单git clone gitgitee.com:your_username/your_repo.git克隆下来之后你得到的是默认分支通常是master或main的代码。如果项目有多个分支你需要切一下才能看到git branch -a # 查看所有分支包括远程分支 git checkout dev # 切到本地 dev 分支 git checkout -b dev # 如果本地没有 dev用 -b 从当前分支创建并切换克隆完最怕的就是「改了半天才发现基于的代码已经过期了」。所以在动手之前建议先执行一次git pull把远程最新代码拉下来。这个习惯能帮你避免大量合并冲突。日常同步还有一个细节值得注意如果你在 Gitee 网页端修改了 README或者别人往仓库推送了新提交你本地需要把这些更新同步过来。执行git pull origin master这个命令本质上是「拉取远程 master 分支的最新提交并合并到当前分支」。如果本地没有未提交的修改基本不会有冲突如果有就需要手动解决冲突文件把 HEAD和之间的内容整理干净。3.2 基于 Pull Request 的团队协作流程Gitee 的 Pull Request简称 PR在 Gitee 里叫「Pull Request」功能是团队协作的核心环节。我第一次用 PR 做协作时不太理解它的价值觉得「直接把代码推到 master 分支不就行了吗」直到有一次我直接推了 master把一个能正常运行的线上项目推到直接挂掉才明白这条「保护线」有多重要。正确的协作流程是这样的每个开发者在自己的分支上开发然后向目标分支发起 PR由负责人或同事进行代码评审确认没问题后再合并。Gitee 的 PR 页面支持在线评论、逐行评论、检查冲突还可以配置「必须通过评审才能合并」的规则这些能力组合起来形成了一条相对完整的质量防线。我在团队里推行的模式是master分支作为稳定分支代码永远是可发布状态dev分支作为集成分支日常开发都往这里合每个人从dev拉出自己的功能分支完成一个功能就发起一个 PR 合回dev。这样做的好处是任何时候想去master发一个版本都能保证「拿到的代码是稳定经过评审的」。Gitee 的 PR 还有一个很实用的能力关联 Issue。你可以在 PR 描述中输入「#123」这样的格式关联一个 Issue合并之后 Issue 会自动关闭。整个开发链路从需求 → Issue → 功能分支 → PR → 合并都有迹可循比一群人闷头 push 代码再靠口头对需求清晰多了。3.3 IDE 与编辑器集成IDEA、VSCode 操作习惯搜「idea 提交代码到 gitee」和「vscode gitee 插件」的人非常多说明大部分人不喜欢在命令行和 IDE 之间来回切换。这块我的建议是不强制谁用命令行但每个人必须理解命令行背后的原理这样哪怕工具界面变了你也能很快适应。IntelliJ IDEA 的操作其实很简单。装好 Gitee 插件后在「File → Settings → Version Control → Gitee」里登录账号之后右侧的 Git 工具窗口就能看到仓库的提交记录、分支列表和远程仓库。提交代码的核心动作是右键项目 → Git → Commit Directory写好提交信息然后点 Commit and Push 就能一次性完成提交并推送到远端。如果你需要拉取远程更新直接 CtrlT或 CmdT就会执行 pull。VSCode 这边官方自带的 Git 面板其实已经够用但搭配 Gitee 相关插件体验会更好。插件市场里搜「Gitee」会有几个社区插件有的可以关联 Gitee 仓库、查看 PR、甚至快捷创建仓库。实际用下来我推荐至少装一个「Git Graph」插件它能把分支提交历史可视化成图形排查「是谁在什么时候改了哪一行」这类问题非常直观。有一点我必须强调在 IDEA 或 VSCode 里操作 Git不要一上来就点「Discard All Changes」丢弃所有修改这个操作会把你本地未提交的代码全部扔掉而且无法恢复。我见过不止一个新手因为这个操作崩溃。做这种「高危动作」之前先把要保留的文件手动复制一份出来。4. DevOps 能力拆解静态托管、自动部署与项目管理4.1 静态页面托管个人博客、项目文档怎么挂上去「gitee静态托管」是个高频搜索词但这个功能被很多人低估了。它不是简单上传 HTML 文件就完事而是可以和一个仓库绑定仓库里放代码和构建脚本Gitee 会在你 push 之后自动构建并把产物发布到一个可访问的网址。我自己的个人博客就是这么搭的。我用 Hugo 生成静态网站把源码放在一个私有仓库里然后在 Gitee 的「服务 → 静态页面托管」里绑定这个仓库选择构建方式为 Hugo默认输出目录是public保存之后每次git pushGitee 都会自动执行构建并更新网站。整个过程五分钟搞定不需要自己买服务器、配 Nginx、折腾 HTTPS 证书。如果你用 Vue 或 React原理也一样只是构建方式要选 Node.js构建命令一般是npm install npm run build输出目录通常是dist或build在静态页面托管的配置里填正确即可。这里常见问题就是输出目录填错导致部署出来的页面是空的或者访问 404。遇到这种情况先检查构建日志再确认输出目录是否和实际一致。有一点需要提醒Gitee 的静态托管对访问频率和流量是有限制的适合个人项目、演示页、文档站这类场景如果你要做高并发商业站点那还是建议用正规云服务。4.2 自动化流水线从提交代码到自动部署Gitee 的 CI/CD 能力叫 Gitee Go它内置了一个可以执行自动化任务的构建环境。你可以配置流水线让它在每次git push或者打 Tag 的时候自动执行安装依赖 → 跑测试 → 构建镜像 → 部署到服务器或对象存储。我举个实际例子。我们有个后端服务用 Go 写的原来的部署方式是本地go build然后 scp 到服务器再手动systemctl restart。这个过程步骤多、耗时长而且很容易在「本地能跑、服务器上跑不起来」这个坎上卡住。后来我配置了一条 Gitee Go 流水线在gitee-ci.yml里做三件事拉代码、用go test ./...跑单测、用go build产出二进制文件并上传到服务器。这样每次 push代码会自动编译单测过了才会触发部署没过就停在流水线里等着人去修。从那以后我再也不用记那些复杂的部署命令了。对于前端项目流水线的价值更明显。团队里曾经发生过「本地构建没问题但线上就是白屏」的事原因是打包工具版本不一致。后来在流水线里固定了 Node 版本和依赖锁文件再配合静态托管自动发布这类问题基本就绝迹了。DevOps 的核心逻辑并不高深就是把「人容易做错、做漏」的重复劳动交给机器让开发和发布之间的衔接变得标准、稳定、可复现。4.3 任务管理、Issue 与里程碑把代码和需求打通代码托管平台如果只管代码那它离「DevOps 一站式」还差得很远。Gitee 上还有一个常被忽略的板块需求管理、任务看板和里程碑。这些功能跟 GitHub 的 Issues 和 Projects 类似但和 Gitee 仓库、PR、注释的集成做得更深更适合国内团队的使用习惯。举个例子我们开发一个新功能流程是这样的先在「任务」里建一个事项写明需求背景、验收标准指派给某个开发开发在本地开一个功能分支提交代码时在 commit message 里写上关联的任务编号比如feat: 增加订单导出功能 #452代码发完 PR 后在 PR 描述里关联对应任务合并之后任务状态自动更新。这样从需求到代码再到验收整条链路都是可追溯的。个人开发者可能觉得这些功能用不上但如果你在维护一个开源项目Issue 和里程碑就成了刚需。用户报 bug、提建议都通过 Issue 进来你可以用里程碑把它们归到某个版本里比如「v1.2 计划」就包含三个 bug 修复和两个新功能。发布版本之后再创建一个新里程碑规划和落地就对齐了。Gitee 的看板视图也是可视化的拖拽卡片就能改变任务状态比纯文字列表直观很多。5. 进阶玩法与踩坑实录批量操作、许可证选择、常见问题5.1 批量删库这类操作千万不要在网页上手动点热搜词里有个「gitee批量删库」看到这个词我第一反应是这应该又是一个觉得自己「仓库太乱想一键清空」的朋友。但真心建议别闲着没事去批量删库尤其是不要手动在网页上一个个点删除。先说说为什么想批量删库的人多。很多人把 Gitee 当临时存储 U 盘写个作业存一个仓库、跑个实验存一个仓库、建个测试项目又存一个仓库时间长了账号里堆积了几十个「已废弃但不敢删」的仓库。想删是因为乱不敢删是因为怕误删重要代码。我更推荐的思路是「归档」而不是「删除」。Gitee 支持把仓库设置为私有、封存或标记废弃这样既不占公开页面也不影响已有链接未来想恢复还能找回来。如果确实要删除也建议用命令行配合官方 API 来做而不是手动逐个点击。用 API 的好处是可以通过脚本筛选「超过 90 天没有新提交、且名称含 test 或 demo 的仓库」再删除降低误删概率。这里我提醒一句删除仓库是个不可逆操作所有代码、Issue、PR、流水线配置都会消失没有任何回收站机制。所以不管用什么方式删删除前一定确保本地和云端都有完整备份。5.2 开源许可证怎么选别让选错变成未来隐患「gitee开源许可证选什么」这个热搜词特别典型说明很多人在创建仓库时会面对「License」这一栏犹豫不决。其实许可证的选择说复杂也复杂说简单也简单关键是你要想清楚你希望别人用你的代码时承担什么义务。我在 Gitee 上看到很多仓库License 一栏是空白的或者选了 MIT 但作者根本不清楚 MIT 意味着什么。空白意味着「保留所有权利」别人理论上不能合法使用、修改、分发你的代码哪怕你的仓库公开展示别人也只能看不能用这跟开源的初衷是矛盾的。如果你「无所谓别人怎么用」选 MIT 或 Apache 2.0 就行。MIT 是最宽松的别人可以商用、修改、闭源只要保留你的版权声明Apache 2.0 多了一堆专利保护和条款企业项目更常用。如果你的诉求是「别人用了我的代码也必须开源」选 GPL 3.0 或 AGPL 3.0。比如你写了一个公共组件不希望别人拿去改成闭源商业产品那就 GPL。这里注意GPL 有传染性别人只要把它集成进自己的项目整个项目的代码都可能被迫开源。社区里还有一种流行做法是「先用 MIT 发布等社区有了一定规模再换」。这个思路看起来灵活但真要执行起来非常麻烦因为你没法追溯所有下游使用者。所以我建议项目成立第一天就把许可证定清楚这个决定越早做后续改起来越省事。5.3 高频问题排查密钥失效、上传失败、强制推送等最后把我在实际使用中碰到的高频问题整理成速查表每一条都是踩过坑换来的。第一个是「git push 报 Permission denied (publickey)」。这个问题大概率是 SSH 密钥出问题。先执行ssh -T gitgitee.com测试返回错误的话多半是本机公钥没配到 Gitee 上或者配了但解析到错误的密钥文件。我前面提到的~/.ssh/config方案就是解决这类「多密钥串台」问题的。第二个是「push 被拒绝因为当前分支落后于远程分支」。这个场景通常是远程仓库里有人提交了新代码你本地还停留在旧版本。解决方案先git pull合并远程更新解决好冲突再重新 push。千万别用git push -f强制推送它会把远程提交直接覆盖掉如果是协作仓库强制推送是对团队极不尊重的操作一旦把别人的提交覆盖了恢复起来非常麻烦。第三个是「上传大文件时 push 卡住或失败」。如果你的仓库里有超过 100MB 的大文件建议用 Gitee 提供的大文件支持功能或者把这类文件放到对象存储里而不是硬塞进 Git 仓库。Git 本身不是为管理大文件设计的仓库体积一旦膨胀后续每次 clone 和 fetch 都会变慢这个痛是会积少成多的。第四个是「clone 很慢」。如果你在公司内网检查一下是否开启了代理或者尝试切换 SSH 和 HTTPS 两种协议看看哪个更快。Gitee 在国内的访问速度通常没问题慢一般都是本机网络配置或 DNS 问题。实在不行可以用 Gitee 网页端的「下载 ZIP」功能应急。我个人的习惯是遇到 Git 报错先不看中文翻译直接看原始英文报错信息。因为大部分中文解释是社区网友猜测的而英文信息后面往往跟着官方文档链接或清晰的错误码顺着排查效率要高得多。最后再说点我的真实体会Gitee 这个平台我用了好几年从最初只是把它当成「把练习代码存云端」的地方到后来把自己参与的开源项目放上去再帮团队搭起一整套基于 Gitee 的协作流程每一步都踩过不少坑也慢慢摸索出了自己的一套用法。最深的体会是工具本身不会自动让团队变得高效真正起作用的是团队有没有一套清晰、一致的使用规范。分支怎么命名、PR 怎么走、Issue 怎么提、流水线怎么卡这些规则越早定下来后面省的事越多。另一个很想分享给大家的经验是不要只盯着「存代码」这一步多花点时间把 Gitee 的静态托管、流水线、任务看板这些能力用起来。它们单个看好像都不复杂但组合在一起完全可以支撑一个小团队从需求到上线的完整闭环。尤其是个人开发者利用这些免费能力搭建自己的效率系统性价比极高。