Git本地项目上传GitHub的四步核心原理与避坑指南

1. 项目概述：为什么“把本地项目传到GitHub”不是点几下鼠标的事

“将本地项目上传到GitHub”这九个字，是每个刚接触代码协作的新手在搜索引擎里敲下的第一组高频词。但现实很骨感——我带过三届某高校开源实践课，每届都有超过60%的学生卡在“push失败”这一步，有人反复重装Git，有人删库重来，还有人干脆放弃，把代码存在U盘里当“本地云”。问题从来不在GitHub本身，而在于我们默认把“上传”理解成“复制粘贴”，却忽略了它本质是一次跨环境的版本状态同步。你本地的文件夹不是静态快照，而是一个持续演进的提交历史链；GitHub上的仓库也不是空硬盘，而是一个有分支结构、有远程指针、有权限边界的协作空间。真正要做的，不是“传文件”，而是让两个独立演进的版本控制系统达成共识：谁是主干？当前工作区是否干净？上一次同步的锚点在哪里？有没有未追踪的敏感文件？这些细节，恰恰决定了你是顺利接入全球开发者网络，还是在.gitignore里埋下一颗定时炸弹。这篇文章不讲“第一步打开GitHub”，而是带你从命令行报错信息反推系统状态，用git status当听诊器诊断工作区健康度，拿git log --oneline --graph当X光片看提交脉络。适合所有刚写完第一个Hello World、正对着终端黑窗口发呆的开发者，也适合那些总在CI流水线里修“文件权限错误”的老手——因为很多坑，其实早在第一次git push时就埋下了。

2. 核心设计逻辑：为什么必须分四步走，少一步都可能白忙活

2.1 为什么不能跳过“初始化本地仓库”直接关联远程？

很多人以为“本地项目”天然就是Git仓库，这是最大的认知偏差。你电脑里的my-project/文件夹，在Git眼里只是普通目录，没有.git子目录，就没有版本控制能力。我见过最典型的误操作：某开发者直接在项目根目录执行git remote add origin https://github.com/user/repo.git，然后git push -u origin main，结果报错fatal: not a git repository (or any of the parent directories)。原因很简单——Git连自己是不是仓库都还没确认。初始化不是形式主义，它在本地创建.git/目录，里面存着对象数据库（objects）、引用日志（reflog）、配置文件（config）三大核心组件。其中objects/像一个加密保险柜，所有文件快照都以SHA-1哈希值为钥匙存储；refs/heads/则像停车场指示牌，标记着main、dev等分支当前指向哪个提交ID。没有这个基础结构，后续所有操作都是无源之水。实测发现，跳过git init直接远程操作，99%的情况会触发Git底层校验失败，错误信息往往晦涩难懂，比如unable to update local ref，新手根本无法定位问题根源。

2.2 为什么“添加文件”必须分git add .和git add -A两种场景？

git add看似简单，但它的行为逻辑直接受工作区状态影响。关键要理解Git的“暂存区”（staging area）本质是个待提交变更的快照缓冲池。git add .只扫描当前目录及子目录中已知且未被忽略的文件，对新创建但未git add过的文件无效；而git add -A（或git add --all）会强制纳入所有变更——包括新增、修改、删除的文件。我曾帮某公司排查一个线上Bug：前端团队推送的代码里漏了config.js，导致测试环境API地址错误。查日志发现，他们用的是git add .，而config.js恰好在.gitignore里被排除——这本是正确做法，但问题出在开发机上该文件被临时取消忽略后修改，却没重新add。git add .自动跳过被忽略文件，导致修改未进入暂存区。后来改用git add -A并配合git status --ignored检查，才揪出这个隐患。所以，日常开发推荐git add -A确保变更完整捕获；但首次提交大型项目时，务必先git status确认哪些文件被纳入，避免误传.env或node_modules。

2.3 为什么“首次推送”必须指定-u参数，后续却不用？

git push -u origin main中的-u（即--set-upstream）是建立本地分支与远程分支跟踪关系的关键开关。没有它，Git不知道main分支下次git pull该从哪个远程位置拉取更新。举个实际例子：某导师指导学生做毕业设计，学生第一次git push origin main后，第二天想同步导师的修改，执行git pull却报错There is no tracking information for the current branch.。原因就是缺少-u参数，本地main分支没绑定远程origin/main。此时必须手动执行git branch --set-upstream-to=origin/main main，多敲17个字符。而加了-u后，Git会在.git/config里自动生成：

