华为云CodeHub代码托管实战：从Git入门到仓库创建与代码推送

做技术这些年，我一直建议身边朋友把代码托管这件事认真对待。过去大家习惯把项目文件丢在U盘、网盘甚至微信文件传输助手里，等到要版本回退、多人协作、或者换电脑继续写的时候，才意识到问题有多痛。华为云CodeHub就是用来解决这个问题的——它的本质是一个基于Git的代码托管平台，你可以在上面创建私有或公开仓库，把本地代码推上去，之后所有修改都有历史记录，随时能回滚，也能多人并行开发。这篇教程我会从注册账号开始，带你走完"创建仓库→本地关联→首次推送"的完整链路，全程用最笨但最稳的方式，并把你大概率会撞上的报错一个一个拆开讲清楚。适合刚接触代码托管的初学者，也适合已经用GitHub但想在国内环境里找更稳托管方案的朋友。

1. 搞懂CodeHub：它到底是什么，能干什么

1.1 从一个提交记录说起

在开始操作之前，我想先用大白话讲清楚CodeHub在我们整个开发流程里扮演的角色。你可以把CodeHub想象成一个带完整历史记录的共享文件夹：你在本地写的每一份代码文件，经过git commit之后，就相当于在时间线上打了一个快照；再把快照通过git push传到CodeHub远端，就等于把这份快照备份到了云端。以后不管是你自己换电脑，还是同事需要接手项目，只需要git clone或git pull，就能拿到最新代码以及全部历史版本。

这个过程相比"把文件夹整个压缩发给你"有一个本质区别：Git记录的是每次提交的差异（diff），而不是每次复制整个项目。所以哪怕项目文件已经几百兆，几十个人每天提交几十次，仓库体积的膨胀速度也远低于直接复制。CodeHub作为云端托管端，还额外承担了权限管理、代码审查、合并请求（Merge Request）、问题跟踪这些团队协作能力，这是本地Git仓库根本做不到的。

1.2 为什么在华为云上选它，而不是直接用GitHub或Gitee

不少人会有疑问：我已经在用GitHub了，为什么还要用CodeHub？我给你梳理一下我的实际体会。

首先是网络稳定性。GitHub虽然功能全面，但国内直连经常出现断断续续的情况，尤其当你push一个包含较多历史提交的仓库时，跑到一半连接被重置是常有的事。CodeHub的服务器部署在华为云国内的Region（比如我用的华北-北京四），上下行速度非常稳定，全程没有那种"等半天没反应"的焦虑。

其次是和华为云生态的集成。如果你后续计划把代码部署到华为云服务器、用云上的编译构建服务做自动化部署，或者用CloudIDE做云端开发，那代码放在CodeHub里是最顺滑的——在控制台里就能直接把仓库关联到流水线，不需要来回复制地址、配置凭证。我见过很多团队代码存在GitHub，构建却要单独配置一堆Webhook和密钥，维护成本高且容易出安全问题。

第三是免费的私有仓库。个人开发者最关心的其实是私有仓库额度。CodeHub对于个人实名认证用户，私有仓库的空间和数量对绝大多数个人项目、毕设、小团队项目来说都是够用的，这一点和需要付费才有私有仓库的GitHub相比，对起步阶段的开发者友好很多。

1.3 动手前的准备清单

理想情况下，你只需要准备这几样东西就能走完整个流程：

• 一个华为云账号，并且已经完成个人实名认证（后面细说）
• 本地电脑上安装了Git工具，Windows用户推荐直接装Git for Windows，macOS用户可以用Homebrew安装
• 一份准备上传的本地代码文件夹，哪怕里面只有一个README.md也行
• 稳定的网络环境（正常家庭或办公网络即可，不需要特殊手段）

提示：请记住你的华为云账号密码，以及后续可能设置的访问令牌（Access Token）。我在第五节会专门讲密码和令牌的区别，这里先不展开。

2. 从零开始实操：5分钟完成本地代码上传

2.1 注册华为云账号并完成实名认证

访问华为云官网，点击右上角"注册"，按照流程填写手机号、邮箱、设置密码。这里有一个小技巧：注册完成后先别急着进CodeHub，先去控制台右上角账号头像下的"账号中心"里完成实名认证。个人开发者选择"个人认证"即可，需要提供身份证信息和人脸识别，一般一两分钟就能完成。

