企业官网建设流程全解析

先交代一个真实的场景：很多人第一次接触代码托管平台，都是从网页端“拖文件”开始的。文件小、数量少的时候还能忍，一旦项目跑起来，几十个依赖文件、频繁的小改动，再点网页上传就完全不是那么回事了。于是开始搜“git怎么上传代码”“gitee上传代码到仓库”，折腾半天才搞明白，原来本地要装一个叫Git的工具，命令行的操作方式也和平时用的软件完全不同。

这篇就完整走一遍“Gitee上传代码”的流程，从装Git开始，到配置SSH密钥、创建仓库、首次推送，再往后日常迭代的pull、push、分支、冲突，以及几个高频报错的排查。适合刚接触Git、第一次用Gitee的人，也适合那些已经能提交代码、但遇到“拉取不下来”“推送失败”“多个仓库冲突”等具体问题的人。我尽量把每一步为什么这么做也说清楚，而不是只丢给你一串能跑的命令。

1. 动手前的一个小时：注册账号、装好Git、弄清三个核心概念

1.1 注册Gitee账号并验证邮箱

Gitee（码云）的注册流程没什么特别的门槛，进官网点注册，填手机号或邮箱，收个验证码就完成了。这里提醒一句，注册完一定要去验证邮箱，因为后续很多操作——包括网页端创建仓库、接收通知、找回密码——都依赖邮箱。这个动作容易忽略，但没验证邮箱的话，后面不管是用SSH还是HTTPS方式推代码，都可能莫名其妙地遇到权限问题。

个人用户尽量把账号的实名认证也顺手做掉，因为Gitee在某些功能上要求完成实名认证才能使用，比如后面会提到的Gitee Pages、部分仓库的评论和Issue功能。虽然这只是网页端的限制，不影响本地Git操作，但早点认证完省得用到的时候卡住。

1.2 安装Git：Windows、macOS、Linux各说一遍

Git是本地操作的核心工具，你的代码先提交给Git管理，再由Git推送到Gitee。没装Git，后面一切命令都谈不上。

• Windows用户：去Git官网下载安装包，安装时基本全程默认下一步就行。有两个地方建议手动改一下，一是安装过程中的“选择默认编辑器”那一步，把默认的Vim换成VS Code、Notepad++或你习惯的编辑器，否则后面写提交信息卡在Vim里会很难受；二是“调整PATH环境变量”保持默认的“Git from the command line and also from 3rd-party software”，这样CMD、PowerShell、PyCharm这些工具才能直接用git命令。

  装完验证一下，打开Git Bash，输入：

  git --version

  能输出版本号就说明装好了。

• macOS用户：macOS自带的xcode-select工具里其实有Git，但版本往往偏旧。我建议用Homebrew装最新版：

  brew install git

  没有Homebrew就先执行/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"装Homebrew，然后再装Git。

• Debian/Ubuntu用户：

  sudo apt update sudo apt install git

  装完同样用git --version验证。

安装Git本身不复杂，但注意安装完要新开一个终端窗口再执行git命令，因为在旧的终端里PATH还没刷新。很多人装了git然后报“找不到命令”，多半就是这个原因。

1.3 工作区、暂存区、本地仓库——三个区域必须搞清楚

新手学Git容易懵，不是因为命令多，而是脑子里没有“三个区域”的模型。我把它们对应到日常场景：

• 工作区：就是你电脑上能看到的项目文件夹，里面是真实文件。你改代码、加文件，改的都是工作区的内容。
• 暂存区：可以理解成一个“候车厅”。git add就是把文件从工作区送进候车厅，表示“这些文件我改完了，待会儿要提交”。为什么要有这一步？因为有时候一个项目里同时改了10个文件，但只想先提交其中3个逻辑相关的，暂存区给了你挑选的机会。
• 本地仓库：git commit之后，候车厅的文件才正式存档进本地仓库，生成一条提交记录。这一步之后，你的改动就有了完整历史版本。

Gitee上的远程仓库则是本地仓库的“异地备份”。git push是把这个存档推送到远端，git pull是拉取远端的存档到本地。理解这条链路之后，你再看任何Git教程，就不会被术语淹没了。

