Git入门:本地代码推送到GitHub的完整流程

发布时间:2026/10/17 19:34:30
Git入门:本地代码推送到GitHub的完整流程
1. 项目概述这条命令到底值不值得学先说结论把本地代码推到 GitHub本质上就是三条 Git 命令的事。git add .、git commit -m 说明、git push。很多人一听“5分钟学会”就觉得是标题党但我可以负责任地告诉你如果你只是想把代码同步到 GitHub 仓库这五分钟绰绰有余。但这里有个容易被忽略的坑大多数人第一次推代码不是倒在命令上而是倒在“本地仓库和远程仓库没有关联”这一步。所以我这篇文章不打算只丢给你几条命令而是把“为什么要这么操作”“每一步在做什么”讲清楚。当你理解了 Git 的工作逻辑以后再遇到合并冲突、推送被拒绝这类问题你也能自己排查出个大概方向。这篇内容适合谁适合刚接触 Git、刚注册 GitHub、或者一直用“上传 zip 文件”方式来备份代码的同学。如果你已经在公司用 Git 做协作开发这篇文章对你来说有点基础了但如果你只是个人开发、写作业、做小项目把代码推到 GitHub 这个操作你今天看完就能自己动手。2. 内容整体设计与思路拆解本地和远程之间发生了什么2.1 先理解 Git 的三个“存档区”很多人学 Git 学得痛苦是因为一上来就背命令但脑子里没有画面。我换个说法Git 的本地操作本质上就是你在“草稿纸 → 文件夹 → 正式发布”这三个状态之间搬运文件。工作区就是你自己电脑上能看到的那些文件你改了代码改动的结果只存在于工作区。暂存区你可以把它理解成“打包台”。git add就是把你想提交的文件先放到这个打包台上告诉 Git“我这次要提交的是这些文件而不是别的”。版本库打包完成之后git commit就是把这些文件封箱生成一个不可变的版本快照。这个快照有版本号、有提交时间、有提交说明之后你想回滚到任何一个历史版本都靠这些快照。本地仓库里的版本快照Git 自己是知道的但 GitHub 服务器不知道。所以还需要一个动作——把本地版本库里的快照同步到远程服务器这就是git push。注意如果你只有git add和git commit你的代码永远只停留在本地硬盘如果你只git push而没有本地提交Git 会报错说“当前分支没有上游分支”或者“Everything up-to-date”因为你推上去的内容根本没有形成版本快照。2.2 为什么是 GitHub而不是直接在网站上传文件有人可能会问GitHub 网页上不是可以直接上传文件吗为什么还要学命令行直接网页上传适合一两个文件的场景但真实项目动辄几十个文件而且后续每次改动都手动上传版本管理就完全失控了。更重要的是Git 的本地版本历史是断网可用的。你在飞机上改了三个小时代码可以随时git commit等到了有网的地方一次git push就把所有提交同步上去。这是网页上传永远无法替代的核心能力。我更喜欢把 GitHub 理解成一个“代码银行保险箱”。本地仓库是手里的现金你可以随时存放commit但保险箱里的账本只有你主动同步push之后银行GitHub才会更新记录。如果中途硬盘坏了只要最近一次 push 过代码就还在保险箱里。3. 核心细节解析与实操要点推送前必须搞懂的三个关键点3.1 分支的概念不要一上来就在主线乱推第一次推送代码的人通常看到git push就直接敲回车结果推到了master或者main分支也没出什么问题。但如果你之后要和别人协作或者你想保留“开发版本”和“稳定版本”两个状态分支就是必须懂的基础概念。简单说分支就像一本书的不同章节草稿。main分支是最终发布的定稿dev分支是你在草稿本上写的新内容。你可以随意在dev分支上折腾等测试没问题了再把dev合并回main。对于个人项目你可以不用创建额外分支直接在main上推送也没问题。但如果你打算以后从事开发相关工作建议第一次推送前就养成创建分支的习惯。基础命令就一条git branch -M main这条命令的意思是把当前分支重命名为main。GitHub 新建仓库默认推荐主分支叫main但你的 Git 版本可能默认初始化成master名字不一致会导致推送出现奇怪的提示。先统一分支名再推送能省掉很多不必要的麻烦。3.2 远程仓库地址的关联为什么总是提示“找不到仓库”新手最常见的报错长这样fatal: origin does not appear to be a git repository fatal: Could not read from remote repository.这个报错翻译一下就是Git 根本不知道你要往哪儿推。你没有告诉它远程仓库的地址。git remote add origin https://github.com/你的用户名/你的仓库名.git这里的origin是一个代称你可以把它理解成“我给这个远程地址起了个别名叫 origin”。之后所有命令都不用再写一长串 URL直接写origin就行。名字你可以随便起但社区约定俗成用origin建议不要标新立异。3.3 SSH 还是 HTTPS推送时密码到底怎么填第一次推送时很多人在这一步被卡得非常痛苦。如果你用的是 HTTPS 地址Git 会让你输入 GitHub 的用户名和密码。注意这里的密码不是你的 GitHub 登录密码而是一个叫 Personal Access Token 的东西。这个设计是 GitHub 前几年改的规则初衷是提高安全性。Token 相当于一把“只拥有某些权限的备用钥匙”你在 GitHub 网站设置里生成然后复制粘贴到命令行里当密码用。如果你不想每次推送都输入用户名和 Token有两个选择配置 Git 凭据管理器让它记住凭证。改用 SSH 密钥认证配置好后推送不再需要输入任何密码。对于新手我建议先用 HTTPS Token 把流程跑通后面有需要再升级 SSH。不要一开始就折腾 SSH因为密钥生成、配置、测试这几个环节出错概率高容易打击学习热情。4. 实操过程与核心环节实现从零到推送到 GitHub 的完整流程4.1 第一步准备好一个本地项目文件夹假设你已经在电脑上新建了一个项目文件夹里面放着你的代码文件比如index.html、app.py、README.md等。打开终端先进入到这个文件夹cd ~/Desktop/my-project然后初始化本地仓库git init这一步会在当前文件夹下生成一个隐藏的.git文件夹它负责记录这个项目的所有版本历史。注意.git文件夹千万不要手动删删了之后你的版本历史就全没了。4.2 第二步配置你的身份信息第一次使用 Git 时最好先告诉 Git 你是谁。这个信息会记录在每次提交的版本快照里方便别人知道某次修改是谁做的。git config --global user.name 你的用户名 git config --global user.email 你的邮箱这里有一个实用技巧--global参数代表“全局生效”相当于只设置一次之后所有项目都用这个身份。如果你只想针对当前项目设置不同身份去掉--global即可。4.3 第三步添加文件到暂存区并生成第一个版本git add . git commit -m 第一次提交初始化项目git add .里的点号代表“当前目录下所有文件”。如果你只想添加某个文件可以写成git add README.md添加之后用git status看一下当前状态确认没有遗漏文件。git status会明确告诉你哪些文件已经被暂存哪些文件还没有被跟踪。4.4 第四步在 GitHub 网站创建远程仓库打开 GitHub点右上角的加号选择 “New repository”。仓库名称填一个和你本地项目相关的名字比如my-project。注意这里不要勾选 “Add a README file”、“Add .gitignore” 这些初始化选项因为你本地已经有文件了如果同时初始化会产生冲突。创建完成后GitHub 会跳转到一个页面里面有几个命令提示。你需要用到的是仓库地址形如https://github.com/你的用户名/my-project.git复制这个地址回到终端。4.5 第五步关联远程仓库并推送git remote add origin https://github.com/你的用户名/my-project.git git branch -M main git push -u origin main这三条命令分别做三件事关联远程地址、统一主分支名、推送并设置上游关联。-u参数的意思是“记住这次推送的目标”之后你再推送就可以直接写git push。如果 HTTPS 认证配置没问题此时终端会要求输入用户名和密码。用户名填你的 GitHub 用户名密码填 Token 而不是登录密码。4.6 第六步验证推送结果推送成功后终端会显示类似这样的输出Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Writing objects: 100% (5/5), 980 bytes | 980.00 KiB/s, done. Total 5 (delta 0), reused 0 (delta 0), reused 0 (delta 0) To https://github.com/你的用户名/my-project.git * [new branch] main - main branch main set up to track remote branch main from origin.看到[new branch] main - main就说明推送成功了。这时候打开 GitHub 仓库页面刷新一下就能看到你的代码已经出现在线上。5. 常见问题与排查技巧实录我踩过的坑你大概率也会踩5.1 推送被拒绝远程仓库有本地没有的文件这是最常见的报错之一! [rejected] main - main (fetch first) error: failed to push some refs出现这个问题的原因通常是你本地初始化仓库之前远程仓库里已经有一些文件。比如你在 GitHub 网页创建仓库时勾选了 README或者别人已经在远程提交过代码。解决思路很简单先把远程的文件拉到本地合并之后再推送。git pull origin main git push -u origin main如果git pull之后出现合并冲突说明本地和远程修改了同一个文件的同一块内容需要手动编辑文件保留想要的内容然后再提交一次。5.2 每次都要输入账号密码嫌麻烦怎么办如果你确认自己已经认证成功但每次推送都要输入一遍用户名和 Token可以在系统层面开启凭据存储git config --global credential.helper store这个配置会把凭证以明文形式存在电脑上。对于个人开发的电脑方便程度大于风险但如果你用的是公用电脑不建议执行这条命令。我个人更推荐的方案是配置 SSH虽然首次配置要花点时间但之后推送完全免密体验非常顺滑。5.3 误把大文件提交了怎么办很多初学者会把依赖包、生成目录、本地配置文件一起提交到 GitHub。比如 Node.js 项目里的node_modules文件夹Python 项目里的venv虚拟环境目录。这些文件体积庞大而且不需要备份到线上。解决办法是在项目根目录新建一个.gitignore文件把你不想跟踪的文件名或目录名写进去这样 Git 会自动跳过它们。以 Node 项目为例node_modules/ dist/ .env需要注意.gitignore只对“尚未被 Git 跟踪”的文件生效。如果你已经把大文件提交到了本地版本历史里光加.gitignore是不够的还需要把历史记录里的文件移除git rm -r --cached node_modules这条命令只把文件从 Git 跟踪里移除不会删除你本地磁盘上的实际文件。执行之后再git commit、git push远程仓库里的对应文件就被清掉了。5.4 提交信息写错了怎么办如果你刚刚git commit还没有推送可以修改最近一次提交信息git commit --amend -m 修改后的提交说明如果你已经推送了修改提交信息之后需要强制推送git push --force-with-lease注意--force-with-lease比--force安全得多。它的意思是“只有当远程分支没有别人新提交时才允许强制推送”可以避免覆盖别人的工作。个人项目无所谓协作项目一定要用带-with-lease的版本。5.5 常见问题速查表问题现象可能原因解决办法fatal: not a git repository当前目录没有初始化 Git执行git initfatal: origin does not appear...没有添加远程仓库执行git remote add origin 地址推送上去了但网页没看到文件推送的是另一个分支在 GitHub 网页切换分支或者统一分支名要求输入密码但不知道填什么HTTPS 认证需要 Token在 GitHub Settings 中生成 Personal Access Token提示 Everything up-to-date本地没有新提交检查是否漏了git add和git commit推送文件太多太慢误提交了大文件添加.gitignore并清理缓存6. 实操心得与扩展技巧从“能用”到“好用”的三个习惯6.1 每次提交只做一件事我见过太多人一次提交几十个文件提交信息写“更新”过了一个月自己都看不懂这版改了什么。好的习惯是每次提交只针对一个功能点或一个修复提交信息尽量具体比如“修复登录页密码框无法聚焦的问题”。这样做的好处一是回滚版本时你能精准定位二是如果某个提交引入了问题代码审查能一眼发现。6.2 推送前先看一眼 diff而这其实是最重要的一个习惯。git diff --stat这条命令会简洁地显示这次改动涉及哪些文件、增删了多少行。推送之前花十秒看一遍能帮你拦截掉很多低级错误比如不小心把调试用的临时文件也提交进去了。6.3 项目维护久了记得打标签当你的项目发展到某个稳定版本比如完成了第一个里程碑可以给这个提交打个标签git tag v1.0 git push --tags标签就像一个书签标记着项目历史中某个特殊节点。以后你哪怕改得面目全非随时都能通过标签找回当时那个版本。这个技巧在个人项目里很容易被忽略但一旦用起来你会发现特别好用。7. 写在最后的个人建议把代码推到 GitHub 这个操作本质上是一个“技术门槛低但思维转变大”的过程。你可能会遇到各种报错但大部分报错在搜索引擎里都能找到答案。切忌一报错就想着重装 Git、重新克隆仓库先去读报错信息它往往已经把原因写得很清楚了。如果你今天跟着这篇文章操作了一遍但中间出了差错别灰心把终端里报错的那几行复制下来对着这篇文章的排查表格逐条对照。大部分人第一次推送都会卡在认证或者分支名上你把这些坑踩一遍后面就会顺很多。我个人现在推送代码早已不需要思考命令是什么靠的是肌肉记忆。但每次看到终端输出main - main的那一刻心里还是会觉得踏实——代码有了第二个落脚点不怕硬盘坏不怕电脑丢。希望这篇文章也能让你体验到那种安心感。