我第一次真正上手用Git往GitCode上传代码时，心里想的是：这不就是把文件拖到网页里的事吗？结果一打开终端就懵了，git init、git add、git commit、git push，每个单词单独看都认识，连在一起就不知道先敲哪个。更折腾的是，好不容易把命令敲完，又碰上一个SSH认证失败，硬是卡了我大半个晚上。后来回头看，问题不在于Git有多难，而在于当时的教程只让我“照着敲”，从没解释过每一步到底在干什么。

这篇文章我想用最简单的方式，把“用Git上传代码到GitCode”这件事从头到尾拆开讲给你听。内容覆盖Git下载安装、本地仓库初始化、关联GitCode远程仓库、SSH密钥配置、完整push流程、分支合并，以及几个高频报错的排查思路。凡是第一次接触Git的新手，或者已经在用了但还没真正理顺流程的人，读完应该都能自己跑通“本地修改 -> 提交 -> 推送到GitCode”的完整链路。

1. Git和GitCode分别解决什么问题

1.1 版本控制就是给代码做存档

很多人不理解，代码为什么要用一套专门的工具来管理。你可以把版本控制想象成游戏存档：你打到一个重要关卡前，先存个档，手滑操作失误了、BOSS打不过去了，随时可以从上一个存档点重新来。代码开发也一样，你今天改了一版功能，明天发现改坏了，总不能靠人工复制粘贴来恢复。

Git就是目前最流行的版本控制工具。它能在你的项目目录里记录每一次“存档”，这个存档在Git里叫一次提交（commit）。每次提交都保存了当前所有文件的快照、提交人、提交时间和说明文字，你想回到哪一次都能回去。更强大的是，Git支持多人同时开发，每个人在自己的分支上改动，最后合并到一起，互不干扰。

1.2 Git负责本地，GitCode负责云端

这里有一个新手最容易混淆的点：Git和GitCode不是同一个东西。

Git是你电脑上安装的命令行工具，它管的是你本地项目文件的历史版本，所有操作都在你的机器上完成。而GitCode是一个代码托管平台，用来存放你的远程仓库。你可以把它理解成一个云端保险柜，你的代码通过Git推送到上面，其他人也能从上面拉取代码。Git负责“怎么管版本”，GitCode负责“把版本存到哪里”。

两者配合起来，才是完整的开发流程：你在本地用Git提交代码，然后把提交记录和文件一起推送到GitCode，需要时再从GitCode拉取到另一台电脑上。

1.3 这套组合的日常使用场景

最简单的场景，就是你单独开发一个项目，需要在多台电脑之间同步代码，或者想把代码备份到云端。你在公司电脑上改了一部分，回家以后继续改，只要有Git和GitCode，两边一推一拉就能无缝衔接。

更常见的场景是团队协作。你负责模块A，同事负责模块B，两个人各自在分支上开发，互不影响。做完之后把分支推送到GitCode，再发起合并请求，由项目维护者审查代码后合并进主分支。GitCode承担的正是这个“多人协作的中转站”角色。

2. 环境准备：从下载安装到用户配置

2.1 在Windows上安装Git的完整步骤

如果你是Windows用户，直接去Git官网下载对应系统的安装包就行，下载下来的是一个exe文件。安装过程基本可以一路“Next”，大部分选项用默认值就好。需要注意两个地方：一是安装过程中会让你选编辑器，默认的Vim对新手不友好，建议选Notepad或者VS Code；二是在安装结束前，确保勾选了“Git Bash Here”这个右键菜单选项，之后在任意文件夹里点右键就能直接打开Git的终端，非常方便。

安装完成后，桌面或者开始菜单会出现Git Bash，打开它，输入下面的命令检查版本：

git --version

如果能输出类似git version 2.x.x.windows.x这样的信息，说明安装成功。Mac和Linux用户也可以用包管理器安装，Mac上用brew install git，Ubuntu上用apt install git，这里就不再展开。

2.2 首次使用前必须完成的两行配置

Git在你每次提交代码时，都会把提交人的名字和邮箱记录到历史里。如果不提前配置，Git就会报错或者提示你补上。这两行配置是最基本、也是最重要的：

git config --global user.name "你的名字" git config --global user.email "你的邮箱"

注意，这个邮箱建议和你注册GitCode用的邮箱保持一致，这样提交记录才能和你GitCode账号关联起来。另外，user.name不一定要真名，可以是用户名或昵称，但建议固定下来不要再改，否则历史提交里会出现多个身份。