为什么我一直强调先实名？因为我踩过这个坑：你如果在未实名状态下进入CodeHub创建仓库，系统可能提示"服务未开通"或者"权限不足"。华为云的很多服务，尤其涉及代码托管这种可能包含敏感内容的功能，默认要求用户先完成实名认证。这个步骤虽然有点烦，但它不需要等待人工审核，是即时生效的，所以现在花两分钟，后面就顺畅了。

2.2 进入CodeHub服务并创建第一个仓库

实名认证通过后，在华为云控制台顶部的搜索栏直接输入"CodeHub"，点击搜索结果里的"代码托管 CodeHub"即可进入服务页面。还有一种方式是通过"开发者中心 → 代码托管"进入，不过直接搜索是最快的。

进入CodeHub页面后，点击"新建仓库"，进入仓库配置页面。这里我给你几个参考配置：

这里有一个容易忽略的选项：是否允许README初始化。我的建议是一开始勾选初始化，这样仓库会自动生成一个默认分支（可能是main或master），后面你git clone或push的时候不会因为"远端没有任何提交"而遇到一些麻烦。如果你完全不勾选，远端是一个空仓库，也可以推送，但对于新手来说，有README的仓库操作起来容错率更低。

点击"确定"后，仓库就创建好了。页面跳转到仓库详情页，你会看到一个HTTPS地址和一个SSH地址。这两个地址就是后续本地代码和远端仓库之间的"门牌号"，先复制出来备用。

2.3 在本地初始化并关联远程仓库

本地操作是我认为最容易出错的部分，所以我分几种情况讲清楚。

第一种情况：你本地已经有一个代码项目文件夹，还没有任何Git历史。

打开终端（Windows用户用Git Bash，macOS用户用Terminal），进入你的项目目录：

cd /path/to/your/project git init

git init会在当前目录生成一个隐藏的.git文件夹，从这一刻起，你的项目就处于Git托管之下了。接着把所有文件加入暂存区并提交：

git add . git commit -m "Initial commit"

然后添加CodeHub远程仓库地址：

git remote add origin https://codehub.devcloud.cn-north-4.huaweicloud.com/你的用户名/my-first-repo.git

这里origin是你给远端仓库起的别名，是约定俗成的默认叫法，你也可以改成别的，但建议不要，因为你后面会看到大量文档和命令都以origin为准，保持一致能少踩很多坑。

第二种情况：你本地还没有项目文件夹，或者想把远端的空仓库直接拉到本地。

git clone https://codehub.devcloud.cn-north-4.huaweicloud.com/你的用户名/my-first-repo.git cd my-first-repo

git clone会自动把远端仓库关联为origin，并且帮你建好本地分支，然后你只需要把代码文件丢进这个文件夹，再走一遍add → commit → push即可。

2.4 首次推送：见证"5分钟"目标的最后一步

如果你是用git clone方式，那么本地分支已经存在，直接进入目录后，把你准备好的代码复制进文件夹，然后：

git add . git commit -m "Add my project files" git push -u origin main

如果你是用git init方式在已有项目上操作，那么在git remote add origin之后也需要做同样的事。这里重点讲一下-u参数：-u全称是--set-upstream，它的作用是让本地当前分支与远端同名分支建立跟踪关系。设置之后，你以后再推送只需要执行git push，Git会自动知道"推送到origin的main分支"，不用每次敲全名。第一次推送时加上-u是推荐做法。

推送过程中，Git会提示你输入华为云的用户名和密码。这里有一个极容易让人抓狂的点：这个密码不是你的华为云登录密码，而是访问令牌（Access Token）或代码托管中设置的HTTPS口令。你在弹窗里输入自己华为云账号的登录密码，极大概率会报Authentication failed。正确做法是提前在CodeHub页面，找到"个人设置"或者"HTTPS密钥管理"，生成一个访问令牌，把这个令牌复制出来当密码用。

推送成功的标志是类似这样的提示：

To https://codehub.devcloud.cn-north-4.huaweicloud.com/你的用户名/my-first-repo.git * [new branch] main -> main Branch 'main' set up to track remote branch 'main' from 'origin'.

到这里，你的本地代码已经成功上传到华为云CodeHub，刷新仓库页面就能看到你刚刚提交的文件了。整个流程熟练之后，5分钟真的够用，第一次操作慢在配置令牌和阅读各种提示上，这很正常。

3. 常见报错与排查技巧实录

3.1 认证失败类错误：密码、令牌与权限

报错信息长这样：

remote: HTTP Basic: Access denied fatal: Authentication failed for 'https://codehub.devcloud.cn-north-4.huaweicloud.com/...'