# 工作流全景 git add . # 工作区 -> 暂存区（. 表示所有文件） git commit -m "描述" # 暂存区 -> 本地仓库 git push # 本地仓库 -> 远程仓库

提示：.是通配符，表示当前目录下所有改动文件，也可以换成具体文件名，比如git add index.html。用git add .虽然方便，但如果仓库里有不该提交的文件（后面会讲.gitignore），就会一起进暂存区。

2. SSH密钥配置：花十分钟折腾一次，以后省下无数遍输密码

2.1 为什么推荐SSH而不是HTTPS

Gitee支持两种连接方式：HTTPS和SSH。HTTPS首次推送要输用户名密码，之后在Windows凭据管理器里记住也行，但命令行里频繁输密码真的影响效率。SSH协议走密钥配对，本机生成一对公私钥，把公钥放到Gitee后台，之后push和pull都不会再要密码。

日常使用中，SSH是最省心的方式，尤其当你有多台电脑、多个平台账号时，配置好之后一劳永逸。而且SSH走的是密钥认证，比HTTPS输密码更安全——密码可能被盗或泄露，私钥只要不离开你本机，别人很难伪造你的身份。

2.2 生成密钥的完整命令

打开Git Bash，执行：

ssh-keygen -t ed25519 -C "你的邮箱@example.com"

-t ed25519是指定加密算法。GitHub和Gitee都支持ed25519，密钥短、生成快、安全性也比老旧的RSA 2048强。如果你老系统的服务器不支持ed25519，才需要用ssh-keygen -t rsa -b 4096走RSA。

执行之后会提示你选择保存位置，直接回车，默认会存到用户主目录下的~/.ssh/id_ed25519。接着提示设置私钥密码（passphrase），这一项可以留空直接回车，但建议填一个。虽然每次连接时会增加一步输入，但私钥文件被盗走时，没有密码别人也用不了。

# 生成完成后查看公钥内容 cat ~/.ssh/id_ed25519.pub

公钥长这样：

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... 你的邮箱@example.com

2.3 把公钥贴到Gitee后台

登录Gitee网页端，进入右上角头像菜单里的“设置”，然后在左侧菜单找到“安全设置 -> SSH公钥”。把你刚才cat出来的那一整行公钥粘贴进去，标题随便起个名字，比如“家用电脑”或“办公室笔记本”，方便以后管理多台设备。

贴完公钥后测试连接：

ssh -T git@gitee.com

第一次连接会提示你确认主机指纹，输入yes回车。如果看到类似这样的输出，说明配置成功：

Hi 你的用户名! You've successfully authenticated, but GITEE.COM does not provide shell access.

看到这句就踏实了，SSH通道已经打通。

注意：ssh -T git@gitee.com用的是git@gitee.com，不是你的邮箱。这个地址是Gitee固定的接入地址，所有用户都用同一个，服务端靠公钥来识别你是谁。

2.4 多台电脑、多个平台账号的密钥管理

如果你除了Gitee还用了GitHub、GitLab，或者家里电脑、公司电脑都要向Gitee推代码，每个设备生成独立的密钥对更安全。你可以在~/.ssh目录下建一个config文件，把不同平台的密钥对应关系写清楚。

比如我本机就同时配了Gitee和GitHub的两个密钥：

# ~/.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

这样git命令在连Gitee时自动读gitee的私钥，连GitHub时读github的私钥，互不干扰。这一节的细节特别容易踩坑：很多人两个平台用了同一个密钥，或者在config文件里写错大小写，导致连接时“错钥”认证失败。配置文件里Host名、IdentityFile路径必须和你实际生成的密钥文件名完全一致，一个字母都不能差。

生成针对Gitee的专属密钥时，可以指定文件名：

ssh-keygen -t ed25519 -C "gitee工作邮箱@example.com" -f ~/.ssh/id_ed25519_gitee

这样密钥对就生成在指定路径，再配合上面的config文件，多平台账号就不会互相打架了。

3. 从零到首次推送：创建仓库、绑定远程、push上去

3.1 在Gitee网页端新建仓库

