刚接触编程或加入新团队的人十有八九会从“拉代码”开始。同事甩给你一个 Gitee 仓库地址说“先把这个项目跑起来”你打开网页看到一堆文件和 commit 记录不知道该点哪里想用 IDEA 或 VS Code 打开又找不到正确的拉取入口。这种状态我太熟了所以这篇 0 基础 Gitee 教程就是按新手最容易卡住的顺序把注册、建仓库、配置密钥、上传代码、拉取到 IDE、处理大文件和子项目这些高频操作全部拆开讲一遍。它不要求你有 Git 基础只需要跟着操作顺序走就能从“不会用”变成“天天用”。1. 为什么是 Gitee 先弄懂它和 Git 的关系很多人第一次看到“Gitee”和“Git”两个词容易混为一谈。其实它们是两个完全不同的东西理解清楚这件事后面所有操作都会顺很多。1.1 Git 是工具Gitee 是平台Git 是一个分布式版本控制工具它跑在你自己的电脑上负责记录代码的每一次变化。你可以把它想象成一个“本地时光机”每提交一次就保存一个快照改坏了随时可以回退。这个过程完全不需要联网也不需要任何平台。Gitee 则是国内流行的代码托管平台你可以把本地 Git 仓库“推”上去相当于给代码加了一个云端备份。别人也能通过这个平台查看、克隆、协作你的代码。如果用生活类比Git 是相机负责拍照和保存照片Gitee 是云相册让你把照片传到网上可以分享给朋友也可以在多台设备之间同步。实际开发中你的操作流程通常是在本地用 Git 记录版本然后把某个分支推送到 Gitee 上同事再从 Gitee 拉下来继续改。两个工具互相配合但各管一摊。搞懂这一点你就不会因为“本地文件删了是不是仓库也没了”这类问题慌神了——本地是本地云端是云端两边可以互相推送但删除本地文件不会影响 Gitee 上的仓库。1.2 0 基础的人需要迈过的三个门槛从“不会用”到“天天用”大部分人都会经过三道坎提前知道它们是什么能少走很多弯路。第一道坎是概念。仓库、分支、提交、推送、拉取这几个词看着玄乎其实对应的是非常具体的动作。仓库Repository是一个项目文件夹加它的版本历史提交commit是保存一次更改记录推送push是把本地记录传到 Gitee拉取pull是把 Gitee 上的更新取回本地。你不需要一开始就理解底层原理只要知道“每次改完代码先 commit再 push消息就同步到云端了”日常使用就够了。第二道坎是命令。Git 的命令确实不少但 0 基础阶段只需要掌握核心的七八条git add、git commit、git push、git pull、git clone、git status、git log。这些命令会在后面的具体操作中反复出现用多了自然就记住了不需要死记硬背。第三道坎是报错。新手最常见的心理障碍是看到命令行里的英文报错就发懵。实际上Git 的报错信息已经非常直白比如“failed to push some refs”就是在提醒你远端有新东西需要先 pull“Permission denied (publickey)”说明 SSH 密钥没配好。这篇教程会专门在关键章节讲怎么读报错你只要按步骤照做报错反而能成为最好的老师。2. 注册与第一次建仓库把“云端文件夹”跑起来在 Gitee 上创建一个仓库本质上就是创建一个可以装代码的云端文件夹。这个过程可以完全不碰命令行网页上点几下就能完成。但有几个参数会影响你之后的使用体验值得认真选。2.1 注册账号与建仓前准备打开 Gitee 官网点击右上角的“注册”用手机号验证即可。注册完成后建议先去“个人设置”里把头像、昵称填好再点击右上角的“新建仓库”进入建仓页面。如果你是第一次注册可能会被要求完成实名认证。这是平台为了规范管理而设的流程按页面提示操作就好不需要额外准备什么复杂材料一般提交信息后很快就能完成。建仓前建议你提前想好两件事仓库叫什么名字。尽量用英文字母、数字和连字符比如 my-first-project。名字路径会成为仓库地址的一部分后期修改虽然可以但会影响已经克隆过这个仓库的同事。这个仓库是要公开还是私有。公开仓库所有人都能看到适合开源项目、学习笔记、作品展示私有仓库只有你自己和被邀请的成员能看适合公司项目、隐私代码、还没准备好的作品。记住一个原则能私有就先私有确定要开源再切换为公开。切换很自由但如果你一开始公开了随手写进去的敏感信息就来不及后悔了。2.2 填写仓库信息时的几个必选参数进入新建仓库页面后会看到仓库名称、路径、介绍、是否初始化仓库等选项。这里最容易纠结的是“初始化仓库”这一区里面有三个选项添加 README 文件、添加 .gitignore、选择开源许可证。README 是一个项目的说明书在仓库首页直接展示。建议新建仓库时勾选“初始化 README”这样仓库里会有一个初始文件后续可以持续补充项目介绍、启动方式和注意事项。即使是个人练习项目我也建议保留因为你会发现几个月后自己也需要靠 README 回忆这个项目怎么跑起来。.gitignore 是 Git 的“忽略清单”。它会告诉 Git 哪些文件不需要纳入版本管理比如 IDE 配置文件、编译输出目录、环境变量文件。Gitee 提供了多种常见语言的模板你可以在创建仓库时按项目类型选择比如选 Python、Node、Java。就算当时选得不完整后面也可以手动补充。开源许可证的选择需要单独说一下因为它不是技术问题而是法律问题。2.3 开源许可证选什么几个常见场景的选择建议如果你创建的是私有仓库许可证选不选都无所谓。但如果仓库要公开许可证决定了别人能不能用你的代码、用了之后要不要开源自己的代码。很多新手随手选了一个“MIT”其实未必适合。下面是我常用的几个选择思路MIT License最宽松别人拿了你的代码可以随便用、改、商用只需要保留版权声明。适合个人开源项目、工具类代码你希望被更多人使用。Apache License 2.0比 MIT 多了一条专利授权保护宽松但稍微严谨一些。适合项目背后有公司或团队参与希望减少专利风险的场景。GPL License 3.0强 Copyleft别人用你的代码做成衍生作品后也必须开源并且使用同样的许可证。适合希望强制“代码共享”的社区型项目比如一些基础框架。如果是普通学习项目我建议直接选 MIT少给自己找麻烦如果以后可能有商业用途选 Apache-2.0如果你明确希望代码永远保持开源再考虑 GPL。别选“没有许可证”因为没有明确许可别人的使用风险会变大反而限制了项目传播。仓库创建完成后你会看到一个页面顶部有两行地址HTTPS 和 SSH。这就是这个仓库的“云端地址”后面拉取和推送都要用到它。3. 配置本机环境密钥、全局身份与 Git 安装网页上的仓库建好了接下来要让本地电脑和 Gitee“认识”对方。这一步配置好了后面推送代码就不用反复输密码体验会非常顺畅。3.1 安装 Git 并验证Windows 用户需要去 Git 官网下载安装包安装时一路 Next。安装完成后在任意文件夹右键如果看到“Git Bash Here”菜单就说明装好了。macOS 用户比较省事系统自带 Git直接在终端输入 git --version 就能确认如果没有系统也会弹出安装提示。安装完第一步打开终端或 Git Bash输入git --version能看到类似 git version 2.40.0 的输出就说明环境没问题。如果你发现自己找不到终端Windows 上一定要学会使用 Git Bash它比 CMD 更接近 Linux 命令很多项目的操作说明都默认基于 Git Bash 写。3.2 配置全局身份Git 每次提交代码时都需要记录“谁提交的”。这个信息来自全局配置不设置的话push 到 Gitee 时会被拒。打开终端敲下面两行git config --global user.name 你的名字 git config --global user.email 你的邮箱注意这里的邮箱最好和 Gitee 账号绑定的邮箱一致这样仓库里的提交记录能顺利关联到你的 Gitee 头像和主页。使用 --global 参数表示对所有仓库生效如果你同一个电脑上不同项目需要不同身份再单独在某个仓库目录里去掉 --global 重新设置即可。配置完可以用 git config --list 检查看到 user.name 和 user.email 就对了。3.3 生成并配置 SSH 密钥让推送不用反复输密码SSH 密钥是一对加密文件私钥留在本地公钥放到 Gitee。推送数据时Gitee 用公钥验证你的身份整个过程不需要输入密码。这个机制有点像小区门禁私钥是你的门禁卡公钥是门禁系统里登记的“允许通行”名单。生成密钥的命令是ssh-keygen -t ed25519 -C 你的邮箱一路回车即可。如果系统提示 ed25519 算法不可用可以用传统方式ssh-keygen -t rsa -b 4096 -C 你的邮箱生成完成后Windows 用户公钥文件默认在 C:\Users\你的用户名.ssh\id_ed25519.pubmacOS 和 Linux 用户在 ~/.ssh/id_ed25519.pub。用文本编辑器打开这个 .pub 文件复制全部内容。注意只复制公钥内容私钥文件没有 .pub 后缀的那个绝不能发给任何人。然后打开 Gitee在个人头像下拉菜单里找到“设置”进入“安全设置”中的“SSH 公钥”把刚才复制的公钥粘贴进去起一个方便识别的标题比如“我的 Windows 笔记本”保存即可。验证是否成功在终端输入ssh -T gitgitee.com如果看到类似“Hi xxx! Youve successfully authenticated”的提示就说明密钥已经生效可以愉快地免密推送了。3.4 HTTPS 与 SSH 该选哪个Gitee 仓库地址提供了 HTTPS 和 SSH 两种协议新手容易犯的选择困难症这里一次说清。HTTPS 地址以 https:// 开头克隆和推送时通常需要输入 Gitee 的用户名和密码虽然可以配置密码缓存但每次换电脑都要重新认证一次。SSH 地址以 gitgitee.com: 开头配置好密钥后长久免密而且只管公钥不涉及账号密码。我更推荐所有新手直接使用 SSH 地址。虽然配置密钥比 HTTPS 多一步但一次性投入后面每天推送代码都能省掉反复输密码的烦恼。如果你已经用 HTTPS 克隆过仓库也可以改回 SSH在本地仓库目录执行 git remote set-url origin 新的SSH地址 即可不需要重新克隆。4. 上传代码到仓库两种路径和完整步骤仓库建好、环境配好接下来就是把本地代码上传到 Gitee。这一步可以说是一切 Gitee 使用的基础。根据你当前手上有没有本地项目有两种做法。4.1 路径一本地已有项目用命令行完成第一次推送假设你的电脑上已经有一个写好的项目文件夹想把它传到 Gitee 仓库。第一步进入项目目录右键打开 Git BashmacOS 用终端cd /c/Users/你的用户名/你的项目路径路径里不要有中文和空格如果有先把文件夹重命名否则后面容易遇到奇怪的问题。接着初始化一个本地 Git 仓库git init执行后目录里会生成 .git 文件夹这就是 Git 保存版本信息的地方。然后把你项目中的所有文件加入“暂存区”git add .这里的 . 代表当前目录下所有文件。如果你不想一股脑全提交可以用 git add 指定文件。检查一下要提交的内容git status这一步很重要。你会看到绿色部分是会被提交的文件如果有 node_modules、target、.idea 这类不该出现的文件说明你的 .gitignore 没写好先把它们排除再继续。确认无误后提交一次版本记录git commit -m first commit接下来要和 Gitee 仓库建立连接。仓库地址用 SSH 形式先给本地分支改个统一的名字git branch -M main然后把 Gitee 仓库地址设置为远程源git remote add origin gitgitee.com:你的用户名/项目名.git最后推送上去git push -u origin main第一次推送时 -u 参数会建立本地分支和远程分支的关联以后在这个分支上直接 git push 就能推送不需要再加参数。4.2 路径二仓库空着用网页直接上传小项目如果本地项目文件很小、数量也不算多Gitee 的网页端可以直接传文件完全不用命令行。进入仓库首页找到“上传文件”按钮把文件拖到上传区域填写提交说明点击提交即可。这种方式适合上传一些配置文件、文档、简单脚本但不适合上传整个工程因为网页上传没有版本控制过程文件多了效率很低而且超过大小限制会被直接拒绝。我个人的建议是只要超过 10 个文件就走命令行推送哪怕多学几条命令也更值得。4.3 push 常见报错和排查新手第一次 push十有八九会碰到报错。下面两个最常见的问题和处理方法值得贴在手边。第一个是To gitee.com:xxx.git ! [rejected] main - main (fetch first) error: failed to push some refs这句话的意思是远端仓库有本地没有的提交比如你在创建仓库时勾选了 README 或者 .gitignore。解决办法是先拉取合并再推送git pull --rebase origin main git push -u origin main--rebase 的作用是把你的提交“放到”远端最新提交的后面避免无意义的 merge 记录。等命令执行完再看 git push一般就能成功。第二个是 SSH 权限问题Permission denied (publickey). fatal: Could not read from remote repository.这说明 Gitee 根本不认识你。先检查公钥有没有配好再检查你 push 的地址是不是 SSH 形式。如果地址没错就在终端执行 ssh -T gitgitee.com 重新验证一次如果提示 Hello说明密钥没问题多半是当前目录的 remote 地址不对。遇到报错不要慌把红字英文复制到搜索引擎里一搜基本都能找到答案。大部分 Git 报错都是英文但结构非常固定见的次数多了后面你甚至能根据报错猜出问题出在哪个环节。5. 把 Gitee 项目拉取到 IDEA 和 VS Code对于很多开发者来说真正“天天用” Gitee 的场景不是敲命令行而是把仓库里的项目拉进 IDE然后在日常开发中不断推送和拉取更新。这里我分别讲 IntelliJ IDEA 和 VS Code 两个最常见的做法。5.1 从 Gitee 拉取项目到 IntelliJ IDEAIDEA 内置了 Git 支持拉取项目非常简单。打开 IDEA在主界面选择 File - New - Project from Version Control或者直接在欢迎页点击“Get from VCS”。将 Gitee 仓库的 SSH 地址复制到 URL 输入框。下面会有一个目录选择项默认会在 IDEA 项目目录下创建同名文件夹你可以指定一个专门放代码的位置比如 D:\codes。点击 Clone等待项目下载完成。如果你拉取的是 Maven 项目IDEA 会自动扫描 pom.xml 并开始下载依赖如果是 Gradle 项目会自动执行 Gradle 同步。这个阶段可能会持续几分钟取决于项目依赖规模第一次等待时间较长是正常的。成功打开项目后IDEA 右下角可以看到 Git 分支信息。以后每次要获取同事的最新代码只需要点击菜单栏 Git - Pull或者在项目上右键 - Git - Pull。推送时点 CtrlShiftK提交点 CtrlShiftL 也行。这里有一个非常常见的问题克隆下来的项目一直无法正常编译半天后发现是本地 JDK 版本不对。IDEA 是从仓库拉取了代码但不会帮你自动配置环境所以拉取后第一件事应该是检查 File - Project Structure 里的 SDK 和语言级别与项目要求的版本对齐。5.2 在 VS Code 中连接 Gitee 仓库VS Code 默认集成了 Git 能力不需要额外装插件。按 CtrlShiftP 打开命令面板输入 Git: Clone回车后粘贴 Gitee 仓库地址选择本地存储路径VS Code 就会自动克隆。克隆完成后点击左下角“打开文件夹”进入项目。左侧会多出一个“源代码管理”图标里面能看到所有变更文件、提交框和推送/拉取按钮。在 VS Code 里提交代码的步骤是先在源代码管理面板里点击文件旁边的 号把文件加入暂存区然后在上方输入提交说明点击“提交”最后点击“推送”按钮。拉取更新则可以通过 ... 菜单选择“拉取”或者直接用命令面板输入 Git: Pull。要注意的是VS Code 第一次推送时可能会弹出“没有配置 Git 用户”的提示。这时候回到终端执行 git config --global user.name/email 即可不需要在 VS Code 里单独操作。5.3 clone、pull、fetch 的区别与日常使用节奏很多新人会分不清 clone、pull、fetch 这三个词其实它们各自对应不同的场景。clone 是“克隆”只在第一次下载整个仓库时使用会复制完整历史和所有分支。pull 是“拉取并合并”把远端更新拉下来直接合并到当前工作区日常更新代码主要用这个。fetch 是“只取不改”它会下载远端更新到本地仓库但不会自动合并到工作区需要你手动决定怎么合并。我建议的个人工作节奏是每天开始写代码之前先 git pull 一次写代码过程中提交自己的修改推送到远端之前再 git pull 一次确保没有覆盖选举如果 pull 过程中出现冲突先在 IDE 里打开冲突文件看看哪些代码要保留解决后再提交推送。这个节奏看着简单但能避免绝大多数“我的代码怎么没了”的惨案。6. 大文件怎么传Gitee 的文件限制与绕过方案代码仓库本来是给代码用的不是给大文件用的。但很多项目里难免会有安装包、数据集、设计稿、编译产物新手往往会一股脑地 git add .结果 push 的时候被拒。这一章我把 Gitee 关于大文件的限制和合理做法讲清楚。6.1 Gitee 的文件限制到底是多少Gitee 作为托管平台会对仓库容量和单文件大小做限制。具体数值会根据套餐、仓库版本有所调整所以最准确的做法是看 push 时的报错提示当文件超过限制时Git 会直接告诉你哪个文件太大、超过多少。从实际体验来看一般超过几十 MB 的文件就会踩到提醒线而一个普通仓库如果塞进太多二进制文件即使能 push 成功后续每次 clone、pull 都会很痛苦。因为 Git 会保存每份文件的每个历史版本一个 100 MB 的压缩包哪怕后来删掉了它的历史记录依然在仓库里会一直拖着仓库体积。所以面对大文件的第一原则不是“想方法传上去”而是“别让代码仓库承担大文件存储”。源码、配置、文档这类文本文件进入 Git压缩包、模型、数据库备份这类二进制产物另想办法。6.2 用 Git LFS 管理大文件有些项目确实需要把大文件纳入版本管理比如游戏开发中的美术资源、AI 项目中的模型权重。Git 官方提供的解决方案是 Git LFSLarge File Storage。它的思路是把大文件的内容单独存储Git 仓库里只记录一个指针这样历史记录不会膨胀。标准用法如下。第一步安装 git-lfsWindows 用户到官网下载安装包macOS 用户可以用 brew install git-lfs。然后执行git lfs install接着声明哪些文件需要走 LFS。比如项目里有一个 models 目录可以执行git lfs track models/*.h5 git add .gitattributes.gitattributes 文件记录了 LFS 跟踪规则必须提交。之后对这些文件执行 add、commit、push操作和普通文件完全一样。需要特别提醒是否支持 LFS、免费套餐能存多少 LFS 容量要看你的 Gitee 仓库套餐。如果仓库后台没有看到 LFS 相关入口说明当前套餐可能不支持这时不要硬传直接看下面的替代方案。6.3 实在不行时改用 Releases 附件或外部存储如果你的 Gitee 仓库不支持 LFS或者大文件只是偶尔发布一次最简单的办法是利用仓库的“发行版”Releases功能。在 Gitee 仓库页面上找到“发行版”点“新建发行版”填写版本号和说明然后上传附件。Releases 附件本质上不是 Git 仓库的一部分而是挂在某个版本下的下载资源很适合放置安装包、压缩包、发布产物。它的好处是不影响代码 clone大家按需下载体积限制也相对宽松一些。但如果大到连 Releases 也传不了那就得考虑外部对象存储或网盘服务了。我的经验是在 README 里写清楚“资源文件下载链接”把大文件托管在存储服务上代码仓库只保留下载说明和校验值。这样既不影响团队协作也不会拖慢仓库操作。最后补充一个清理历史大文件的方法。如果仓库里已经误传过很多大文件普通删除文件并不会减小仓库体积因为历史记录还在。需要用到 git filter-repo 这类工具重写历史操作比较复杂而且要同步给所有人都重新克隆建议在没有同事的旧仓库里练习不要在公司主仓库贸然尝试。7. 子项目与多个仓库Gitee 仓库能包含子项目吗这个疑问几乎每个带过项目的人都会遇到我想把公共组件、后端、前端放在一起Gitee 的一个仓库里能不能包含多个子项目答案是可以但要分清楚“普通目录”和“独立子项目”的区别否则维护成本会越来越高。7.1 仓库里建多个子目录与独立子项目的区别如果你只是希望把几个相关的应用放在同一个代码仓库里维护比如一个后端服务加一个前端页面完全可以在一个仓库里建多个子目录就像这样my-project/ ├── backend/ └── frontend/这种“单仓库多目录”的方式优点是代码集中、依赖管理简单、一个 PR 可以同时改前后端适合中小型项目和整体发布。缺点是随着项目变大代码量会膨胀成员之间的权限无法按目录隔离。而“独立子项目”指的是每个子项目有自己的 .git 目录、自己的仓库地址、自己的版本历史和发布节奏。如果你想在 Gitee 上用多个仓库管理它们最标准的技术是 Git Submodule子模块。7.2 用 Git Submodule 管理子项目的完整操作假设你有一个主仓库 app里面要引用一个公共库 common。先在 app 仓库目录下执行git submodule add gitgitee.com:你的用户名/common.git common这条命令会把 common 仓库克隆到 app/common 目录同时在主仓库中记录子模块的版本信息。子模块在父仓库中保存的不是代码而是一个提交 hash这样两个仓库可以独立演进父仓库可以锁定子模块的某个版本。当你克隆包含子模块的项目时普通的 git clone 并不会自动把子模块文件拉下来你会在目录里看到空文件夹。需要额外执行git submodule update --init --recursive或者克隆时直接加参数git clone --recursive gitgitee.com:你的用户名/app.git日常开发中子模块本身的更新要在子模块目录里执行 git pull然后把更新后的 hash 在父仓库中提交一次。这也是新手最常踩的坑改了子模块父仓库却不提交导致别的同事拉下来时项目一直报错。记住子模块的变动必须“父仓库也提交一次”才算完成。Gitee 对子模块的支持是没问题的需要注意子模块仓库不能是私有且与父仓库权限不同的情况否则同事拉取时会报权限错误。处理方式要么统一公开要么在 Gitee 上把相关成员都加入为子模块仓库的协作者。7.3 什么场景建议拆成多个仓库到底把子项目放一个仓库还是拆成多个仓库这里没有绝对答案但根据我踩过的坑可以给出几条判断标准如果子项目会被多个不同项目复用例如企业内部的公共组件库、工具函数库建议单独建仓库并开放仓库权限用包管理器或子模块方式引进来。如果前后端团队经常各自独立发布前端资源打给前端团队后端资源打给后端团队建议拆开这样各自的分支、标签、发布记录都清晰。如果项目规模不大、团队人数少、发布经常跨模块协同建议先保持一个仓库不要过早拆散拆仓也是有成本的。用表格总结一下场景单仓库多目录多个仓库 子模块团队规模小团队亲密协作中大型团队职责隔离发布节奏模块间强耦合同步发布各自独立发布代码复用内部简单引用被多个项目复用权限控制仓库级控制无法按目录隔离可按仓库分别控制维护成本低高需要处理子模块同步8. 从“会用”到“天天用”我的一点工作流心得工具只有变成习惯才算真正学会。最后一个章节我不讲命令也不讲配置就分享几个让我从“会操作”变成“天天用”的小习惯以及踩过几次坑之后的教训。8.1 分支与推送规范个人项目可以只在一个 main 分支上维护想省事就直接 push。但只要有两个以上的人协作就要养成“不直接往主分支上推”的习惯。我的做法是每次功能开发新建一个分支例如 feature/user-login完成后再通过 Gitee 的 Pull Request 合并到 main。这样做的好处是代码在合并前多了一道人工检查环节问题能在上线前被发现。同时主分支永远保持可用状态即使某个功能分支改崩了也不会影响其他同事。对于不熟悉分支的新手记住一句话就够了一个功能一个分支合并完成后及时删除远端和本地分支。8.2 提交信息怎么写才有用我看到过很多新手的 commit 信息是 update、fix、修改这种信息三个月后回头看完全想不起来当时改了什么。我自己常用的格式是feat: 新增用户注册接口 fix: 修复登录超时导致页面白屏 refactor: 重构订单状态枚举 docs: 更新部署文档这种用“动词: 描述”的写法可以让 Git 日志变成一份自动更新的项目变更文档。以后出问题需要回溯时搜索一个关键词就能快速定位相关提交。如果你维护的是开源项目这份提交信息还能直接用于生成 release notes省时省力。8.3 我踩过的几个坑和对应的习惯最后一个大坑必须重点说把密钥文件传上仓库。有一次我不小心把包含私钥的配置文件交给了 Git虽然仓库是私有的但推上去之后立刻慌了。处理办法是立刻把文件移出版本管理并从远端删除同时重新生成密钥。从那以后凡是包含密码、密钥、Token 的文件一律放进 .gitignore绝不提交。还有一个很影响效率的坏习惯频繁产生零散提交。改一行字也 commit改一个样式也 commit导致历史像打了马赛克回退时根本没法定位。现在我尽量一个逻辑单位提交一次比如“修复用户注册页面表单校验”是一个完整提交“微调按钮颜色”只会在和它相关时一起提交不会单独占用一条记录。每天下班前还有一个动作很重要就是 git status 检查一遍。有时改了代码忘了提交第二天早上到了公司却发现同事已经等你推送很久了。养成“当天改动当天提交、提交后推送”的习惯后你会发现协作突然变得无比顺畅。这也是从“会用 Gitee”到“天天用 Gitee”的最后一层转变。