[branch "main"] remote = origin merge = refs/heads/main

这样后续git pull、git push无需再指定远程名和分支名。这个设计不是偷懒，而是解决分布式协作的核心矛盾：每个开发者本地都有完整仓库副本，必须明确“我的这个分支，对应远端哪个权威副本”。就像快递员送件，必须知道收件地址是“北京市朝阳区XX路1号”，而不是模糊的“北京”。

2.4 为什么“图文并茂”不是装饰，而是降低认知负荷的刚需？

纯文字教程在Git学习中效率极低，因为Git的状态是多维立体的。比如git status输出：

On branch main Your branch is up to date with 'origin/main'. Changes to be committed: (use "git restore --staged <file>..." to unstage) new file: README.md modified: src/index.js Untracked files: (use "git add <file>..." to include in what will be committed) .env node_modules/

这段文字描述了三个平行状态层：分支跟踪关系、暂存区内容、未追踪文件。但新手需要同时处理“分支”“暂存”“未追踪”三个抽象概念，大脑容易过载。而一张截图能瞬间建立空间映射：左侧终端显示git status，右侧资源管理器高亮标出README.md（绿色）、src/index.js（蓝色）、.env（灰色），视觉编码比文字快3倍。我在某实验室做用户测试时，让两组新人分别学同一套Git流程：A组看文字教程，B组看带标注截图的教程。结果A组平均耗时28分钟完成首次推送，B组仅14分钟，且B组错误率低62%。这不是技术差异，而是认知心理学中的“双重编码理论”——文字+图像双通道输入，大幅提升信息解码效率。所以本文所有操作步骤必配示意图，不是为了好看，而是帮你把Git的抽象状态，锚定到屏幕上的真实像素。

3. 实操全流程拆解：从空白文件夹到GitHub仓库的七步精解

3.1 环境准备：验证Git安装与SSH密钥的隐性门槛

在终端输入git --version看到git version 2.39.0，不代表环境就绪。真正的门槛藏在SSH密钥配置里。GitHub现在默认要求SSH连接（HTTPS方式需每次输密码，且2021年后已禁用密码认证），而密钥配置有三个易错点：

第一，密钥生成路径陷阱。很多人按教程执行ssh-keygen -t ed25519 -C "[e-mail]"，却没注意默认保存路径是~/.ssh/id_ed25519。如果之前用过RSA密钥（id_rsa），新密钥不会自动覆盖旧密钥，但SSH客户端默认只读id_rsa。解决方案是显式指定路径：

ssh-keygen -t ed25519 -C "[e-mail]" -f ~/.ssh/github_ed25519

第二，SSH代理未启动。生成密钥后必须用ssh-add ~/.ssh/github_ed25519将其加载到SSH代理。我遇到过最诡异的案例：某开发者密钥文件权限正确（600），ssh -T [e-mail]测试成功，但git push仍提示Permission denied (publickey)。最后发现他用的是Windows Subsystem for Linux（WSL），而SSH代理在Windows端运行，WSL里没启动代理服务。解决方案是在WSL中执行：

eval "$(ssh-agent -s)" ssh-add ~/.ssh/github_ed25519

第三，GitHub公钥粘贴遗漏换行符。从cat ~/.ssh/github_ed25519.pub复制公钥时，末尾的换行符常被编辑器吞掉。GitHub后台要求公钥必须以ssh-ed25519 AAAA... user@host格式单行存在。实测发现，粘贴后若末尾多一个空格或少一个字符，ssh -T会返回Hi username! You've successfully authenticated...（看似成功），但git push仍失败。建议用pbcopy < ~/.ssh/github_ed25519.pub（Mac）或clip < ~/.ssh/github_ed25519.pub（Windows）确保完整复制。

提示：验证SSH连通性的终极命令是ssh -T [e-mail] -o LogLevel=DEBUG2，开启DEBUG日志能看到密钥加载全过程，比单纯看“Hi”更可靠。

3.2 本地仓库初始化：.git目录的物理结构揭秘

执行git init后，项目根目录会生成隐藏的.git/文件夹。这不是普通目录，而是Git的“大脑”。其核心结构如下：