登录Gitee，右上角“+”号选择“新建仓库”，或者在首页直接找到“创建仓库”按钮。填表时有几个字段我重点说一下：

仓库名称必填，建议全小写加短横线，比如my-first-project。名称会直接体现在仓库访问路径里：https://gitee.com/你的用户名/my-first-project，起得规范一点，分享给别人时也清爽。

开源许可证这一栏，很多新手不知道选什么。如果你的项目真的要开源给别人用，MIT是最宽松的，别人拿走随便改随便商用，只要保留你的版权声明；如果希望别人使用你代码后，改动的代码也必须开源，选GPL-3.0；如果别人可以用你的代码，但改动部分必须用相同许可证开源，选MPL-2.0。如果只是自己练习、不打算开源，直接选“不使用”或“自定义”，许可证这块不影响上传代码本身。

.gitignore模板建议选中，Gitee提供了Java、Python、Node.js等语言模板，选了之后仓库初始化时会自动生成一个.gitignore文件，把依赖目录、编译产物都忽略掉，避免把node_modules、target这些乱七八糟的目录推到远程仓库。

初始化仓库这一类里，可以勾上README.md和.gitignore，但不要勾开源许可证如果你还不确定用哪个。初始化时带上README文件的好处是，仓库克隆下来就有一个说明文件，不会是个空壳。

创建完成后，你会看到仓库地址，一行是HTTPS，一行是SSH。后面要用的是SSH地址，形如git@gitee.com:用户名/仓库名.git。

3.2 本地初始化并完成首次推送

在本地项目根目录下打开Git Bash，执行：

# 1. 初始化一个空的git仓库 git init # 2. 查看当前状态（这是使用频率最高的命令之一） git status # 3. 把项目所有文件加入暂存区 git add . # 4. 提交到本地仓库，第一次提交信息一般写 init 或 first commit git commit -m "first commit"

如果第4步报错提示需要配置user.name和user.email，那就先执行下面两条：

git config --global user.name "你的用户名" git config --global user.email "你的邮箱@example.com"

然后把提交那步再执行一遍。全局配置只需要做一次，之后所有仓库都会自动继承这两个身份信息。

本地提交完成后，把本地仓库和远程仓库关联起来：

# 用SSH地址关联远程仓库，origin是远程仓库的默认名字 git remote add origin git@gitee.com:你的用户名/你的仓库名.git # 推送本地master分支到远端，-u 表示记住这个关联关系 git push -u origin master

绝大多数新手会卡在这一步。如果执行完没有报错，并出现类似master -> master或者main -> main的输出，就说明代码已经推到Gitee上了。回到网页刷新一下仓库页面，应该能看到你推送的文件。

3.3 master和main：分支命名为什么对不上

这是高频疑问。最初Git默认分支叫master，很多老教程里写的都是git push -u origin master。但后来社区出于技术中性的考虑，新仓库默认分支逐渐迁移到main。Gitee新建仓库时默认分支名是master，如果你给本地的分支也是master，那就直接推。如果你本地是main分支，就要写成：

git push -u origin main

如果你落地到Gitee后发现远端分支叫master，本地分支叫main，可以用git branch -m master main把本地分支重命名，再推送。也可以用git push origin main:master这种“源分支:目标分支”的推送语法，把本地main推到远端master，但这容易让新手迷糊，不推荐。保持两端同名分支是最省心的。

3.4 网页上传zip的问题：为什么强烈不推荐

Gitee网页端也支持直接上传文件，甚至拖拽Zip压缩包，仓库会自动解压。这种方式代替不了命令行推送，原因有三：

一是没有版本历史。你上传10次文件，仓库里只是10份不同时间的文件快照，没有一个递进的提交记录，想看“某一行代码是什么时候改的”完全无从下手。

二是大文件传不上去。网页端单文件有大小限制，超过一定体积直接失败。命令行推送没有这样的困扰，大文件照常推。

三是无法解决协作问题。只要你想拉取别人的改动、合并分支、回滚版本，就必须用Git操作。网页上传只是把文件放进仓库，电子表格里的“文件”和Git仓库里的“提交”是两回事。