这是我见到过最高频的报错，几乎每天都有群里的人来问。它出现的原因很简单：Git在通过HTTPS协议访问CodeHub时，需要你提供一组有效的"用户名+密码"，而这里的"密码"并不是华为云账号的系统登录密码，而是访问令牌。

解决办法分两步。第一步，进入CodeHub页面，找到个人账户设置，不同版本控制台的入口可能叫"个人设置""HTTPS密钥管理"或"访问令牌"，进去后点击"生成新令牌"，给令牌一个名称（比如"my-pc-git"），选择有效期和权限范围，一般选read_repository和write_repository就够用。生成后系统会展示一次令牌明文，一定要立刻复制保存。

第二步，回到终端重新推送，在用户名提示框输入你的华为云用户名（通常是手机号或账号名），密码提示框粘贴刚才复制的令牌。如果你的Git配置里已经缓存了错误的凭证，Windows用户可以在"控制面板 → 用户账户 → 凭据管理器"里找到对应条目删掉，macOS用户则需要在"钥匙串访问"里删除相关记录，否则下次推送还是会用旧密码，反复报错。

还有一种特殊情况：你没有这个仓库的权限。比如你用的是子账号，而仓库是主账号创建的，主账号没有授权给你。这种报错往往是Access denied或fatal: unable to access。排查思路是确认你登录的账号对这个仓库有没有Developer或更高权限，去CodeHub仓库的"成员管理"里检查一下。

3.2 仓库不存在与网络类错误

报错信息有两种常见形式：

fatal: repository 'https://.../repo.git/' not found fatal: unable to access 'https://.../': Recv failure: Connection was reset

前者"repository not found"的原因可能有三种：

• 仓库地址拼错了，比如用户名写错、仓库名大小写写错。Git仓库地址是区分大小写的，MyRepo和myrepo是两回事。
• 仓库是私有的，而你当前使用的账号没有访问权限。你在未登录状态下访问一个私有仓库的地址，Git也会报"not found"，因为它不会告诉你"这是权限问题"，这是一种安全设计。用对了凭证之后一般就能解决。
• 仓库真的不存在。你还没有创建仓库，或者已经被删除。回到CodeHub控制台确认仓库状态，如果被删除了，重新建房再关联即可。

"Connection was reset"这类网络错误，主要是本地网络到华为云机房之间的链路不稳定导致的。可以尝试更换网络环境（比如用手机热点），或者配置本地的HTTPS代理。这里要注意，如果你的电脑开了代理工具，也可能导致Git的HTTPS请求被代理干扰，反而报错。可以直接执行下面两条命令，临时禁止Git走代理：

git config --global --unset http.proxy git config --global --unset https.proxy

3.3 远端有本地没有的提交：push被拒

报错信息：

! [rejected] main -> main (fetch first) error: failed to push some refs to 'https://...' hint: Updates were rejected because the remote contains work that you do not have locally.

这个错误发生的场景很典型：你从网页端编辑了README，或者同事A推了一个提交，而你在本地也提交了代码，此时你本地的历史与远端的历史出现了分叉。Git出于安全考虑，拒绝你直接覆盖远端，要求你先把远端的最新提交拉到本地。

解决思路是"先拉后推"：

git pull origin main git push origin main

但这里又有一个新手很容易撞上的坑：如果你本地最初的提交记录和远端的历史完全不相干（比如你本地用的是master，远端是main，且两边没有共同的parent节点），git pull会报：

fatal: refusing to merge unrelated histories

这说明Git认为你本地和远端是两个完全独立的项目。解决方法是先拉取并允许合并无关联历史：

git pull origin main --allow-unrelated-histories

执行后Git会尝试把两边的文件合并到本地，如果同一文件两边都有内容的话，会提示你解决冲突。对于刚开始练习的场景，最简单的办法是：把本地代码先备份到别的文件夹，然后直接从远端clone一份干净的仓库，把代码复制进去再推。虽然显得笨，但成功率最高。只有当你确实需要保留本地已有的Git历史时，才值得去深入研究--allow-unrelated-histories的合并操作。

3.4 大文件、忽略规则与clone失败

CodeHub对单个文件的体积是有上限的，我记得应该是100MB左右。如果项目中不小心提交了一个几百MB的模型文件或压缩包，git push时会直接报错：

remote: error: File: xxx.zip is 214.83 MB; this exceeds 100 MB