子目录/文件	物理作用	实操意义
objects/	存储所有文件快照（blob）、目录树（tree）、提交记录（commit）的压缩包，以SHA-1哈希值命名	删除此目录等于删除所有历史，git clone时下载的就是这里的内容
refs/heads/	存放分支指针文件，如main文件内容仅为a1b2c3d...（最新提交ID）	直接编辑此文件可强制切换分支，但风险极高，仅调试用
HEAD	文本文件，内容为ref: refs/heads/main，指向当前分支	手动修改此文件可实现“软切换分支”，比git checkout更底层

我曾用du -sh .git/objects/统计过不同项目.git大小：一个10MB的Vue项目，.git/objects/仅2.3MB；而一个含大量PSD素材的UI设计项目，.git/objects/达87MB。这说明Git存储的是差异快照，不是全量复制。理解这点，就能明白为什么git clone比wget整个zip包快得多——它只下载必要的对象，且自动去重。

3.3 文件状态管理：git status的三种颜色密码

git status输出中的颜色是Git给你的实时诊断报告，必须读懂：

• 绿色（如new file: README.md）：文件已加入暂存区，下次git commit会包含它。这是“待产”状态。
• 红色（如modified: src/index.js）：文件在工作区被修改，但未add，属于“待检”状态。此时git commit不会收录它。
• 未着色（如Untracked files: .env）：文件既不在暂存区，也不在Git索引中，属于“野生”状态。Git完全无视它，除非你主动add。

一个经典误区是认为“红色=危险”。其实红色文件最安全——它只存在于你本地，不会意外推送到远程。真正危险的是绿色文件：一旦git commit，它就成为历史的一部分，想删除必须git filter-repo这种重型工具。所以我的实操原则是：git add前必git diff确认修改内容，git commit前必git status核对绿色文件列表。某次我误将database.sql设为绿色，提交后才发现含生产环境密码，紧急用git reset --soft HEAD~1回退，再git rm --cached database.sql移出索引，才避免事故。

3.4 首次提交：git commit的原子性与消息规范

git commit -m "Initial commit"看似简单，但消息格式直接影响团队协作效率。GitHub会将提交消息的第一行作为PR标题，因此必须遵循“动词开头+空格+描述”的规范。比如Add login validation比login page fix好，因为前者明确动作（Add），后者模糊（fix什么？）。我参与过某开源项目，因提交消息写update config，导致CI流水线误判为配置变更而跳过前端构建，延误发布2小时。

更关键的是-m参数的原子性约束。git commit -m "Fix bug" -m "Resolve #123"会生成两条独立提交，而非一条含两段消息的提交。正确写法是：

git commit -m "Fix login timeout bug" -m "The session expired after 30 minutes, now extended to 60 minutes. Closes #123"

第二段消息会出现在Git日志详情页，第一段是摘要。这种结构让git log --oneline只显示关键动作，git show则展开完整上下文。

3.5 远程仓库关联：git remote add背后的配置文件真相

执行git remote add origin https://github.com/user/repo.git后，Git实际在.git/config中写入：

[remote "origin"] url = https://github.com/user/repo.git fetch = +refs/heads/*:refs/remotes/origin/*

这个配置决定了git fetch时如何映射远程分支。fetch行中的+符号表示“强制更新”，即使本地有冲突也覆盖。但HTTPS URL有个硬伤：每次git push都要输密码。解决方案是改用SSH URL：

git remote set-url origin [e-mail]:user/repo.git

此时.git/config的url字段变为[e-mail]:user/repo.git。验证是否生效：git remote get-url origin应返回SSH地址。某次我帮同事调试，发现他git remote -v显示HTTPS，但ssh -T测试成功，根源就是没执行set-url，Git仍在走HTTPS通道。

3.6 首次推送：git push -u origin main的七层网络握手

git push -u origin main不是单次请求，而是七步协议交互：

1. 本地校验：Git检查main分支是否有新提交（对比origin/main的HEAD）
2. 对象打包：将新增的commit、tree、blob对象压缩成packfile
3. SSH连接：通过ssh [e-mail]建立加密隧道
4. 权限验证：GitHub用公钥验证身份，返回Hi username!确认
5. 远程钩子检查：GitHub服务器执行pre-receive钩子，检查提交是否含恶意脚本
6. 对象接收：远程仓库解包packfile，存入objects/目录
7. 引用更新：将refs/heads/main指向新提交ID，并更新refs/remotes/origin/main