所以我的建议是：网页上传只适合临时放几个静态文件，真正开发一定要走命令行或IDE集成的Git流程。

4. 日常迭代的正确姿势：pull、push、分支管理与冲突处理

4.1 每天最标准的操作节奏

项目跑起来之后，你的日常流程会固定成四部曲：

# 1. 先拉取远端最新代码，避免你的本地版本落后 git pull # 2. 改代码...（在工作区修改文件） # 3. 查看改动状态 git status # 4. 提交并推送 git add . git commit -m "这次改了什么" git push

为什么第一步要pull？因为如果你和同事同时在开发，对方先推了代码，你本地就落后了。你直接改代码、提交、推送，大概率会撞上“远端有更新而被拒绝推送”的提示。Git的模型是你必须在远端最新代码的基础上提交，git pull就是把远端更新合并到本地，让你的提交建立在最新状态上。这条铁律养成习惯后，冲突会少很多。

git status也有讲究，它会告诉你当前分支落后还是领先远端（比如Your branch is ahead of 'origin/master' by 1 commit），这个信号比你自己记忆可靠多了。

4.2 拉取不下来？先分清是网络还是仓库问题

“clone仓库半天没反应”是Gitee用户最常遇到的问题之一。首先要分清两种情况。

第一种是网络层面。国内访问Gitee本身比较快，但如果你本地网络走了一些特殊设置或代理，反而会让SSH的连接失败。排查时可以先看是不是网络代理配置导致的，把代理关掉再试。

第二种是仓库本身比较大。如果仓库里有大量二进制文件（图片、视频、打包产物），clone时可能需要较长时间，看起来像卡住了，但实际上在下载。可以用git clone --depth 1做浅克隆，只拉取最近一次提交，节省大量时间。缺点是只保留最新状态的快照，没有完整历史，适合临时想看代码的人。

TortoiseGit的用户可能遇到过“右键克隆失败”的情况。这个问题多半出在TortoiseGit默认使用PuTTY风格的Pageant密钥管理，而你生成的是OpenSSH格式的私钥。解决方法是：在TortoiseGit设置里把SSH客户端改成C:\Program Files\Git\usr\bin\ssh.exe，或者用TortoiseGit自带的PuTTY Key Generator把OpenSSH私钥导入并保存成.ppk格式，再用Pageant加载。这一步只想强调一点：TortoiseGit和Git命令行虽然共用git命令，但SSH密钥管理机制不互通，这是大多人“拉取不下来”的根源。

4.3 分支操作：建立gitee分支结构的基础命令

分支是Git最强大的特性，几乎没有之一。它让你可以同时在多条开发线上工作，互不干扰。

# 创建并切换到新分支 git checkout -b dev # 等价做法（拆开写） git branch dev git checkout dev # 从dev分支提交代码，推送到远端并建立关联 git add . git commit -m "开发新功能" git push -u origin dev # 切回主分支并合并dev git checkout master git merge dev # 删除本地dev分支（已合并） git branch -d dev # 删除远端dev分支 git push origin --delete dev

-b是“branch”的缩写，checkout -b dev等于“创建dev分支并切过去”。push -u origin dev除了推送，还记录了本地dev和远端dev的关联关系，以后在dev分支上直接git push就够了。

分支结构怎么设计看团队习惯，个人项目最简单的做法是：master/main保留稳定可发布版本，日常开发都在dev分支上，开发完合并回主分支。如果你有Gitee Pages之类的自动部署需求，还可以把生成好的静态文件单独放一个gh-pages分支，和源码分支分离。

4.4 冲突到底是个什么东西

冲突是人人都怕、但人人都逃不掉的环节。它本身不是错误，而是Git在说“我不知道该听谁的”。发生冲突时，Git会在冲突文件里插入这样的标记：

<<<<<<< HEAD 这是你本地版本的内容 ======= 这是远端版本的内容 >>>>>>> 分支名

HEAD表示当前所在分支（本地版本），=======下面的是远端拉下来的版本。你需要逐行检查，保留需要的部分，把标记符号和不要的内容删掉，保存文件，然后：