配置完之后，可以用下面的命令确认：

git config --global --list

只要能看到user.name和user.email两行，说明配置生效了。

2.3 顺手做掉的额外设置

还有两个设置我建议新手提前做好。一个是把默认分支名改成main，避免本地用master、远程用main导致的混乱：

git config --global init.defaultBranch main

另一个是Windows换行符处理。Windows和Linux系统的换行符不一样，为了团队协作时不出现“整个文件都被判定为改动”的情况，建议Windows用户设置：

git config --global core.autocrlf true

这条配置的意思是：提交时把Windows换行符转成Linux风格，拉取时再转回来，减少换行符带来的噪音。

3. 在本地把一个项目变成Git仓库

3.1 git init之后发生了什么

假设你有一个项目文件夹，里面放着代码，现在要开始用Git管理它。第一步是进入这个文件夹，打开Git Bash，执行：

cd D:/我的项目 git init

执行后Git会在当前文件夹里创建一个名为.git的隐藏目录。这个目录就是Git的“数据库”，你的所有提交记录、分支信息、历史版本都存在这里。你可以进去看一眼，但正常情况下不要手动修改里面的任何文件。

从这一刻开始，你的项目就成了一个Git仓库。如果你执行一下git status，Git会告诉你当前处于哪个分支，以及哪些文件还没有被跟踪。

3.2 add和commit的工作逻辑

项目变成仓库之后，下一步就是提交代码。很多新手会在这里卡住：为什么不能直接一个命令提交，非要先git add再git commit？

原因是Git把提交过程分成了两步，它们之间隔了一个“暂存区”。你可以这样理解：git add是把你想保存的东西放进购物车，git commit才是真正结账付款生成小票。购物车的好处是你可以自由挑选，比如你同时改了三个文件，但只想提交其中两个，那就只把这两个文件add进暂存区，然后commit。

实际操作如下：

git add index.html git add style.css git add . git commit -m "完成首页样式"

第一条和第二条分别添加特定文件，第三条git add .表示把当前目录所有改动都添加进暂存区。我建议你刚开始用的时候多打几条明确的git add，而不是一上来就无脑用git add .，这样你更清楚自己提交了什么。

commit的-m参数是提交说明，这行文字会永久记录在历史里。说明要写清楚这次改了什么东西，比如“修复登录按钮点击无效”就比“update”有价值得多。提交之后再看git status，工作区就干净了；用git log能看到提交记录。

3.3 用.gitignore过滤无用文件

你迟早会遇到一个问题：项目里有些东西根本不需要提交，比如Python的__pycache__目录、Java的target目录、前端的node_modules文件夹、IDE的.idea和.vscode配置、日志文件等等。这些文件要么是自动生成的，要么是个人环境差异导致的，推送到远程仓库只会制造混乱。

解决办法是在项目根目录创建一个名为.gitignore的文件，把要忽略的内容写进去：

node_modules/ target/ .idea/ .vscode/ *.log .DS_Store

每行一条匹配规则，支持通配符。创建好之后，再执行git status就不会看到这些文件了。这个文件本身要提交到Git，这样团队里所有人的忽略规则就统一了。

4. 在GitCode上建立远程仓库并关联本地

4.1 新建远程仓库时的关键选项

本地仓库建好后，还需要一个远程仓库来存放代码。登录GitCode官网，注册并登录账号后，进入创建仓库页面。这里需要填几个信息：

• 仓库名称：推荐用小写英文字母和连字符，例如my-first-project，不要用中文和空格。
• 仓库描述：可选，简单写一下项目是做什么的。
• 可见性：私有仓库只有你和被邀请的人能看，公开仓库所有人都能看到，自己学习练习刚开始用私有就好。
• 初始化选项：建议先不勾选自动生成README、.gitignore等文件。如果勾选了，本地和远程仓库就会有两套互不相干的历史，第一次推送时反而要被拒绝。后面我会专门讲这个坑。

创建完成之后，GitCode会展示一个仓库主页，上面有远程仓库的HTTPS地址和SSH地址。这两个地址就是本地仓库和远程仓库之间的“门牌号”。

4.2 用git remote关联远程地址

回到本地项目目录，执行下面的命令，把远程地址和本地仓库关联起来：

git remote add origin https://gitcode.com/你的用户名/仓库名.git