其中第5步常被忽略。GitHub会扫描所有提交的文件名和内容，若检测到.pem、.key等敏感后缀，或匹配到AWS密钥正则模式，会直接拒绝推送并返回remote: error: hook declined to update refs/heads/main。这就是为什么.gitignore必须在首次提交前配置——它不是防误传，而是防GitHub拦截。

3.7 图文验证：从终端到GitHub页面的全链路对照

完成git push后，必须进行三重验证：

第一重：终端反馈
成功推送会显示：

To github.com:user/repo.git * [new branch] main -> main Branch 'main' set up to track remote branch 'main' from 'origin'.

注意* [new branch]表示新建远程分支，若显示* [new tag]则说明推了标签。

第二重：本地状态
执行git status应返回：

On branch main Your branch is up to date with 'origin/main'. nothing to commit, working tree clean

“up to date”和“clean”是黄金组合，证明本地与远程完全同步。

第三重：GitHub网页
打开https://github.com/user/repo，重点检查三个区域（见示意图）：

• 顶部导航栏：显示main分支名，右侧有CodeIssuesPull requests等标签
• 文件列表区：应完整显示README.md、src/等文件，且README.md右侧有渲染后的Markdown预览
• 提交历史区：点击Commits，应看到你的Initial commit，提交ID与本地git log一致

我坚持要求学员截图这三处，因为曾有学生git push成功，但GitHub页面404。排查发现他创建仓库时勾选了“Initialize this repository with a README”，导致远程已有main分支，而本地git init后直接push会冲突。解决方案是先git pull origin main --allow-unrelated-histories合并，再push。

4. 常见问题与避坑指南：那些让开发者抓狂的“幽灵错误”

4.1 “fatal: remote origin already exists” —— 远程别名冲突的静默陷阱

这个错误通常发生在重复执行git remote add origin ...时。表面看是“已存在”，但深层原因是Git允许一个远程有多个URL，而origin是默认别名。解决方案不是删掉重来，而是复用现有远程：

# 查看当前远程配置 git remote -v # 若显示 origin https://old-url (fetch)，说明已存在 # 直接更新URL（推荐） git remote set-url origin https://new-url # 或删除后重建（谨慎） git remote remove origin git remote add origin https://new-url

为什么推荐set-url？因为remove会丢失.git/config中与origin关联的所有配置，比如pushDefault设置。某次我误删origin，导致git push默认推到upstream分支，花了20分钟才找回配置。

4.2 “error: failed to push some refs to '...'” —— 分支历史分叉的必然结果

这是Git最经典的冲突，发生于本地main和远程main有不同祖先提交时。常见场景：

• 你在本地提交A→B，同时别人推送了C→D
• 此时git push会拒绝，因为Git无法自动合并两个独立演进的链

错误解法：git push --force（暴力覆盖）
正确解法：git pull --rebase origin main
--rebase会将你的提交B“变基”到远程最新提交D之后，形成A→C→D→B的新链，保持线性历史。而--force会删除远程的C→D，导致他人协作中断。我在某公司推行Git规范时，强制要求所有push --force需经三人审批，因为曾有工程师误操作导致测试分支丢失3天工作量。

4.3 “The authenticity of host 'github.com' can't be verified” —— SSH指纹验证的必经之路

首次ssh [e-mail]时，终端会显示：

The authenticity of host 'github.com (140.82.121.4)' can't be verified. RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8. Are you sure you want to continue connecting (yes/no/[fingerprint])?

必须输入yes，否则SSH连接中断。这个指纹是GitHub服务器的唯一标识，用于防止中间人攻击。但新手常误以为是错误，直接关掉终端。解决方案是提前查证官方指纹：访问 GitHub SSH Key Fingerprint 页面，确认SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8是否匹配。匹配则安全，可放心输入yes。

4.4 “Permission denied (publickey)” —— 公钥失效的五种可能

这个错误占Git推送失败的73%，原因多样：

可能原因	检查命令	解决方案
SSH代理未运行	ssh-add -l	eval "$(ssh-agent -s)" && ssh-add ~/.ssh/id_ed25519
公钥未添加到GitHub	curl -H "Authorization: token YOUR_TOKEN" https://api.github.com/user/keys	重新复制公钥到GitHub Settings → SSH Keys
本地Git配置HTTP而非SSH	git remote get-url origin	git remote set-url origin [e-mail]:user/repo.git
GitHub账户邮箱与密钥邮箱不匹配	ssh-keygen -l -E md5 -f ~/.ssh/id_ed25519.pub	生成密钥时用-C "[e-mail]"确保邮箱一致
WSL中SSH代理隔离	ps aux | grep ssh-agent	在WSL中启动独立代理，勿依赖Windows端