git add 冲突文件名 git commit -m "解决冲突"

注意，解决冲突不能在暂存区直接完成，必须先编辑文件、再add标记为已解决、最后commit。很多新手看到冲突提示后直接懵了，或者把文件删掉重来，其实只要冷静处理，冲突解决的难度远低于想象。

减少冲突的方法：代码改动前先pull、改动尽量拆小、多提交；多人协作时避免同时大范围改动相同文件。冲突不是烂摊子，而是协作的一部分，处理多了就习惯了。

5. 几个高频进阶操作：多账号、amend、worktree与.gitignore

5.1 本地全局设置Gitee和GitHub冲突怎么破

网上教程鱼龙混杂，很多教程都让你git config --global设一遍user.name和user.email，但如果同时用Gitee和GitHub，不同平台可能想用不同身份（或者同一个身份、不同邮箱），全局配置就会互相覆盖，导致一个平台的提交记录显示的不是你想要的作者名。

解法有两条路：

**第一条路，给每个仓库单独设置身份，不设全局user.name和user.email。**进入某一个仓库目录后，执行：

git config user.name "Gitee专用名字" git config user.email "gitee邮箱@example.com"

不带--global的参数只对当前仓库生效。这个方式简单直接，适合用得少、仓库少的场景。

**第二条路，按目录施加条件配置。**在全局配置里追加这样一段：

# 在 ~/.gitconfig 里 [includeIf "gitdir:~/work/gitee/"] path = ~/.gitconfig-gitee [includeIf "gitdir:~/work/github/"] path = ~/.gitconfig-github

然后在~/.gitconfig-gitee文件里写Gitee专用身份，在~/.gitconfig-github里写GitHub专用身份。Git 2.13以上版本支持includeIf，它会根据仓库所在的目录路径自动加载对应配置文件。同一个目录下的所有仓库就会自动用该平台的配置，彻底解决“全局配置冲突”。这个方法适合仓库数量多的人，多花10分钟配置，之后省心很多。

5.2 git commit --amend：后悔药怎么吃才安全

git commit --amend用来修改最近一次提交。典型场景有三个：

• 提交信息写错了，比如把“修复登录bug”写成了“修复登bug”；
• 漏了一个改动文件，想把补进去并合并成同一次提交；
• 想把两次提交合并成一次。

用法：

# 修改上一次提交的说明文字 git commit --amend -m "新的提交信息" # 修改上一次提交的说明，进入编辑器（适合多行说明） git commit --amend # 漏了文件，补进去 git add 漏掉的文件 git commit --amend --no-edit

--no-edit表示沿用上一次的提交信息，不用重新输入。

最重要的一个警告：commit --amend会改写提交历史。如果这个提交还没有推送过，随便改；如果已经推送到了Gitee远端，并且可能被别人拉取使用过，不要amend。因为改写历史会导致远端和本地的提交记录对不上，别人pull时会出现复杂的分叉或冲突。万不得已非改不可，就得用git push --force-with-lease，但强制推送会覆盖远端历史，对协作项目风险很大。我的原则很简单：推送过的提交，就别再amend了，错误信息不值得用团队协作的稳定性去换。

5.3 git worktree：一个仓库并行检出的好工具

git worktree是相对冷门但非常实用的功能。它允许你在同一个仓库下，同时检出多个分支到不同的目录。比如说，你正在master分支改一个功能，但突然需要去dev分支看个问题，正常情况下要先commit或stash再切换，来回折腾。用worktree：

# 在 ../my-project-dev 目录检出dev分支 git worktree add ../my-project-dev dev # 现在可以同时打开两个项目目录，一个在master，一个在dev cd ../my-project-dev git status # 能看到当前在dev分支 # 用完移除这个worktree git worktree remove ../my-project-dev

worktree的好处是：不同分支的编译产物不会相互污染，不用重复clone几份仓库，磁盘空间也省。适合那些需要频繁在多分支间切换做临时修复的人。第一次用的时候，注意worktree目录不要放在主工作区里面（比如不要放成项目目录/dev），否则会引发嵌套仓库的递归问题。安全做法是和主仓库平级。