这条命令里的origin是远程仓库的别名，你也可以叫别的名字，但origin是全世界的Git用户约定俗成的叫法。添加之后，可以用下面命令查看是否关联成功：

git remote -v

看到origin对应两行地址（fetch和push），说明关联完成。

如果中途填错了地址，可以用git remote remove origin删掉重新添加，不改远程地址也可以直接编辑本地配置，但对新手来说remove再add是最直观的。

4.3 HTTPS和SSH怎么选

GitCode支持两种远程连接方式：HTTPS和SSH。新手容易在两者之间纠结，我这里直接给结论：

用HTTPS第一次推送时，如果提示密码错误，通常是因为平台要求使用“访问令牌（Personal Access Token）”而不是登录密码。你需要到GitCode的设置或安全设置里生成一个个人访问令牌，复制下来，在Git提示输入密码时粘贴进去。这个令牌相当于有特定权限的临时密码，使用之后要保存好。

但如果你已经决定长期使用GitCode，我更推荐直接上SSH，省得每次都要处理密码问题。接下来的第5节就是完整的SSH配置流程。

5. SSH密钥配置：从此告别账号密码

5.1 为什么SSH值得花这个时间

SSH是一种安全连接协议，它靠一对密钥来验证身份：一把私钥存放在你电脑本地，另一把公钥配置到GitCode账号上。推送代码时，Git会用你的私钥签名，服务器用你留下的公钥验签，两边对上就放行。整个过程不需要输入账号密码。

你只需要花一次时间生成密钥、上传公钥，之后无论push、pull还是fetch，都是全免密状态。而且在多台电脑之间切换也方便，每台电脑生成各自的密钥，分别加到GitCode账号里就行。

5.2 一步步生成SSH密钥

在Git Bash里依次执行下面的命令。先检查一下是否已经有密钥：

ls ~/.ssh/id_ed25519.pub

如果提示文件不存在，说明你还没有密钥，需要先生成。推荐用Ed25519算法，比传统RSA更安全且生成更快：

ssh-keygen -t ed25519 -C "你的邮箱"

执行之后会提示你选择保存路径，直接回车用默认路径就行。接下来会提示输入passphrase（口令短语），这一步可以留空，直接按两次回车。但如果你是在公司电脑上使用，我建议设置一个口令，这样即使别人拿到你的私钥文件，也无法直接用。

生成成功后，执行：

cat ~/.ssh/id_ed25519.pub

屏幕上会输出一串以ssh-ed25519开头的长文本，这就是你的公钥。从开头一直复制到结尾，注意不要多复制空格和换行。

5.3 把公钥加进GitCode并验证连通性

登录GitCode，进入个人设置，找到“SSH公钥”或类似入口（通常在安全设置里）。把你复制的公钥粘贴进去，起个标题，比如“工作电脑”或“家用台式机”，然后保存。

接下来验证是否配置成功。在终端执行：

ssh -T git@gitcode.com

这里的域名要以GitCode官方文档为准。首次执行时，SSH会提示确认主机的指纹，输入yes回车即可。如果看到类似“Hi 用户名! You've successfully authenticated”的信息，说明SSH密钥已经生效。

同时，记得把远程仓库地址从HTTPS换成SSH格式：

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

之后再push和pull就完全不用输入密码了。

6. 手把手跑完一次完整上传

6.1 从空项目到首次push的完整命令

现在一切就绪，我们从头到尾走一遍上传流程。假设你有一个项目文件夹，里面已经有代码了，且没有初始化过仓库。完整的命令序列如下：

cd D:/我的项目 git init git add . git commit -m "first commit" git remote add origin git@gitcode.com:你的用户名/仓库名.git git branch -M main git push -u origin main

逐条解释一下。git init创建本地仓库，git add .把所有文件加入暂存区，git commit生成第一个提交记录。git remote add关联远程地址。git branch -M main把当前分支名强制改成main，这是为了和GitCode新建仓库的默认分支保持一致。最后一条git push -u origin main是推送命令，其中的-u参数表示把本地main分支和远程main分支关联起来，以后你直接执行git push就可以，不需要再带参数。

第一次push成功后，终端会显示一些统计信息，比如写入了多少对象、实际推送了多少文件。这时候去GitCode仓库页面刷新一下，就能看到你的代码了。

6.2 分支操作：创建、切换、合并

只要你不在一个分支上完成所有工作，就一定会用到分支。分支的本质是“平行世界”，你在一个分支上开发新功能，不管改得多乱，都不会影响主分支上稳定运行的代码。