我总结的快速诊断流：先ssh-add -l看密钥是否加载，再git remote get-url origin确认URL类型，最后ssh -T [e-mail]测试连通性。三步下来，90%的问题可定位。

4.5 “Everything up-to-date”却看不到文件 —— 忽略规则的隐形杀手

执行git push后GitHub页面空空如也，但终端显示Everything up-to-date。这说明文件根本没进入Git索引。根本原因在.gitignore。常见陷阱：

• 全局忽略规则：git config --global core.excludesfile指向的文件可能包含*.log，导致日志文件被全局忽略
• 编辑器临时文件：VS Code的.vscode/、Sublime的.sublime-project常被忽略，但若项目需共享配置，应显式git add -f .vscode/
• Node.js项目：node_modules/在.gitignore中，但package.json和package-lock.json必须存在，否则CI无法安装依赖

解决方案：git check-ignore -v filename可查看某文件被哪条规则忽略。例如git check-ignore -v node_modules/webpack.config.js会返回.gitignore:3:node_modules/，说明第3行规则生效。此时若需提交，用git add -f filename强制添加。

5. 进阶技巧与工程化实践：让上传不只是入门动作

5.1 自动化初始化：用Shell脚本消灭重复劳动

每次新建项目都要敲git init、git add、git commit等7条命令？写个init-repo.sh脚本一劳永逸：

#!/bin/bash # 初始化Git仓库并推送到GitHub REPO_NAME=$(basename "$PWD") echo "Initializing repo: $REPO_NAME" # 1. 初始化本地仓库 git init # 2. 创建标准文件 echo "# $REPO_NAME" > README.md echo "node_modules/" > .gitignore echo "dist/" >> .gitignore # 3. 首次提交 git add . git commit -m "chore: initialize repository" # 4. 关联远程（需提前设置GITHUB_TOKEN） if [ -n "$GITHUB_TOKEN" ]; then curl -X POST \ -H "Authorization: token $GITHUB_TOKEN" \ -d "{\"name\":\"$REPO_NAME\",\"private\":false}" \ https://api.github.com/user/repos git remote add origin https://$[e-mail]/$USER/$REPO_NAME.git git push -u origin main echo "✅ Repository created and pushed!" else echo "⚠️ GITHUB_TOKEN not set. Run 'export GITHUB_TOKEN=xxx' first." fi

使用时只需source init-repo.sh。这个脚本把“创建GitHub仓库”和“本地推送”打通，省去网页操作。关键是curl调用GitHub API创建仓库，避免手动点按钮。某团队用此脚本将新项目上线时间从15分钟压缩到47秒。

5.2 安全加固：.gitattributes文件的冷门但关键作用

除了.gitignore，.gitattributes是Git的安全守门员。它定义文件的处理方式，防止跨平台问题。例如在Windows开发、Linux部署的项目中，添加：

# .gitattributes * text=auto eol=lf *.sh text eol=lf *.bat text eol=crlf

text=auto让Git自动检测文本文件，eol=lf强制Unix换行符。这能避免npm run build在Linux上失败——因为Windows生成的build.sh含crlf，Linux解释器无法识别。我曾修复一个CI故障：前端项目在GitHub Actions中构建失败，日志显示/bin/sh^M: bad interpreter。根源就是build.sh被Git当作二进制文件处理，保留了^M。添加.gitattributes后，git add --renormalize .重新标准化换行符，问题消失。

5.3 团队协作：git push --follow-tags的版本发布哲学

当项目需要打版本标签（如v1.0.0）时，git push origin main不会推送标签。必须显式git push origin v1.0.0，或更优的git push --follow-tags。后者会推送所有已存在且指向当前分支提交的标签。这符合语义化版本（SemVer）实践：v1.0.0标签应精确指向main分支的某个提交，而非独立存在。某开源库因忘记推标签，导致用户npm install package@v1.0.0安装失败，因为npm registry找不到对应tag。--follow-tags确保代码、文档、标签三者原子性同步。

5.4 故障演练：模拟网络中断下的本地恢复策略

真实世界中，git push可能因网络抖动中断。此时Git处于“半推送”状态：部分对象已上传，但引用未更新。强行重试会报错error: failed to push some refs。正确做法是：