5.4 .gitignore：哪些文件打死也不能提交

.gitignore文件的作用是告诉Git“这些文件忽略掉，不要跟踪”。我见过太多新手直接把整个项目推上去，结果把node_modules几百MB的依赖、IDE的缓存目录、甚至.env里的数据库密码都传上了Gitee，既拖慢仓库又埋下安全隐患。

一个典型的Node.js项目的.gitignore长这样：

node_modules/ dist/ build/ .idea/ .vscode/ *.iml .DS_Store *.log .env .env.local

Gitee新建仓库时选的模板会生成一个基础版本，但模板覆盖不到你项目的特殊目录。写了.gitignore之后，如果文件已经被Git跟踪过（以前提交过），光写进.gitignore不会让它停止跟踪，必须执行：

# 从Git索引里移除该文件，但保留本地文件 git rm --cached 文件名 git commit -m "从版本控制中移除敏感文件"

这个细节很值得记住，否则你会遇到“明明加了.gitignore，push上去还有那个文件”的疑惑。

另外，线上服务器部署的web根目录下不要暴露.git目录。如果某个目录存在git仓库，且该仓库里有敏感历史记录（比如曾经提交过数据库密码），攻击者可以通过访问/.git/路径直接下载整个仓库的历史，这是常见的信息泄露途径。排查方法很简单，浏览器直接访问你的站点https://域名/.git/config，如果返回了文件内容而不是404，说明这个目录的安全规则没配好，应该在Web服务器层面禁止访问所有以.开头的目录。这件事和“上传代码”直接相关，因为代码托管到Gitee代表公开了一部分信息，但公开到Gitee的只是你推送的分支历史，而不是本机.git目录里你可能忘记推送的东西。

5.5 Gitee Pages：把仓库变成可访问的网页

热搜词里有“gitee pages”，顺手说一下，因为它本质上就是“上传代码之后的一步延伸”。Gitee Pages可以把仓库里的静态页面通过https://你的用户名.gitee.io/仓库名/这样的地址公开展示，适合个人主页、项目文档站、纯前端Demo。

使用条件：仓库必须有静态内容（HTML/CSS/JS），且开启Pages服务前需要先在仓库设置里找到“Gitee Pages”，选择要发布的分支和目录，然后点击启动。首次开启可能会要求实名认证，认证时问题不大，按流程来即可。

实际操作中，开启Pages之前先把代码提交并推送一次，保证仓库里已经有内容，否则Pages启动时找不到可发布文件，会报一个“没有可发布的文件”之类的提示。发布之后如果页面更新了，需要回到Pages设置里手动“更新”一次，Gitee目前不像GitHub Actions那样支持自动部署，但对静态个人站点来说，手动更新也算够用。

6. 高频报错自查手册：从fatal到登录失败再到TortoiseGit

6.1 fatal: not a git repository (or any of the parent directories): .git

这个报错极其常见，意思是“当前目录不是Git仓库”。原因一般有三种：

• 你还没有在项目目录执行过git init。解决办法：在项目根目录执行git init，然后再执行其他git操作。
• 你在子目录里执行git命令，但子目录不属于任何Git仓库。有些编辑器或终端会默认打开用户主目录，你在那里执行git status就会报这个错。解决办法：先用cd切到有.git目录的那个文件夹。
• .git目录被误删了。Git仓库的所有元数据都存放在项目根目录下的.git文件夹里，它丢了，本地历史就丢了（工作区文件还在）。如果远端Gitee上有完整代码，直接重新clone一份，再把本地改动的文件拷贝过去即可。

个人经验：每次打开终端第一件事就是cd到项目根目录，再执行Git命令。不要依赖终端启动时的默认路径，这是消灭这个报错最朴素的方法。

6.2 Login failed. check api token or gitlab version. log in via git

这个报错通常不是命令行里出现的，而是在PyCharm、IntelliJ IDEA等IDE的Gitee插件登录时出现的。文字里的gitlab version是因为Gitee的API兼容GitLab，所以很多IDE插件把Gitee当成GitLab来支持，版本检测失败了就会报这个错。

解决办法按顺序试：