常用分支操作如下：

git branch dev # 创建dev分支 git checkout dev # 切换到dev分支 git checkout -b feature/login # 创建并切换到新分支 git branch # 查看本地分支 git branch -a # 查看所有分支（含远程分支）

在dev分支上改完代码并提交后，想把它合并回main分支，需要先切回main，再执行合并：

git checkout main git merge dev

合并的结果是把dev分支的提交记录整体加入到main分支中。如果两个分支同时改过同一个文件的同一处内容，可能会产生冲突。冲突时Git会在文件里标记出冲突区域，你需要手动确认保留哪边内容，然后git add、git commit完成合并。

6.3 多人协作时的拉取与推送节奏

如果是多人协作，节奏通常是：先拉取最新代码，再提交自己的改动，最后推送。刚上手的人最容易犯的错误是一上来就git push，结果被告知推送被拒绝。原因很简单：远程仓库上已经有了你本地没有的新提交，Git担心你把别人的历史覆盖掉。

正确的习惯是每次开始工作前先拉取：

git pull origin main

这条命令相当于把自己本地的main分支更新到和远程一致。之后你在本地修改、提交、推送，就会顺畅很多。如果你已经写完了代码才发现远程有新提交，也可以先git pull再git push，Git会自动处理合并，除非真有冲突需要手动解决。

另外要区分两个概念：git pull是“下载远程提交并合并到当前分支”，git fetch只是“下载远程提交但不合并”。大多数时候你只需要git pull就够了。

7. 必读：高频报错排查方案

7.1 SSH认证失败（Permission denied）

这是新手碰到最多的错误，提示通常是Permission denied (publickey)。出现这个错误，说明你的SSH密钥没有通过服务器验证。按顺序排查下面的可能性：

1. 有没有生成过密钥：执行ls ~/.ssh/，看看是不是空目录。
2. 公钥是不是完整地添加到了GitCode：粘贴公钥时容易漏掉末尾的邮箱标识，虽然不影响验证，但尽量整行复制。
3. 远程仓库地址用的是不是SSH格式：如果之前用的是HTTPS，就算SSH配置好了，Git也压根不会走SSH流程。
4. 当前终端是否加载了正确的私钥：大多数情况下ssh-keygen生成的默认私钥会自动生效，不用额外配置。

排查完这些，再执行一次ssh -T git@gitcode.com，看是否能正常验证。

7.2 推送被拒绝（non-fast-forward）

错误信息里会看到! [rejected]和non-fast-forward。这个问题的核心就是远程仓库有本地没有的提交，通常发生在你在GitCode网页端或另一台电脑上提交过代码。

解决办法是把远程的新提交拉下来合并，再推送：

git pull origin main git push origin main

如果你的本地仓库和远程仓库没有任何共同历史，比如你创建仓库时勾选了自动生成README，而本地也做了一次commit，拉取时会提示合并不相关历史。这时需要加一个参数强制允许合并：

git pull origin main --allow-unrelated-histories

首次合并后两边就有了公共历史，以后再推送就恢复正常了。

7.3 其他高频错误与处理

我把自己这些年在Git和GitCode使用中遇到的小问题整理了一下，方便你对照：

还有一个很多新手忽略的点：push前先养成git status的习惯，用git diff看一下具体改了什么，再决定要不要提交。这能帮你避免把调试日志、临时文件、甚至是数据库密码提交到远程仓库这种事故。

带过几个新人之后，我发现真正难住他们的往往不是命令本身，而是不理解“本地仓库和远程仓库是两套独立的仓库”这件事。文件上传到GitCode页面并不算完成，只有本地提交、推送、远程同步这三步都走通，整套流程才算闭环。我自己现在每次开始动手写代码前，都会先想清楚一个问题：“这次改动最终要以什么形式出现在远程仓库里”，想清楚之后再动手，就不会在命令和分支里迷失方向。

最后分享一个小技巧：如果你经常要手动敲git add、git commit、git push这几条固定动作，可以组合成一条别名快速键，在Git Bash里执行：

git config --global alias.pushd "commit -a -m"

以后想快速提交全部改动就输入git pushd "提交说明"，会减少一点重复劳动。等你真正跑通一次完整流程，再去看Git的分支、合并、回滚这些高级功能，会发现它们都建立在今天这些基础操作之上，并没有想象中那么难。