这种问题处理起来有点麻烦，因为错误记录已经写入了本地的Git历史里。解决办法是使用git filter-repo或BFG Repo-Cleaner这类工具重写历史，把大文件从历次提交中彻底移除。但我不建议新手直接操作，风险较高，可能搞坏整个仓库。更好的策略是在源头就拦住它：在项目根目录创建或完善.gitignore文件，把构建产物、安装包、依赖目录排除掉。

一个常见的Java项目.gitignore长这样：

target/ *.class *.jar *.war *.log .idea/ *.iml .vscode/

对于Python项目，则建议加上：

__pycache__/ *.py[cod] .venv/ venv/ dist/ build/ *.egg-info/

如果你的项目确实需要管理大文件，比如游戏美术资源或深度学习的权重文件，请考虑Git LFS（Large File Storage）。CodeHub是支持LFS的，把大文件交给LFS管理，Git仓库本身依然保持轻量，clone和push的速度都不会被拖垮。

我还遇到过一种很隐蔽的报错：'origin' does not appear to be a git repository。这个不是网络问题，而是你本地仓库和远端仓库的关联信息丢了，或者你根本没有执行git remote add origin。排查命令非常简单：

git remote -v

如果输出为空，说明你的仓库还没配置远端，重新执行git remote add origin 仓库地址即可。

4. 进阶玩法：把CodeHub真正用好

4.1 配置SSH密钥，一劳永逸免密推送

如果你受够了每次推送都要输用户名和令牌，SSH方式是你的不二之选。SSH密钥的原理是在本地生成一对密钥（公钥和私钥），把公钥上传到CodeHub，之后Git向CodeHub发起连接时，CodeHub通过公钥加密挑战信息，本地私钥能正确解密，就验证了你的身份。整个过程不需要输入任何密码。

第一步，在本地生成密钥。在终端执行：

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

一路回车即可（对新手来说，不额外设置密码短语更省心），生成的文件默认在~/.ssh/id_rsa.pub。

第二步，查看公钥内容并复制到CodeHub。在终端执行：

cat ~/.ssh/id_rsa.pub

输出的一大段以ssh-rsa开头的内容就是你的公钥，全部复制。然后进入CodeHub的"个人设置 → SSH密钥管理"，添加一条SSH公钥记录，粘贴进去，取个好记住的名字。

第三步，测试连接：

ssh -T git@codehub.devcloud.cn-north-4.huaweicloud.com

如果提示Welcome to CodeHub或类似信息，说明SSH认证成功。以后你在CodeHub上复制仓库地址时，记得选SSH格式（形如git@codehub.devcloud.cn-north-4.huaweicloud.com:用户名/仓库.git），这样推送就自动免密了。注意，SSH端口默认走22，如果你所在的网络封了22端口，可以测试一下443端口的SSH连接，部分云托管平台支持这个备用通道，具体看CodeHub的官方帮助文档。

4.2 用分支管理你的开发流程

很多单干的朋友习惯所有代码都往main分支上推，这在项目早期完全没问题，但一旦涉及到"要给线上加个紧急修复，同时又在开发新功能"这种场景，没有分支会很痛苦。

基本的分支模型我建议这样用：

• main分支始终是可发布的状态，只允许合入经过验证的代码。
• 每次开发新功能前，从main拉出一个新的功能分支，命名随意但尽量有语义。

git checkout main git pull origin main git checkout -b feature/awesome-dashboard

你在功能分支上正常提交、推送，完成开发后，在CodeHub网页端给main分支发起一个合并请求（Merge Request）。其他成员可以在请求下评论、审查代码，确认无误后再合并。这样做的好处是明显的：main分支永远干净，任何时候都能基于它发版；如果某个功能开发到一半被废弃，直接删除分支即可，对主分支零影响。

我发现有不少人一开始嫌这套流程"多此一举"，但真正经历一次"线上出现bug，却因为本地一堆未测试代码而不敢修复"的窘境后，都会主动回归分支规范。在CodeHub上操作分支和合并请求的入口很直观，多试两次就熟了。

4.3 利用CodeHub的代码审查与问题跟踪

团队协作时，CodeHub提供的合并请求（Merge Request）和问题跟踪（Issue）功能非常实用。前者结合分支模型使用，后者可以记录你发现的bug、待办的需求、改进想法，每一条issue都能关联提交记录、指派负责人、设置优先级，项目脉络一目了然。