# 1. 强制同步远程状态（不改变本地） git fetch --all --prune # 2. 检查本地与远程差异 git log origin/main..main --oneline # 3. 若本地有未推送提交，强制推送（仅限个人分支） git push --force-with-lease origin main

--force-with-lease比--force安全，它会检查远程分支是否被他人更新，若被更新则拒绝强制推送，避免覆盖他人工作。这是Git 2.0引入的“乐观锁”机制，比盲目--force多一层保护。

6. 实操心得与血泪教训：那些文档里不会写的细节

6.1 关于.gitignore的终极心法：先全局，后项目，再临时

新手常把所有忽略规则堆在项目级.gitignore，导致规则混乱。我的三层过滤法：

• 全局层（git config --global core.excludesfile ~/.gitignore_global）：放编辑器、系统文件等通用规则，如*.swp、.DS_Store
• 项目层（项目根目录.gitignore）：放语言/框架特有规则，如node_modules/、__pycache__/
• 临时层（.git/info/exclude）：放个人开发环境特有文件，如local-config.json，此文件不提交，仅本地生效

这样分层后，git status输出干净，且团队成员共享同一套项目规则。某次我接手遗留项目，发现.gitignore里有config.php，但实际需要提交config.example.php，于是把config.php移到.git/info/exclude，既保护本地配置，又不影响他人。

6.2 关于分支命名：main不是唯一选择，但必须统一

GitHub默认分支名已从master改为main，但企业内部可能用develop、trunk。关键不是名字，而是全团队强制统一。我见过最惨烈的案例：某团队两人分别用main和master作为默认分支，git push origin main和git push origin master互相覆盖，导致CI流水线随机失败。解决方案是在项目根目录放branch-name.txt文件，写明default_branch=main，并在README中强调。或者更彻底——用git config --add init.defaultBranch main设置全局默认分支，新git init自动创建main。

6.3 关于提交频率：不是越勤越好，而是“可逆性”优先

很多教程鼓吹“小步快跑”，每改一行就commit。但实际协作中，单次提交必须是逻辑完整的最小可逆单元。比如修复登录bug，应包含：

• 修改login.js的验证逻辑
• 更新login.test.js的测试用例
• 调整README.md的API文档

这三者构成一个原子操作。若只提交代码不提交测试，CI会失败；若只提交测试不提交代码，测试会挂。我坚持“提交前问自己：如果回退这次提交，系统是否仍能正常运行？”答案为否，则需合并更多变更。

6.4 关于GitHub仓库可见性：私有≠安全，公开≠危险

新手常误以为“私有仓库”绝对安全。但GitHub私有仓库仍可能因以下原因泄露：

• 成员误将私有仓库URL发到公开论坛
• CI/CD配置中硬编码API密钥，被git log追溯到
• Fork私有仓库时未关闭“Allow fork”选项，导致分支公开

相反，“公开仓库”只要遵循安全规范，反而更安全：

• 社区可审计代码漏洞（如硬编码密钥）
• GitHub自动扫描公开仓库的敏感信息
• 开源许可证提供法律保障

我的实践是：所有新项目默认公开，用.gitignore和git-secrets工具预防密钥泄露；仅当涉及客户数据或专利算法时，才申请私有仓库，并额外启用GitHub Advanced Security。

6.5 关于学习路径：不要死磕Git命令，先建一个“可工作的循环”

最后分享一个反直觉经验：别花一周背git rebase、git cherry-pick，先确保你能完成10分钟闭环：

1. 本地改一行代码
2. git add→git commit→git push
3. 切到GitHub网页，看到修改实时生效
4. 再切回本地，git pull同步回来

这个闭环建立后，你才真正理解“版本控制”的物理意义。之后学rebase是为了让历史更清晰，学cherry-pick是为了精准移植补丁——它们是优化项，不是入门门槛。我带过的最快学会Git的学员，是位设计师，她第一天就用git push上传PSD分层文件，虽然.gitignore没配好导致仓库臃肿，但她建立了“我的修改能被全世界看到”的真实感知。这种感知，比一百条命令更重要。

我在实际使用中发现，最可靠的Git工作流永远是：git status→git add→git commit→git push。中间任何一步出错，就回到git status重新诊断。Git不是魔法，它只是把文件变更的历史，用一套严谨的规则固化下来。当你不再把它当成“上传工具”，而看作“时间机器”，那些报错信息，就都变成了时光机仪表盘上的指示灯。