1. 在IDE的插件设置里检查Gitee登录方式，优先使用“使用Token登录”，Token在Gitee网页端的“设置 -> 安全设置 -> 私人令牌”里生成，生成后粘贴进IDE。注意私人令牌只显示一次，生成后要立即复制保存。
2. 如果插件版本太旧，API不兼容，更新插件或IDE到最新版本。
3. 用SSH方式替代插件内置的HTTPS登录，IDE的Git功能最终调用的还是本地Git，不一定要用插件登录。

这个报错其实和Gitee本身无关，是IDE插件对Gitee API兼容性的问题。你不用在IDE里反复点登录，直接改用Token或者SSH方式反而更快。

6.3 Authentication failed / 用户名或密码错误

HTTPS方式推送时经常遇到，原因通常是：

• 用户名写错了，注意Gitee的用户名不是邮箱全称，而是个人主页URL上那个短标识。
• 密码错误，或者Gitee账号开启了两步验证，需要改用私人令牌作为密码。在HTTPS提示输入密码时，粘贴的是私人令牌字符串，不是账号密码。

我自己已经很少用HTTPS方式推代码了，就是因为“密码是对的但就是认证失败”这种问题在SSH下压根不存在。如果代码仓库已经用HTTPS关联了，可以换成SSH：

git remote set-url origin git@gitee.com:你用户名/仓库名.git

执行完再push，看看是否直接通过了。以后添加远程仓库时直接复制SSH地址，从一开始就走SSH。

6.4 Gitee创建Issue验证码错误

这个其实和Git关系不大。在Gitee网页端创建Issue时如果验证码提示错误，先检查是不是浏览器自动填写或缓存了过期验证码。换个浏览器、开无痕模式、清cookie，基本都能解决。这个问题不影响代码上传，但属于热搜高频词，提一嘴帮有同样困扰的人少走弯路。

6.5 其他“看起来无解”的怪现象

某个文件push总是失败且提示文件过大：Git的http.postBuffer设置有时会限制单次推送体积。可以临时调大：

git config --global http.postBuffer 524288000

还没有任何commit时不能push：Git仓库第一次push必须至少有一个commit，否则没有可推送的提交记录。先git commit -m "init"再push。

不小心把大文件推进历史里了，仓库体积巨大：这是历史遗留问题，最轻量的处理是借助git filter-repo工具重写历史，将指定大文件从所有历史提交中移除，然后强制推送。这属于手术级操作，操作前务必备份整个仓库目录，并确认所有协作者没有在本地的未推送修改。

实操中我最想提醒的三件事

写到最后，结合我个人的使用体会，列几句掏心窝的话。

**第一，不要背命令，要理解三个区域和一条推送链路。**Git命令再多，本质上就是“文件在工作区、暂存区、本地仓库、远程仓库之间搬移”。你把这条链路在脑子里画清楚，遇到问题就知道该查哪个环节：文件没进暂存区就查git add，提交没生成就查git commit，推送失败就查git remote和网络。

第二，提交信息别偷懒。“修复bug”“改代码”“update”这种信息等于没写。一个月之后回看历史，你根本想不起来那次提交到底改了什么。养成好习惯，一句话说清楚“做了什么、为什么”。我习惯用类似“修复用户登录时验证码过期的问题”“调整首页移动端布局，适配375px宽度”这样带具体场景的描述，后来回溯问题省了大力气。

**第三，SSH密钥和.gitignore值得一次性配置到位。**很多人的Git体验不好，不是因为Git难，而是因为基础配置太将就。密钥没配，每次输密码；敏感文件没忽略，推送前还要提心吊胆；多平台身份冲突，提交记录乱七八糟。花十几分钟把这些一次性做对，后面几年都顺。

Gitee的定位是国内开发者最顺手也最可靠的代码托管入口，上传代码只是第一步，真正用好Git的分支、合并、回滚、协作能力，才算是把这套工具的价值榨干。从今天开始，建一个仓库，把你手头还没管理的项目推上去，跑通一次完整的“修改 -> 提交 -> 推送”循环，所有概念都会在这一遍实操里串起来。