还有一个小细节：在提交信息中可以直接关联issue编号，比如提交信息写fix #123，等这次提交合并到主分支后，系统会自动把issue标记为关闭（具体语法可能略有差异，以CodeHub页面提示为准）。这种"提交即关联"的操作让项目进展非常透明，我推荐每个人从写代码的第一天就养成规范提交信息的习惯。一个标准的提交信息可以长这样：

feat: add login page - support phone number login - add verification code module - fix #15

类型前缀（feat、fix、docs、refactor等）是Conventional Commits规范里的约定，CodeHub不会强制，但团队约定俗成后，翻历史记录的效率会高很多。

4.4 与华为云DevCloud和CI/CD流水线打通

CodeHub最大的优势之一，就是它与华为云DevCloud系列服务的无缝联动。你不需要把代码下载到本地再手动部署到服务器，直接在CodeHub仓库页面创建流水线，把"获取源码 → 编译构建 → 部署上线"这几个阶段串起来。

举个最简单的例子：你有一个Node.js项目，希望每次往main分支推送代码后，自动在云端执行npm install和npm run build，然后把构建产物部署到一台云服务器上。在华为云DevCloud的流水线服务里，选择CodeHub源码源，指定仓库和main分支，添加一个构建任务（选择Node.js构建镜像），再添加一个部署任务（填写服务器IP和部署脚本），一个基础的CI/CD就搭好了。从此之后，你只管推送代码，剩下的事情流水线自己会做。

这前后端的体验跨度很大——从一个"上传代码的工具"，变成"驱动自动化流程的源头"。我是强烈建议所有CodeHub用户都去试着配一次流水线的，哪怕只是构建一下然后打印一行"hello"，它带给你的视角变化是纯代码托管没法给的。不过这一步内容量很大，我今天先不展开，后续可以单独写一篇流水线的实操教程。

5. 写给大家的避坑心得

总结一下我这几年来用CodeHub、也用过其他代码托管平台之后沉淀下来的几点体会。

第一，遇到报错先冷静，把整行报错信息复制到搜索引擎里，而不是只看最后几个单词。很多人一看到fatal就慌了，其实fatal在Git里只是一个普通的错误级别标识，后面的完整提示才真正告诉你问题在哪。比如fatal: Authentication failed for 'https://...'，最核心的信息是"认证失败"，和网络无关、和代码无关、和仓库是否存在也无关。

第二，访问令牌（Access Token）用完一定要妥善保存，它是你HTTPS方式下最高的凭证。如果令牌泄露，别人就能随意读写你的仓库。我的做法是给每台设备单独生成一个令牌，设备不用了顺手删除对应的令牌，避免一把钥匙走天下的风险。令牌权限也要遵循最小化原则，只给read_repository和write_repository，不给删除或管理权限。

第三，提交信息的质量决定你项目历史的可读性。《编写优质提交信息的核心技巧》这类文章很多，但核心就是一句话："为代码写说明，而不是为Git写日志"——把"添加了xxx功能"拆开讲清楚为什么做这件事，比写一百个字面描述有用得多。我见过同事写update file这种提交信息，过了两周连他自己都不记得改了什么。

第四，git pull之前建议先git stash保存你未提交的改动，否则当本地有冲突时，Git会拒绝拉取。新手经常在这里卡住，以为自己的代码全丢了。其实stash就像代码的临时储物柜，改完冲突后随时可以再把改动取回来：

git stash # 暂存未提交的改动 git pull # 拉取远端 git stash pop # 恢复改动

第五，不要因为嫌麻烦就不写.gitignore。它可能是你从"能用"到"好用"的分水岭。很多初学者第一次上传项目，把node_modules（几万个依赖文件）也推上去了，导致每次操作慢到怀疑人生，仓库体积也瞬间爆炸。从项目第一天就写一份贴合语言的.gitignore，后面受益无穷。

我在实际使用中最深的感受是：CodeHub这类平台真正的价值不在于"有个地方存代码"，而在于它强制你建立起"版本思维"和"协作习惯"。当你习惯了每次提交都带着明确意图、每次合并都走审查流程、每个问题都有迹可循之后，你写的代码质量和开发的顺畅度，都会往上走一个台阶。如果你现在还在"本地写代码、文件名加v2、v3、最终版"的状态，我想说的是，是时候改变一下了。Git的入门门槛没有你想象中那么高，今天这篇教程里的命令，能解决你90%的日常需求，剩下的10%，等你真正遇到了再去搜索、去解决，那时候你已经有足够的能力判断什么是靠谱的答案了。