1. 从一次代码丢失事故说起：为什么你必须搞懂 Git 与 GitHub
去年冬天，一位做后端的朋友深夜给我打电话，声音都在抖。他花了三周写的一个订单系统，因为本地硬盘突然罢工，整个项目文件夹直接变成了一堆无法读取的坏道。他平时习惯把代码放在桌面上，唯一的备份是两周前发给同事的一个压缩包。那两周里他重构了支付模块、加了库存锁、修了十几个并发问题，全没了。他问我有没有办法恢复，我只能沉默。这件事之后，他花了整整一个周末学会了 Git，把代码推到了 GitHub 上，再也没丢过一行代码。
这个故事不是个例。我见过太多人写代码时只会在本地建文件夹，版本靠“项目名_最终版_真的最终版_打死也不改版”来管理。这种土办法在单人小脚本上勉强能用，一旦涉及多人协作、功能分支、线上回滚，立刻崩溃。Git 和 GitHub 就是来解决这个问题的。Git 是本地版本控制系统，负责记录你每一次代码变更，让你可以随时回到任何一个历史版本；GitHub 是基于 Git 的远程托管平台，负责把你的代码仓库同步到云端，实现多人协作、代码审查、持续集成和开源分享。简单说，Git 管“版本”，GitHub 管“托管和协作”。
这篇文章适合谁看？如果你是刚学编程的新手，还在用复制文件夹的方式管理代码，这篇能帮你建立正确的版本管理习惯；如果你已经会一些 Git 命令但总是记不住、用不顺，这篇会帮你把零散的知识点串成一条完整的链路；如果你正在准备团队协作或者开源贡献，这篇里的分支策略、冲突解决、Pull Request 流程都是可以直接抄作业的实战内容。我会从底层原理讲到实操命令，从单人开发讲到多人协作，把 Git 与 GitHub 托管项目代码这件事彻底讲透。
2. Git 与 GitHub 的核心概念拆解：别被术语吓到
2.1 Git 到底是什么：一个会记日记的代码管家
很多人第一次接触 Git 时，被“分布式版本控制系统”这个名词劝退。其实你可以把 Git 想象成一个极其认真的日记本。你每写一段代码，告诉它“记一下”，它就会把当前所有文件的状态拍一张快照，存进一个隐藏的.git文件夹里。这张快照叫commit，里面包含了你改了哪些文件、改了什么内容、谁改的、什么时候改的、为什么改的。以后你想回到任何一个时间点，只要翻到对应的那一页就行。
Git 和普通备份最大的区别在于：它记录的是变更，不是完整拷贝。你第一次提交时，Git 会存下所有文件的完整内容；第二次提交时，它只存变化的部分，没变的文件通过指针引用上一次的快照。这样做的好处是仓库体积小、速度快。我实测过一个中型项目，三千多次提交，整个.git文件夹也就几十兆，比每次复制整个项目文件夹高效太多。
还有一个关键概念叫分支（branch）。你可以把主线想象成一条河流，分支就是从主线上分出去的一条小支流。你可以在支流上随便折腾，改坏了也不影响主线，改好了再合并回去。这个机制让多人协作成为可能：每个人在自己的分支上开发，互不干扰，最后统一合并。
2.2 GitHub 的角色：代码的云端客厅
Git 是本地工具，装在你电脑上，不需要联网就能用。GitHub 是一个网站，把 Git 仓库托管在云端。你可以把本地仓库“推”到 GitHub，也可以把 GitHub 上的仓库“拉”到本地。它的核心价值有三个：备份、协作、展示。
备份不用多说，代码放在云端，本地硬盘坏了也不怕。协作是 GitHub 的杀手锏：多人可以同时操作同一个仓库，通过 Pull Request 机制做代码审查，通过 Issue 跟踪任务和 Bug。展示则是开源生态的基础，你的 GitHub 主页就是你的技术简历，很多招聘方会直接看你的提交记录和项目代码。
这里要区分一个常见误区：GitHub 不是唯一的托管平台，还有 GitLab、Bitbucket、Gitee 等，它们都基于 Git，操作逻辑大同小异。你学会了 GitHub，换到其他平台也能快速上手。
2.3 三个工作区域：理解 Git 的关键钥匙
很多人学 Git 命令时觉得混乱，是因为没搞清楚三个工作区域的关系。Git 把代码分成三个地方：
| 区域 | 英文名 | 作用 | 类比 |
|---|---|---|---|
| 工作区 | Working Directory | 你正在编辑的文件目录 | 你的书桌 |
| 暂存区 | Staging Area | 准备提交的变更清单 | 待寄出的包裹 |
| 本地仓库 | Local Repository | 已提交的历史记录 | 档案柜 |
| 远程仓库 | Remote Repository | GitHub 上的云端副本 | 云端备份柜 |
你修改文件是在工作区；git add把变更放进暂存区；git commit把暂存区的内容存进本地仓库；git push把本地仓库同步到远程仓库。反过来，git pull把远程仓库的变更拉回本地并合并到工作区。理解了这个流转关系，所有 Git 命令都不再是死记硬背。
提示：暂存区的存在是为了让你可以精确控制每次提交的内容。比如你改了五个文件，但只想提交其中三个，就可以只 add 那三个，另外两个留在工作区继续修改。这个设计在排查问题时特别有用。
3. 从零开始的完整实操：本地仓库到 GitHub 托管
3.1 环境准备与初始配置
第一步是安装 Git。Windows 用户去官网下载安装包，一路下一步即可，安装完成后在开始菜单里能找到 “Git Bash”，这是一个模拟 Linux 命令行的终端，后续操作都在这里进行。macOS 用户如果装了 Xcode Command Line Tools，Git 已经自带了，终端输入git --version能看到版本号就说明可用。Linux 用户直接用包管理器安装，比如 Ubuntu 下sudo apt install git。
安装完成后，必须做两件事：配置用户名和邮箱。这两个信息会写进每一次提交记录里，是追溯代码作者身份的依据。
git config --global user.name "你的名字" git config --global user.email "你的邮箱"--global表示全局配置，对这台电脑上所有仓库生效。如果你在公司项目和个人项目想用不同的身份，可以在具体仓库目录下不加--global重新配置，局部配置会覆盖全局配置。
还有一个实用配置是设置默认分支名。Git 早期默认分支叫master，现在社区更推荐用main，GitHub 也默认用main。你可以在初始化时指定：
git config --global init.defaultBranch main另外建议开启颜色显示和别名简化。比如把git status简写成git st，把git checkout简写成git co，能省不少敲键盘的时间：
git config --global alias.st status git config --global alias.co checkout git config --global alias.br branch git config --global alias.ci commit3.2 本地仓库初始化与第一次提交
假设你有一个项目文件夹叫my-project，里面已经有了一些代码文件。打开终端，进入这个目录，执行：
cd my-project git init这个命令会在当前目录下创建一个隐藏的.git文件夹，所有版本记录都存在里面。此时你的项目还没有任何提交记录，执行git status会看到所有文件都是红色的 “Untracked files”，意思是 Git 还没开始跟踪它们。
接下来把文件加入暂存区：
git add ..表示当前目录下所有文件。如果只想添加特定文件，把.换成文件名即可。执行完再git status，文件变成绿色，表示已经进入暂存区，等待提交。
然后执行提交：
git commit -m "初始化项目，添加基础代码"-m后面跟的是提交信息，必须写清楚这次提交做了什么。我见过有人写 “update” 或者 “fix bug”，这种信息在回溯历史时毫无价值。好的提交信息应该像一封简短的邮件主题，让人一眼知道这次变更的目的。比如 “修复订单金额计算精度丢失问题” 就比 “修复 bug” 强一百倍。
3.3 连接 GitHub 远程仓库
本地仓库建好后，下一步是把它托管到 GitHub。首先在 GitHub 上创建一个新仓库。点击右上角加号，选择 “New repository”，填写仓库名，建议和本地项目名一致。描述可填可不填，可见性选 Public 或 Private 根据需求决定。不要勾选 “Initialize this repository with a README”，因为我们要把本地已有项目推上去，如果远程仓库先有了文件，推送时会冲突。
创建完成后，GitHub 会显示一个页面，里面有仓库地址。地址有两种格式：HTTPS 和 SSH。HTTPS 格式是https://github.com/用户名/仓库名.git，SSH 格式是git@github.com:用户名/仓库名.git。新手建议先用 HTTPS，配置简单，缺点是每次推送可能要输入账号密码。SSH 需要配置密钥，一次配置永久免密，适合长期使用。
在本地终端里，把远程仓库地址关联到本地：
git remote add origin https://github.com/你的用户名/my-project.gitorigin是远程仓库的默认别名，你也可以叫别的名字，但 origin 是社区惯例，建议保持一致。执行git remote -v可以查看当前关联的远程地址。
然后推送本地提交到远程：
git push -u origin main-u表示把本地 main 分支和远程 origin/main 分支关联起来，以后直接git push就行，不用再指定远程和分支名。第一次推送时，GitHub 可能会要求你输入账号密码或者授权令牌。现在 GitHub 已经不支持密码推送了，需要用 Personal Access Token 代替密码。在 GitHub 设置里的 Developer settings 中生成一个 Token，勾选 repo 权限，复制下来当密码用。这个 Token 只显示一次，务必保存好。
3.4 日常开发循环：改代码、提交、推送
仓库建好之后，日常开发就是一个循环：改代码 →git add→git commit→git push。听起来简单，但实际操作中有几个细节决定效率。
第一，提交前先git status和git diff。status看哪些文件变了，diff看具体改了什么内容。这个习惯能帮你避免误提交。我踩过的坑：有一次调试时在代码里硬编码了一个测试用的 API 密钥，提交时没检查，直接推到了公开仓库，虽然马上删了，但 Git 历史里还留着，只能重建仓库。从那以后，我每次提交前必看 diff。
第二，提交粒度要小。不要攒了一周的代码一次性提交，那样提交信息没法写清楚，出问题也不好回滚。理想状态是完成一个独立功能或修复一个 Bug 就提交一次。比如 “添加用户登录接口” 和 “修复登录接口的空指针异常” 应该是两次提交，而不是一次 “登录功能相关改动”。
第三，推送前先拉取。如果多人协作，远程仓库可能已经有别人的提交，你直接 push 会被拒绝。正确做法是先git pull把远程变更合并到本地，解决可能的冲突，再 push。这个顺序能避免很多不必要的麻烦。
4. 分支管理与多人协作：从单打独斗到团队作战
4.1 分支的本质与常用操作
分支是 Git 最强大的功能之一。默认情况下，你有一个 main 分支，所有提交都在上面。但实际开发中，main 分支应该保持稳定，只存放经过测试的代码。新功能开发、Bug 修复、实验性尝试都应该在独立分支上进行。
创建一个新分支并切换过去：
git checkout -b feature/user-login这个命令等价于先git branch feature/user-login创建分支，再git checkout feature/user-login切换过去。现在你在新分支上提交代码，不会影响 main 分支。开发完成后，把分支推送到远程：
git push -u origin feature/user-login然后在 GitHub 上发起 Pull Request，请求把 feature/user-login 合并到 main。团队成员可以在 PR 页面审查代码、留言讨论、提出修改意见。确认无误后，点击 Merge 按钮完成合并。
合并完成后，本地可以切回 main 并删除已合并的分支：
git checkout main git pull git branch -d feature/user-login-d是安全删除，如果分支还没合并会提示警告。如果确定要强制删除，用-D。
4.2 分支命名规范与团队协作策略
分支命名看似小事，但在团队协作中直接影响沟通效率。我见过有人用test、abc、dev2这种名字，过两天自己都忘了是干什么的。推荐一套清晰的命名规范：
| 分支类型 | 命名格式 | 示例 | 用途 |
|---|---|---|---|
| 功能分支 | feature/功能名 | feature/order-export | 开发新功能 |
| 修复分支 | fix/问题描述 | fix/login-timeout | 修复 Bug |
| 热修复 | hotfix/问题描述 | hotfix/payment-error | 紧急修复线上问题 |
| 发布分支 | release/版本号 | release/v1.2.0 | 准备发布版本 |
| 实验分支 | experiment/主题 | experiment/new-ui | 尝试性改动 |
团队协作中还有一种常见策略叫Git Flow，它定义了 main、develop、feature、release、hotfix 五种分支及其流转规则。这套流程适合版本发布周期明确的中大型项目。小团队或持续部署的项目可以用更简单的GitHub Flow：main 分支永远可部署，任何改动都从 main 拉分支，通过 PR 合并回 main，合并后自动部署。选择哪种策略取决于团队规模和发布节奏，没有绝对优劣。
4.3 冲突是怎么产生的，怎么解决
冲突是多人协作中绕不开的问题。当两个人修改了同一个文件的同一行，Git 无法自动判断该保留谁的版本，就会标记冲突，暂停合并，等你手动解决。
冲突发生时，打开冲突文件，会看到类似这样的标记：
<<<<<<< HEAD 你的代码版本 ======= 对方的代码版本 >>>>>>> feature/other-branch<<<<<<< HEAD到=======之间是你当前分支的内容，=======到>>>>>>>之间是对方分支的内容。你需要手动决定保留哪部分，或者把两者融合成新的逻辑。解决后删除这些标记符号，保存文件，然后git add标记为已解决，再git commit完成合并。
我处理冲突的经验是：先沟通，再动手。如果冲突涉及核心逻辑，直接找对方确认意图，比自己猜要快得多。另外，频繁拉取远程变更能减少冲突概率。每天开工前先git pull，收工前再git pull，让本地尽量跟远程保持同步。
注意：解决冲突时千万不要直接删掉对方的代码。曾经有个团队新人遇到冲突，嫌麻烦直接把对方分支的内容全删了，结果合并后线上功能缺失，排查了半天才发现是冲突解决时误删。冲突标记里的每一段代码都有存在的理由，不确定就问。
5. 高频问题排查与避坑指南
5.1 提交错了怎么撤回
这是新手最常遇到的问题。根据错误发生的阶段，处理方式不同：
| 场景 | 命令 | 说明 |
|---|---|---|
| 刚 commit，还没 push | git reset --soft HEAD~1 | 撤销提交，保留变更在暂存区 |
| 刚 commit，还没 push，想改提交信息 | git commit --amend | 修改最后一次提交的信息或内容 |
| 已经 push 到远程，想撤销 | git revert HEAD | 创建一个反向提交，安全撤销 |
| 误 add 了不想提交的文件 | git reset HEAD 文件名 | 从暂存区移除该文件 |
git reset --soft和git reset --hard的区别要特别注意：--soft只撤销提交记录，代码变更还在；--hard会连代码变更一起丢弃，不可恢复。用--hard之前一定要确认没有未保存的工作。
5.2 推送被拒绝怎么办
执行git push时看到rejected或non-fast-forward错误，说明远程仓库有你本地没有的提交。最常见的原因是别人先推了代码，或者你在 GitHub 上直接改了文件。解决办法是先拉取再推送：
git pull origin main如果拉取时提示分支没有关联，可以指定：
git pull origin main --allow-unrelated-histories--allow-unrelated-histories用于合并两个没有共同历史的分支，比如本地初始化的仓库和远程带 README 的仓库首次合并。拉取后如果有冲突就解决冲突，然后正常 push。
5.3 误删文件或误改代码怎么恢复
Git 的好处就是几乎什么都能恢复。如果误删了文件但还没提交：
git checkout -- 文件名如果已经提交了删除操作，想找回文件：
git log --diff-filter=D --summary找到删除该文件的那次提交，然后从那次提交的父提交中恢复：
git checkout 父提交哈希 -- 文件名如果连提交记录都找不到了，可以用git reflog查看所有 HEAD 移动记录，包括已经被 reset 掉的提交。reflog是 Git 的“后悔药”，默认保留 90 天。我靠这个命令救回过好几次误操作。
5.4 大文件与敏感信息处理
Git 不适合管理大文件，比如视频、数据集、编译产物。如果不小心提交了一个几百兆的文件，仓库会变得臃肿，克隆和推送都会变慢。解决办法是用.gitignore文件提前排除不需要跟踪的文件。在项目根目录创建.gitignore，写入规则：
node_modules/ *.log .env dist/ *.mp4如果已经提交了大文件，需要用git filter-branch或 BFG 工具清理历史，操作较复杂，建议直接重建仓库。敏感信息如密码、密钥一旦提交，即使删除文件，历史记录里依然存在。正确做法是立即更换密钥，然后用工具清理历史，或者干脆重建仓库。
提示：
.gitignore只对未跟踪的文件生效。如果文件已经被 Git 跟踪，需要先git rm --cached 文件名从跟踪列表中移除，再写入.gitignore。
6. 进阶技巧：让 Git 与 GitHub 用起来更顺手
6.1 SSH 免密配置与多账号管理
如果你同时管理个人 GitHub 账号和公司账号，或者觉得每次输入 Token 太麻烦，SSH 是更好的选择。生成密钥对：
ssh-keygen -t ed25519 -C "你的邮箱"一路回车，会在~/.ssh/目录下生成id_ed25519和id_ed25519.pub两个文件。把.pub文件的内容复制到 GitHub 的 SSH Keys 设置里。然后测试连接：
ssh -T git@github.com看到 “Hi 用户名” 就说明配置成功。之后把远程地址从 HTTPS 换成 SSH 格式：
git remote set-url origin git@github.com:用户名/仓库名.git多账号场景下，可以在~/.ssh/config文件中配置不同 Host 别名，分别对应不同的密钥文件，实现同一台电脑管理多个 GitHub 账号。
6.2 用 GitHub Actions 做自动化
GitHub Actions 是 GitHub 提供的持续集成服务。你可以在仓库里创建一个.github/workflows/目录，放入 YAML 配置文件，定义在什么条件下自动执行什么任务。比如每次 push 到 main 分支时自动运行测试：
name: Run Tests on: push: branches: [ main ] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Setup Python uses: actions/setup-python@v5 with: python-version: '3.11' - name: Install dependencies run: pip install -r requirements.txt - name: Run tests run: pytest这个配置会在每次推送到 main 时自动跑一遍测试，测试不通过会在 GitHub 上显示红色叉号，提醒你代码有问题。除了测试，Actions 还能做自动部署、代码格式检查、依赖更新提醒等。免费额度对个人项目完全够用。
6.3 提交信息规范与代码审查习惯
提交信息写得好，团队协作效率翻倍。推荐使用Conventional Commits规范，格式是类型(范围): 描述。常见类型包括：
feat：新功能fix：修复 Bugdocs：文档变更style：格式调整，不影响代码逻辑refactor：重构test：测试相关chore：构建工具或辅助工具变更
示例：feat(order): 添加订单导出 Excel 功能、fix(login): 修复登录超时未跳转问题。这种格式不仅人类可读，还能被工具解析，自动生成变更日志。
代码审查方面，发起 Pull Request 时尽量控制规模。一个 PR 改几百行代码，审查者很难看仔细。理想情况下，一个 PR 只解决一个问题，改动控制在 200 行以内。审查者要关注逻辑正确性、边界条件、命名规范、是否有测试覆盖，而不是纠结空格和换行。
7. 我踩过的坑与最后分享的几个小技巧
刚用 Git 那会儿，我犯过一个经典错误：在 main 分支上直接开发，改到一半发现方向不对，想切回之前的版本，结果发现没提交的代码全丢了。后来我养成了一个习惯：开工前先拉分支，哪怕只是改一行配置。分支是免费的，创建和切换几乎不耗时，但能给你一个安全的实验环境。
另一个坑是.gitignore的生效时机。我曾经在项目中期才加.gitignore，发现之前提交的node_modules还在仓库里，每次git status都显示一堆变更。正确做法是项目初始化时就创建.gitignore，如果已经提交了，用git rm -r --cached node_modules从跟踪列表移除，再提交一次。
最后分享一个查看历史的技巧：git log --oneline --graph --all能以图形化方式展示所有分支的提交历史，一眼看清分支从哪分出去、在哪合并回来。配合git log -p 文件名查看某个文件的具体变更历史，排查问题时特别高效。
Git 和 GitHub 的学习曲线前陡后平，刚开始记命令确实痛苦，但一旦理解了工作区、暂存区、本地仓库、远程仓库这四个区域的关系，所有命令都会变得顺理成章。我建议你从今天开始，把手上任何一个项目用 Git 管起来，推到 GitHub 上。哪怕只是一个练习 Demo，这个动作本身就会让你比昨天更专业。
