Necromanov刚开始用代码托管平台的时候，我其实一直在 GitHub 和 Gitee 之间来回折腾。GitHub 上资源多、社区活跃，但服务器在境外，push 和 clone 的速度经常让人血压飙升，尤其是项目里塞了几个大文件之后，等进度条简直是一种煎熬。后来切换到 Gitee（码云）之后，体验好了不止一点半点——仓库创建秒开、推送速度基本跑满带宽、中文界面也没有理解成本，对于国内开发者来说，Gitee 确实是日常托管代码最顺手的那个选择。
这篇博文把我实际使用 Gitee 这段时间积累的经验完整梳理一遍，从账号注册、创建仓库、命令行推送、SSH 免密配置，到 Gitee Pages 托管网页、分支管理和高频报错排查都有覆盖。不管你是刚接触 Git 的新手，还是习惯了 GitHub 想转回国内平台的老手，照着这套流程走一遍基本就能顺畅用起来。
1. 为什么选 Gitee：先搞清楚代码托管平台的定位
1.1 Gitee 和 GitHub、GitLab 的差异
很多刚接触 Git 的人会对这三个平台产生困惑，因为它们表面上都是“放代码的网站”，实际上侧重点完全不同。
GitHub 是全球最大的开源社区，生态最完善，各种开源项目、CI/CD 集成、Actions 自动化都是天花板级别，但国内访问速度不稳定，私有仓库虽然免费了，某些场景下协作体验还是受网络影响。GitLab 更偏向企业级私有化部署，功能极其庞大，从代码托管到 DevOps 全流程都能包揽，但自建 GitLab 对硬件和运维能力有要求，个人开发者用起来其实有点重。
Gitee 的定位就很清晰：国内开发者日常使用的代码托管平台。它兼容 Git 的所有标准操作，提供无限私有仓库，内置了代码质量检查、CI/CD、Pages 托管、企业版协作等功能。最关键的是服务器在国内，push 和 clone 的速度体验远超 GitHub。我在实际使用中的感受是，GitHub 更适合“看世界”，跟踪国外开源项目、参与社区讨论；Gitee 更适合“做事情”，日常开发、团队协作、部署个人站点，全流程都能在稳定的网络环境下完成。
1.2 Gitee 在本地开发流程中的位置
要理解 Gitee 能做什么，首先得明白 Git 和 Gitee 的关系。Git 是一个版本控制工具，它运行在你本地电脑上，负责记录文件每次的修改历史——谁在什么时候改了什么，都能完整追溯。Gitee 是一个托管平台，它相当于把本地的 Git 仓库同步到一台远程服务器上，起到备份代码、多人协作、发布部署的作用。
用一个生活化的例子来解释：Git 就像你电脑上的云盘客户端，负责管理本地文件的版本；Gitee 就是云盘服务器本身，存放所有同步上去的文件。你在本地提交代码（commit），然后推送到远端（push），别人再从远端拉取（clone 或 pull），合作就建立起来了。
理解了这层关系，后面所有操作都是围绕“本地 Git 仓库”和“远程 Gitee 仓库”之间的数据同步展开的。Gitee 本身不需要安装任何客户端，你只需要安装 Git，然后用命令行或者 IDE 自带的图形界面操作即可。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 从零准备：账号、Git 环境与第一个仓库
2.1 注册账号与实名认证
直接用 Gitee 之前，先花几分钟把账号准备好。打开 Gitee 官网，右上角有注册入口，支持手机号注册。这里提醒一句：注册后尽快完成实名认证，否则部分功能会受到限制——比如创建仓库后的某些操作、Gitee Pages 服务、Issue 创建等，都可能因为未实名而报错。
我在实际使用中踩过一个坑：创建 Issue 时一直提示验证码错误，换了浏览器、清了缓存都没用，最后发现是账号没实名，系统在验证步骤中反复要求校验身份。实名认证路径在“设置 -> 安全设置 -> 实名认证”，支持个人认证和企业认证，个人认证只需身份证信息，几分钟就能通过。
注册完成后，建议顺手在“设置 -> 基本设置”里把用户名和头像设置好。用户名会在仓库的访问地址中出现——比如用户名为 hgn977，那么你创建的仓库地址就是 https://gitee.com/hgn977/仓库名，这个地址以后会频繁用到，取一个好记的名字能省不少事。
2.2 本地 Git 安装与全局配置
Gitee 的网页端只是用来管理仓库的，真正把代码传到 Gitee 上需要借助本地的 Git 工具。Git 的安装很简单：Windows 用户去 Git 官网下载安装包，一路 Next 即可；macOS 用户可以用 Homebrew 安装，执行 brew install git 就行；Linux 用户用包管理器安装，sudo apt install git（Debian/Ubuntu）或 sudo dnf install git（Fedora）。
安装完成后，打开终端（Windows 用 Git Bash），先配置用户名和邮箱。这一步很关键，因为每次提交代码时，Git 都会用这个身份信息记录“是谁提交的”。配置命令如下：
bash复制git config --global user.name "你的名字"
git config --global user.email "你的邮箱"
我见过很多人跳过这一步，结果提交历史里显示的都是一串随机生成的默认名字，后期整理提交记录时非常痛苦。建议在配置时使用和 Gitee 账号一致的用户名和邮箱，这样提交记录能自动关联到 Gitee 账号上。
验证配置是否成功，执行：
bash复制git config --global --list
看到刚才设置的 name 和 email 就说明配置生效了。
2.3 创建远程仓库：选项怎么填、开源许可证选什么
登录 Gitee 后，点击右上角的“+”号，选择“新建仓库”，会看到一个表单，有几个字段需要仔细填写。
仓库名称：必填项，只允许字母、数字、下划线、中划线等字符。名称会出现在仓库访问地址中，建议用项目英文名或缩写，比如 my-blog、ecommerce-system。路径通常会自动关联仓库名，也可以手动修改。仓库介绍是个选填项，建议填上，让别人能快速了解项目用途。
开源许可证 的选择，这里多说几句。如果你创建的是公开仓库，最好选择一个许可证，否则代码默认是“保留所有权利”，其他人虽然能看到代码但不能合法使用。常见的选择有：
| 许可证 | 特点 | 适用场景 |
|---|---|---|
| MIT | 最宽松，允许自由使用、修改、商用，只需保留版权声明 | 个人开源项目、库文件 |
| Apache 2.0 | 宽松，额外提供专利授权保护 | 企业级项目、涉及专利的场景 |
| GPL 3.0 | 严格，衍生作品必须以相同许可证开源 | 希望代码永远保持开源的场景 |
| 不选 | 保留版权，他人只能看不能用 | 不打算让别人使用的项目 |
我的建议是：拿不准的时候选 MIT，这是最简单、最没有理解成本的许可证。如果是学习用的项目，选不选都无所谓，但选了 MIT 能让你的项目看起来更专业。
创建仓库时还有一个选择：是否用 README 初始化仓库。我个人建议底下的“使用 Readme 文件初始化这个仓库”勾选上，这样仓库创建后就不是完全空的，后续 clone、修改再推送的流程会更接近日常开发节奏。
3. 代码推送实战：覆盖最常用的三条路径
3.1 已有项目首次推送到 Gitee（命令行完整流程）
这是初学者问得最多的问题：“我本地已经有一个项目文件夹，怎么把它传到 Gitee 上？” 完整流程分四步。
第一步，在本地初始化 Git 仓库。进入项目文件夹，打开终端，执行：
bash复制git init
这条命令会在项目根目录生成一个 .git 隐藏文件夹，这个文件夹就是 Git 的“大脑”，所有版本信息都存在里面。执行完后，项目所在目录就被 Git 接管了。
第二步，添加远程仓库地址。在 Gitee 仓库页面复制仓库地址（HTTPS 或 SSH 都行，首次使用推荐 HTTPS），然后在本地执行：
bash复制git remote add origin https://gitee.com/你的用户名/仓库名.git
这里的 origin 是远程仓库的别名，是 Git 的默认习惯叫法，可以自定义，但没必要改。执行成功后可以用 git remote -v 查看远程地址是否配置正确。
第三步，添加文件并提交到本地仓库：
bash复制git add .
git commit -m "初始化项目"
git add . 表示把当前目录下所有文件加入暂存区，git commit -m "提交说明" 会把暂存区的内容提交到本地仓库，并附带一条提交说明。这里有个小技巧：提交说明不是随便写的，建议用简洁但有信息量的话描述本次改动，比如“初始化项目”是第一次提交，“修复登录接口返回 500 问题”是修 bug 的提交，这样以后回看历史时能快速定位每一次改动的目的。
第四步，推送代码到远程仓库：
bash复制git push -u origin master
首次推送时加上 -u 参数，作用是建立本地分支和远程分支的关联关系。以后执行 git push 或 git pull 时，Git 会自动知道该和哪个远程分支同步，不用再手写完整参数。
如果是第一次用 HTTPS 方式推送，Git 会弹出窗口要求输入 Gitee 的用户名和密码。这里的密码不是登录密码，而是 Gitee 的私人令牌（Personal Access Token），需要在“设置 -> 安全设置 -> 私人令牌”里生成。生成时勾选 projects 权限即可，生成的令牌要保存好，只显示一次。
推送成功后，刷新 Gitee 仓库页面，就能看到你上传的文件了。
3.2 日常更新与拉取：add/commit/push/pull 的正确姿势
项目跑起来之后，每天都会重复很多次“改代码 -> 提交 -> 推送”的操作。日常更新的流程其实就三个命令：
bash复制git add .
git commit -m "改了什么"
git push
这三个命令的顺序不能乱，逻辑是：先告诉 Git 哪些文件有改动（add），然后把改动记录下来（commit），最后同步到远程（push）。
如果项目是多人协作的，或者你在不同电脑上切换开发，推送前一定要先拉取远程更新：
bash复制git pull
git pull 的底层操作是 git fetch 加 git merge：先从远程下载最新代码，然后合并到你本地当前分支。如果你改了某个文件，远程也有人对同一个文件的同一行做了修改，就可能产生冲突。冲突发生时，Git 会在文件中标记冲突区域，需要你手动编辑解决——详见后面“常见问题”部分。
这里有一个容易忽略的点：每次提交前先执行 git status 看一眼当前状态，确认哪些文件被修改了、哪些文件是新添加的。这样能避免把不该提交的文件（比如 .env 配置文件、日志文件、临时文件）一起推送到远程。
3.3 用 VSCode 图形化操作替代记忆命令
命令行虽然高效，但对不熟悉终端操作的人来说还是有一定门槛。如果你用的是 VSCode，其实可以不用记命令，因为 VSCode 内置了完整的 Git 图形化操作面板。
在 VSCode 左侧边栏点击源代码管理图标（快捷键 Ctrl+Shift+G），就能看到当前仓库的改动列表。文件旁边的 + 号按钮可以把文件加入暂存区，输入提交信息后点击顶部的“提交”按钮完成 commit，点击“同步更改”按钮完成 push 和 pull。
这个方式的优势不仅是省去记命令，还能直观地看到每个文件的改动差异。点击任何一个文件，右侧就会显示这个文件的改动对比，哪些行是新增、哪些行是删除，一目了然。日常开发中，我先用 VSCode 的图形界面完成常规提交，遇到需要复杂操作（比如分支合并、rebase）时才切回命令行，两者结合效率最高。
4. 免密推送：配置 SSH Key 的核心细节
4.1 为什么要用 SSH
使用 HTTPS 方式推送时，每次都要输入用户名和密码（令牌），很繁琐。配置 SSH Key 之后，本地电脑和 Gitee 之间会建立一个加密的信任关系，推送和拉取代码不再需要输入任何凭据，这就是 Gitee 用户常说的“免密推送”。
SSH 免密的原理是密钥对机制：本地生成一把私钥和一把公钥，公钥交给 Gitee，私钥保存在本地。推送时，Gitee 会用公钥验证本地的私钥是否匹配，匹配就放行。私钥不出本地，安全性是可以放心的。
4.2 生成并配置 SSH Key 全流程
第一步，生成密钥对。打开终端，执行：
bash复制ssh-keygen -t rsa -b 4096 -C "你的邮箱"
回车后，终端会提示选择密钥保存路径，直接回使用默认路径即可。紧接着会提示输入密码短语（passphrase），这个可以直接留空，否则每次推送时还是要输入一遍密码，就失去了免密的意义。
执行完成后，在用户主目录的 .ssh 文件夹下会生成两个文件：id_rsa 是私钥（绝不能泄露），id_rsa.pub 是公钥（可以给任何人）。
第二步，复制公钥内容。执行：
bash复制cat ~/.ssh/id_rsa.pub
终端会显示一串以 ssh-rsa 开头、以你的邮箱结尾的长字符串，全部复制下来。
第三步，把公钥添加到 Gitee。登录 Gitee，进入“设置 -> 安全设置 -> SSH 公钥”，把复制的内容粘贴进去，输入一个标题（比如“我的电脑”），点击确定即可。
配置完成后，测试连接：
bash复制ssh -T git@gitee.com
如果显示 Hi 用户名! You've successfully authenticated, but GITEE.COM does not provide shell access.，说明配置成功了。之后把仓库地址换成 SSH 格式（git@gitee.com:用户名/仓库名.git），推送就再也不用输密码了。
4.3 HTTPS 方式记住密码和多账号切换的坑
有些场景下需要使用 HTTPS 方式，比如在公司的电脑上不方便生成密钥，或者是临时拉取一个公开仓库。这时可以通过配置 Git 的 credential helper 让 Git 记住凭据：
bash复制git config --global credential.helper store
配置后，第一次推送时输入一次用户名和密码，之后凭据会被明文保存在用户主目录的 .git-credentials 文件中，后续推送自动读取，不需要再输入。
但使用 HTTPS 时有一个坑需要特别小心：如果本机之前用 A 账号推送过，后来想切换到 B 账号，即使修改了代码仓库的 remote 地址，Git 依然会使用缓存里 A 账号的凭据，导致推送被拒绝（403 或权限错误）。解决方法是删除或编辑 .git-credentials 文件，或者执行：
bash复制git credential-manager erase
清除缓存的凭据后重新推送，输入新账号的密码即可。
5. Gitee Pages：把仓库变成可访问的网页
5.1 Gitee Pages 现状：实名认证和更新延迟
Gitee Pages 是 Gitee 提供的一项静态网页托管服务，可以把仓库里的 HTML/CSS/JS 文件直接发布成一个可访问的网站，类似 GitHub Pages。部署个人博客、项目演示页、前端页面都很有用。
但随着平台规则的调整，Gitee Pages 目前有一些限制条件：必须完成实名认证才能使用；免费版用户的 Pages 更新需要人工审核，通常要等待一段时间（短则几分钟，长则半小时以上），且没有自动更新机制——你不能像 GitHub Pages 那样 push 代码后页面自动刷新。
这里插一句，网上很多帖子说“Gitee Pages 没有了”，实际是 Gitee 在调整服务策略，Pages 功能依然存在，只是入口和审核机制变了。截至我写这篇博文的时间，Pro 版用户和通过实名认证的个人用户都能正常使用 Pages。如果你对自动构建部署有强烈需求，Gitee Pages 可能不是最佳选择；但如果你只需要部署一个“能访问的静态页面”，它完全够用。
5.2 配置 Pages 的步骤和注意事项
配置 Pages 前，先准备好一个静态网页仓库。最简单的方式是创建一个新的公开仓库，把 index.html 文件传上去，比如：
html复制<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="UTF-8">
<title>我的演示页</title>
</head>
<body>
<h1>Hello Gitee Pages</h1>
</body>
</html>
然后进入仓库页面，找到“服务 -> Gitee Pages”入口，会看到部署配置页面。首次使用需要先上传部署公钥——Gitee 会提示你添加一个 SSH 公钥，这个公钥用于让服务器拉取你的仓库代码，把它复制添加到仓库的部署公钥里即可。
之后选择部署分支为 master（或 main），目录保持默认 /，点击启动。等待审核通过后，你会获得一个 https://你的用户名.gitee.io/仓库名/ 格式的访问地址。
我实际部署时遇到一个坑：更新网页内容后重新部署，新内容不会立即生效，因为免费版有一个审核流程，即使是已审核过的仓库，每次更新都要重新触发审核。解决办法是点击部署页面上的“更新”按钮，等待审核完成后刷新页面。
5.3 把小程序项目拉到微信开发者工具的思路
很多人在热词里问“怎么把 Gitee 上的小程序项目拉到微信开发工具平台上”，其实思路很简单：WXSS/小程序本质上就是一个前端项目，代码托管方式和普通项目没有区别。先通过 git clone 把项目拉取到本地，然后在微信开发者工具中选择“导入项目”，路径指向你 clone 下来的项目根目录，填入自己的 AppID（没有 AppID 可以用测试号），开发者工具就能直接打开并编译运行。
这里要特别提醒：微信小程序的 project.config.json 文件通常包含了开发者工具的项目配置，一定要一起提交到 Git 仓库，否则别人 clone 下来后导入时可能需要重新配置很多项。还有小程序的 appid 字段一般是个人隐私信息，如果用私有仓库托管可以保留真实 appid；如果托管在公开仓库，建议把 appid 改成测试值，避免被他人冒用。
6. 协作与团队：分支、Issue 与 Pull Request
6.1 分支命名规范与日常操作
分支是 Git 最强大的功能之一。它允许你在同一个仓库里维护多条独立的代码线，互不干扰。Gitee 默认创建 master（或 main）分支作为主分支，实际开发中通常不会直接在主分支上改代码，而是为每个功能或版本创建独立的分支。
关于分支命名，我看过很多团队踩坑，最终沉淀下来一套相对实用的规范：
| 分支类型 | 命名格式 | 示例 |
|---|---|---|
| 主分支 | master / main | 保持不变 |
| 功能分支 | feature/功能名 | feature/user-login |
| 修复分支 | fix/问题描述 | fix/login-bug |
| 发布分支 | release/版本号 | release/1.2.0 |
| 开发分支 | develop | develop |
创建新分支并切换过去，一条命令搞定：
bash复制git checkout -b feature/user-login
checkout -b 的意思是“创建并切换”。创建后所有提交都会在这个新分支上，不会影响主分支。开发完成后，把分支推送到远程：
bash复制git push origin feature/user-login
然后在 Gitee 上发起 Pull Request（简称 PR），请求把功能分支合并到主分支。代码审查通过后合并，删除远端和本地的功能分支，一个完整的开发闭环就完成了。
6.2 创建 Issue 时验证码错误的排查
使用 Gitee 的 Issue（问题追踪）功能时，很多新手会遇到“验证码错误”提示。这个提示很让人迷惑，因为表单里明明没有验证码输入框。
我最初也因为这个困扰了很久，后来搞清楚了：Gitee 的 Issue 功能对未实名认证的账号会触发额外的安全验证机制，有时是弹窗验证码，有时是绑定手机号验证。页面提示“验证码错误”，实际上可能是你根本没有完成实名认证。解决办法是先去“设置 -> 安全设置 -> 实名认证”完成认证，再回来创建 Issue，大概率就能正常使用了。
另一个可能的原因是浏览器缓存了旧页面。Gitee 经过多次改版，前端的表单校验逻辑有变化，如果浏览器缓存的是旧版本 JS 文件，就会出现校验不通过的情况。强制刷新页面（Ctrl+Shift+R）或者换个无痕窗口试试，通常能解决。
6.3 Pull Request 和 Code Review 的实用流程
团队协作中，PR 是代码统一入口的有效手段。在 Gitee 上发起 PR 前，建议先确保本地分支已经完成以下操作：一是和主分支保持同步，避免合并时出现大量冲突；二是提交信息清晰，一个 PR 只解决一个问题，不要混合多个不相关功能。
发起 PR 时，Gitee 会展示一个对比页面，绿色是新增代码，红色是删除代码，审查者逐行查看并评论。我自己的经验是，PR 的描述字段千万不要留空，哪怕只是两句话，也要写清楚“改了什么”“为什么改”“是否测试过”。好的 PR 描述能让审查效率翻倍，也能让你在几个月后回顾这个 PR 时一秒了解当时的上下文。
7. 高频报错排查实录：我踩过的坑
7.1 clone 时提示 “git did not exit cleanly”
这个报错经常出现在 Windows 的图形化 Git 工具（比如 TortoiseGit）中，实际原因是 clone 操作没有成功，但工具没有把底层错误信息完整暴露出来。
排查思路按优先级排列：
| 可能原因 | 排查方式 | 解决办法 |
|---|---|---|
| 仓库不存在或地址错误 | 检查仓库地址是否完整，能否在浏览器中打开 | 用正确地址重新 clone |
| 权限不足 | 检查仓库是否为私有仓库，是否登录账号 | 配置 SSH Key 或使用正确账号 |
| 本地网络与 Gitee 连通性 | 尝试 ping gitee.com |
切换网络或配置代理 |
| 文件路径过长 | Windows 下路径超过 260 字符导致 | 修改 Windows 组策略启用长路径支持 |
| 本地 .git 目录损坏 | 检查当前目录是否有残留的 .git | 删除 .git 后重新 clone |
我在 Windows 上遇到这个报错，最终排查出来是路径过长问题。项目目录层级很深，加上仓库内的文件路径本身很长，超出了 Windows 的默认路径限制。解决办法是：先把项目 clone 到一个浅层目录（比如 C:\projects），同时通过组策略或 git config --system core.longpaths true 开启 Git 的长路径支持。
7.2 推送时提示 “Unable to access”
推送报 Unable to access 'https://gitee.com/xxx.git': Failed to connect to gitee.com port 443: Connection refused，多半是网络问题或者代理配置错误。
排查步骤：先检查 Gitee 网页能否正常打开，能打开说明网络没问题；再检查 Git 的代理配置：
bash复制git config --global --list | grep proxy
如果之前配置过代理，换网络环境后代理失效，就会导致连接被拒。清除代理配置：
bash复制git config --global --unset http.proxy
git config --global --unset https.proxy
重新推送基本就好了。还有一种情况是本地 hosts 文件被修改过，导致 gitee.com 解析到错误 IP，这时候把 hosts 文件里关于 gitee.com 的记录删除即可。
7.3 推送被拒绝：non-fast-forward 的解决思路
当你在本地提交代码后执行 git push，遇到 non-fast-forward 错误时，说明远程分支有本地没有的提交——最常见的情况是别人（或另一台电脑）已经往远程推送了新代码，而你本地还停留在旧版本。
解决方式有两种。推荐用 pull 先合并远程代码再 push：
bash复制git pull --rebase
git push
--rebase 会把本地的提交“搬到”远程最新提交的后面，形成一条线性的提交历史，比默认的 merge 方式更干净。如果 pull 时产生冲突，先解决冲突，再 git add，然后执行 git rebase --continue 继续。
另一种方式是强制推送 git push -f，但这是下下策。强制推送会覆盖远程已有的提交，如果远程分支上有别人的代码，会造成代码丢失。除非你很确定远程分支是你自己独占的，否则不要使用 -f。
我个人在实际开发中，每次 push 前都会主动执行 git pull --rebase，已经养成了习惯，因为冲突越早发现越好解决，堆到 PR 合并时才处理冲突，成本要高得多。
7.4 常见问题速查表
| 现象 | 最可能原因 | 快速解法 |
|---|---|---|
| push 需要反复输入密码 | 未配置 SSH Key | 生成公钥并添加到 Gitee，使用 SSH 地址 |
| clone 报错但浏览器能打开 | 本地网络或代理问题 | 检查 Git 代理配置，尝试 git clone 加 -v |
| 推送后网页不显示新内容 | 浏览器缓存 | 强制刷新（Ctrl+Shift+R） |
| 创建不了仓库 | 账号未实名 | 完成实名认证 |
| pull 时产生冲突 | 多人修改同一文件 | 手动编辑文件解决冲突后提交 |
| 403 推送被拒绝 | 凭据缓存错误账号 | 清除 credential helper 缓存后重新输入 |
| Issue 验证码错误 | 未实名认证 | 完成实名认证后重试 |
8. 最后再分享一个提升效率的小技巧
用得时间长了，我越来越觉得 Gitee 真正的价值不只是当一个“代码网盘”，而是它把整个开发生态都串起来了。我自己用 Gitee 做两件额外的事情：一是作为个人博客的托管平台，用 Pages 功能部署静态页面；二是把一些常用配置（比如 .vimrc、终端配置文件）放在私有仓库里，换电脑时直接 clone 下来就能恢复熟悉的环境。
这些小用法比单纯管理代码工程更贴近日常，也让 Gitee 真正成为个人开发环境的一部分。如果你刚开始用 Gitee，建议先把基础流程跑通——注册账号、创建仓库、push 代码、配置免密——然后再慢慢探索 Pages、Issue、PR 这些进阶功能。每个功能背后都有对应的真实场景，用到了自然就理解了。我最早也是从一条 git push 命令开始的，到现在已经习惯了离开 Git 就没法写代码的日子。工具终究是工具，能帮你稳定地管理代码、顺畅地协作，就是它最大的价值。