如果你在搜索引擎里敲过“GitHub”这几个字那大概率经历过这种场面注册完账号面对一堆英文界面发呆然后被git clone、commit、push几条命令折磨得怀疑人生最后连“怎么把本地文件夹传上去”都能耗掉一下午。GitHub 确实有学习门槛但它的门槛不在技术难度而在于你手上有没有一条完整、能照着一步步操作的主线。这篇文章我把主要知识点梳理成一条主线先搞清楚 Git 和 GitHub 的关系再从注册到第一次 push 走通全流程接着讲多人协作里的分支、PR、Issue 怎么配合再聊怎么评估、下载、运行别人的开源项目把自己的仓库收拾专业最后给出几个日常高频报错的排查思路。新手可以全文通读有一定基础的人直接跳到对应章节。1. 一个容易被低估的认知门槛Git 跟 GitHub 从来不是一回事1.1 Git 是本地存档工具GitHub 是协作中心很多新手把“Git”和“GitHub”混着叫但这两者解决的其实不是同一个问题。Git 是一个运行在你本机的版本控制工具。它把你的项目目录变成一个“有存档记录的文件夹”每一次commit都等于打了一个存档点之后无论你怎么改、怎么删随时可以回退到任意一个存档。没有 Git 的时候我见过最惨烈的局面是团队里有人用“最终版”“最终版2”“最终版_再也不改”这种文件名协作后来发现两个版本的代码各有千秋又没法合并只能手工比对。Git 就是来终结这种混乱的。GitHub 则是一个托管 Git 仓库的云端平台。你可以把本地仓库推到 GitHub 上相当于给项目做了远程备份别人也能通过这个平台看到你的代码、提出修改建议甚至直接把代码合并进来。更准确地说GitHub 是一个以代码为载体的协作社区。一个容易混淆的点是不用 GitHubGit 照样能本地用但不学 Git 基础直接用 GitHub 网页端上传文件很快会碰壁。所以下面所有操作我都默认你本机装好了 Git。1.2 新手需要先认识的五个核心对象我在带新人时第一步从来不是让背命令而是让他们在脑子里建立五个基本概念名词它是什么解决什么问题生活化类比Repository仓库一个项目的完整代码目录包含所有文件和历史记录把项目整体管理起来一个项目文件夹Commit提交一次代码改动的快照让改动可追溯、可回退游戏里的存档点Branch分支从主线分出来的独立开发线新功能、修 Bug 时不污染主代码平行世界Pull RequestPR请求把某个分支的改动合并到另一个分支让改动经过评审再合入一份合并提案Issue项目内的任务单 / 讨论帖记录需求、Bug、想法便利贴 / 工单这里重点说下 Commit 背后的机制。Git 的本地状态分成三层工作区、暂存区、历史区。你平时改文件改的是“工作区”执行git add后改动进入“暂存区”执行git commit暂存区的内容才真正写入“历史区”。很多新手卡在“我明明改了文件为什么git status看不到变化”就是少做了git add这一步。1.3 开始前的准备清单一个 GitHub 账号注册地址在官网首页即可进入。本机安装 Git。Windows 用户建议下载官方安装包macOS 可以brew install gitLinux 用发行版自带的包管理器。一个终端。Windows 请用 Git Bash别用默认的 CMD否则很多快捷键和命令体验都很别扭。项目路径尽量不要放在含中文和空格的目录下。这不是玄学是我见过太多人在这上面踩坑尤其 Windows 下的权限和编码问题会集中爆发。准备做完我们开始走第一条完整链路。2. 从注册账号到第一次 push新手最容易卡住的六个细节2.1 注册账号时就要决定的三件事第一用户名。这个用户名会公开出现在你的 commit 记录和项目地址里以后很难改取一个像“英文名数字/缩写”的组合比较稳妥。第二隐私邮箱。GitHub 默认会把你的注册邮箱公开在提交记录里我建议在 Settings → Emails 里勾选“Keep my email addresses private”。勾选后 GitHub 会给你分配一个用户名users.noreply.github.com邮箱之后本地 Git 配置就要用这个邮箱否则提交记录无法关联到你的账号。第三两步验证。建议所有账号都开启 2FA这不仅能保护你以后维护的项目也能避免账号被盗后被恶意篡改代码。2.2 本机 Git 的初始配置两条命令定乾坤装好 Git 后打开终端先执行git config --global user.name 你的用户名 git config --global user.email 你的 GitHub 绑定邮箱/或 noreply 邮箱这两条配置影响极大。GitHub 判断一次提交属于哪个用户靠的不是“登录状态”而是提交者邮箱。如果你本地填的邮箱和 GitHub 账号不一致push 上去的代码会显示成一个灰色未知作者。我接手过不少项目历史记录里一大半提交都来自“noreplygithub.com”或者随便敲的邮箱后期想找人问当时为什么这么写都找不到。另外建议顺手处理换行符问题。Windows 下执行git config --global core.autocrlf truemacOS 和 Linux 执行git config --global core.autocrlf input不设置的话Windows 和 Linux 协作时每次提交都会出现大量与内容无关的换行符变更review 时非常痛苦。2.3 SSH Key配一次之后不用反复输密码用 HTTPS 方式 push 也可以但每次都要弹窗输用户名和 token很烦。SSH 方式配好之后一劳永逸。生成密钥Git Bash 里执行ssh-keygen -t ed25519 -C 你注册 GitHub 的邮箱一路回车即可默认会生成在~/.ssh/id_ed25519和~/.ssh/id_ed25519.pub。然后查看公钥cat ~/.ssh/id_ed25519.pub复制完整输出到 GitHub 网页的 Settings → SSH and GPG keys → New SSH key粘贴保存。验证是否成功ssh -T gitgithub.com看到Hi 你的用户名! Youve successfully authenticated就说明通了。这里有个坑公钥生成路径一定要是默认的~/.ssh别手动改到项目目录里否则 Git 找不到密钥报错时又得排查半天。2.4 第一次创建仓库并完成 push 的完整命令链路最推荐新手的方式先在网页端创建空仓库拿到远程地址然后本地 clone 下来。这样一开始就把“远程”和“本地”对应上了不容易慌。网页端右上角 → New repository填仓库名选 Public 或 Private不要勾选任何初始化文件直接创建。创建后会看到一屏提示命令复制git clone gitgithub.com:用户名/仓库名.git本地执行git clone gitgithub.com:用户名/仓库名.git cd 仓库名把项目文件放进这个目录后就是标准的四步走git add . git commit -m first commit git branch -M main git push -u origin main逐个解释git add .把当前目录所有改动加入暂存区。如果你只想提交某个文件可以替换成文件名。git commit -m ...把暂存区内容提交到本地历史区。-m后面是提交说明建议写清“做了什么”别写“update”。git branch -M main把当前分支重命名为 main。GitHub 默认分支名是 main而老版本 Git 本地默认分支是 master统一名称是避免后续推送混乱。git push -u origin main把本地 main 分支推到远程-u是建立本地分支与远程分支的追踪关系以后直接git push就能推。如果你看到一个报错“remote origin already exists”说明仓库已经配过远程地址用git remote -v查看现有地址然后用git remote set-url origin 新的地址修正。2.5 网页端上传文件和真正用 Git 管理的区别很多人刚开始不想碰命令行会直接在网页仓库里点“Add file → Upload files”上传整个文件夹。这条路能走但只适合非常小的临时文件比如一个文档、一张图片。真正的项目开发网页上传完全支撑不了原因有很多没有历史记录、无法多人同时改、上传大量文件容易超时、后续无法分支管理。如果你实在暂时不想学完整 Git也建议至少装一个 GitHub Desktop 客户端图形化界面对新人友好底层依然是 Git 的逻辑。在桌面端克隆仓库、切分支、提交、推送都比网页端靠谱得多。2.6 界面语言想换成中文怎么办GitHub 网页端没有全站中文设置。你可以用浏览器自带的翻译功能或者借助浏览器翻译插件把网页内容自动翻译成中文操作最直接。桌面端 GitHub Desktop 也是英文界面但核心词汇就那么几个Repository仓库、Branch分支、Commit提交、Push/Pull推送/拉取看几次就记住了不用硬翻译。命令行工具的提示默认跟随系统语言如果你把系统 locale 设为中文部分信息会显示中文但最稳定的做法还是直接熟悉英文报错。3. 多人合作的标准流程分支、Pull Request 和 Issue 怎么配合3.1 分支把“半成品”和“稳定版”强行分开一个仓库的 main 分支应该始终保持可运行、可发布的状态。你新写一个功能时如果直接在 main 上改改到一半发现线上出了问题想回退就会非常被动。正确做法是开一条功能分支git checkout -b feat/user-login这条命令同时完成两件事创建新分支 切换过去。分支命名建议遵循惯例feat/表示新功能、fix/表示修 Bug、docs/表示文档改动、chore/表示杂务。一看到分支名别人就知道你正在干什么。新手最容易出的问题是在分支 A 改了文件还没提交直接切到分支 B结果发现改动跟着“跑”过去了。记住未提交的修改会跟随工作区切换。如果你临时要切换分支要么先把改动 commit要么用git stash暂存起来处理完再git stash pop恢复。3.2 Pull Request它不是“拉代码”而是“请求合并”很多人看到 Pull Request 这个英文直译就晕了其实它的本质很朴素我完成了一个分支的改动现在请求仓库维护者把这个分支合并进目标分支。标准流程本地从 main 创建功能分支git checkout -b feat/login在分支上正常开发多次git add、git commit推送分支到远程git push -u origin feat/login网页端会弹出提示“Compare pull request”点击进入创建 PR 页面填写 PR 标题和描述说明“做了什么、为什么做、怎么测的”邀请同事或维护者 Review通过后点击 Merge合并进 mainPR 描述是很多人忽略的重点。代码 review 的人不是你肚子里的蛔虫你写清楚背景和验证步骤reviewer 才敢放心合。在描述里写Fix #12、Close #123这种格式合并后还会自动关闭对应 Issue是目前开源项目里最常用的做法。关于合并方式GitHub 提供三种区别很关键合并方式效果适用场景Merge commit保留所有提交历史额外生成一个合并提交团队内部长期分支Squash and merge把该分支所有提交压缩成一条开源小 PR历史最干净Rebase and merge把提交按线形方式重新排到目标分支后面希望历史没有合并节点时我的习惯是功能分支的小改动用 Squash and merge大数据量分支用 Merge commitRebase 用得少因为对新手来说一旦冲突处理不好历史会被搞得很难看。3.3 Issue把需求、Bug 和任务都管起来Issue 不是简单的“bug 反馈邮箱”它是一个项目内部所有可讨论任务的总入口。需求可以开 IssueBug 可以开 Issue任务分配也可以开 Issue。成熟的仓库通常会有标签体系bug功能异常enhancement新功能或体验优化good first issue专门标记给新手入门的低难度任务help wanted需要外部帮助对开源新手来说good first issue是很好的切入点。很多项目维护者会主动把这类任务描述得非常详细并在一旁指导你只要能读代码、改一行测试就能完成第一次开源贡献。对团队项目来说用模板能显著减少无效问题。GitHub 允许在仓库里配置 Issue 模板让用户提交时按固定格式填写既省了你的沟通成本也让提问者自己先过一遍脑。还有一个很实用的小技巧你 commit 的消息里写Close #12push 并合并后GitHub 会自动关闭编号为 12 的 Issue。这比合并后手动回去关 Issue 高效得多。3.4 两种协作模式团队内和团队外团队内部通常用 Collaborators 模式仓库管理员把成员的 GitHub 账号添加为合作者大家直接往同一个仓库的不同分支 push然后通过 PR 合并。外部开源贡献用的是 Fork 模式普通路人没有仓库的 push 权限需要先在网页端点 Fork把这个仓库复制一份到自己的账号下然后 clone 自己这份、改动、push 回自己的仓库最后在原始仓库发一个跨仓库 PR。两者的核心差异在于“谁能直接改仓库”。团队内讲究快开源讲究安全。但无论哪种模式都建议在 Settings → Branches 里给 main 分支添加分支保护规则Require pull request reviews强制所有代码必须经过 PR 和 review 才能合并。这个规则起初会让团队效率看起来变低但从长远看能拦住大量低级错误。4. 发现一个好项目之后评估、下载、运行一条龙4.1 搜索语法比裸关键词高效得多GitHub 的搜索框远比你想的智能支持很多过滤语法。举个实际例子你想找“Python 写的最新聊天机器人项目”裸搜chatbot出来的结果可能几千条但用语法一过滤chatbot language:python stars:500 pushed:2025-01-01结果就精确得多只显示 Python 写的、star 超过 500、且近一年内还在更新的仓库。类似的常用语法还有org:某个组织名 # 只看某组织下的仓库 in:readme 关键词 # 关键词出现在 README 里 topic:机器学习 # 按主题标签过滤养成在 GitHub 站内直接检索的习惯比在外部搜索引擎里搜“GitHub xxx 推荐”再跳转过来要靠谱得多。外部搜到的所谓推荐贴往往已经滞后而 GitHub 站内的搜索结果是实时的。另外GitHub 的 Explore 页面有 Trending 趋势榜按天/周/月展示热门仓库每周花十分钟刷一下能让你保持对技术圈动态的感知。4.2 一个项目值不值得用别只看 Star 数Star 多只能说明曝光度高并不代表维护质量好。我给项目做评估时会同时看几个维度指标怎么看说明最近提交时间仓库首页的提交记录半年以上没更新大概率已经停更Issue 处理速度Issues 标签页的 Open/Closed 比例和最近回复长期无人回应的项目用起来风险高License仓库根目录是否有 LICENSE 文件没有许可证的代码法律上默认保留所有权利文档质量README 是否提供快速开始和示例好项目的 README 一定舍得花时间写维护者数量Contributors 页面单人项目维护者一旦没空整个项目就停摆一个很典型的判断某个老牌高 star 项目过去三年只有零星提交Issue 区积压了几百个没人回。这种项目你再怎么 star 它也比不上一个虽然才几百 star、但维护者每天都在回消息的活跃项目。4.3 把一个开源项目跑起来的通用三板斧很多人搜“GitHub 上的项目怎么运行”本质上是没搞懂一个规律绝大多数项目跑起来就是三板斧。第一步看 README。README 里的“Installation / Quick Start / Getting Started”段落几乎就是项目作者手把手教你怎么运行。找不到就去看docs目录。第二步装依赖。不同语言的依赖管理工具不同Node 项目用npm installPython 项目用pip install -r requirements.txtJava 项目用 Maven 或 Gradle。命令通常会在 README 里明确写出。第三步配置环境变量。很多项目需要数据库地址、API Key、端口号等配置。通常项目里会有一个.env.example文件你复制一份改成.env把里面缺的东西填上。这个环节卡住最多人问题往往不是代码跑不起来而是没给程序提供运行必需的参数。如果你只是临时想看项目效果优先找 Demo 链接或 Release 包。很多项目 README 里直接挂着在线 Demo你连本地环境都不用搭。如果是桌面软件或工具类项目去 Release 页面下载编译好的版本比 clone 源码再折腾构建省事得多。4.4 仓库特别大时怎么减少下载时间和体积大型仓库直接 clone 会非常痛苦因为 Git 会默认下载整个历史的所有版本。这里有三个官方支持的减负方案。浅克隆只拉最近一次提交git clone --depth1 仓库地址如果你的目的是看代码或基于最新代码开发这个方案足够用。稀疏检出只拉取目录的子集。适用于 monorepo 这种巨型仓库你只想看其中一个包git clone --depth1 仓库地址 cd 仓库目录 git sparse-checkout init --cone git sparse-checkout set packages/某个子目录大文件用 Git LFS。如果仓库里图片、模型文件、二进制文件很多项目一般会用 Git LFS 管理。普通 clone 不会把 LFS 文件全部拉下来而是先下载指针文件等你真正用到哪个文件时再按需拉取。最省流量的路径其实是不需要历史记录时直接到 Release 页面下载打包好的产物或点仓库首页的 Code 按钮选 Download ZIP得到的是当前快照而不带任何历史。5. 仓库体面三件套README、.gitignore 和开源许可证5.1 README 是门面也是最好的“使用说明书”README 决定了一个陌生人看到你仓库后的第一印象。我见过不少功能很硬核的项目因为 README 只写了几行字用户根本不知道这个项目能干什么、怎么装最终无人问津。一份负责任的 README 至少包含两块内容。给使用者看的项目一句话简介、功能截图或效果演示、安装方式、快速开始示例、常见问题。给贡献者看的开发环境搭建步骤、测试命令、代码风格约定、提交规范。核心判断标准很简单——“一个完全不了解项目的人只看 README 能不能把项目跑起来”。新手写 README 最容易犯的毛病是堆功能列表不写使用示例。实际上一个带输入输出示例的代码块比一百行功能描述都管用。如果你做的是开源库README 里的示例代码就是最好的广告。5.2 .gitignore不该提交的东西永远别提交.gitignore文件的作用是指定哪些文件不参与 Git 版本控制。需要忽略的文件分几类依赖目录node_modules、vendor、构建产物dist、build、target、本地配置.env、.idea、.vscode、操作系统产生的杂项.DS_Store、Thumbs.db。创建仓库时可以直接选一个官方维护的 .gitignore 模板GitHub 会根据你选择的语言自动生成合适的基础配置。如果发现文件已经被误提交了想停止跟踪但保留本地文件git rm --cached 文件名然后提交这个变更再更新 .gitignore后续就不会再被追踪。这里有一条红线密钥和密码永远不能提交。.env文件、token、密钥文件一旦被推到公开仓库等于是把钥匙挂在门口。即便你马上删除文件Git 历史里依然存在任何人都能翻出来。发生这种情况正确做法是立即去对应平台撤销旧密钥并重新生成新密钥而不仅仅是删文件。5.3 开源许可证没有 License就等于“保留所有权利”一个普遍误解是代码公开了别人就能随便用。实际上没有 License 的仓库法律上默认保留所有权利别人只能看不能合法复制、修改、分发。常见许可证的选择其实不复杂MIT最宽松。别人可以用你的代码做任何事包括闭源商用只要保留你的版权声明。适合绝大多数想被广泛使用的项目。Apache 2.0同样宽松额外包含专利授权条款大公司和涉及专利场景的项目更偏好它。GPL传染性较强。基于 GPL 代码的衍生作品也必须以 GPL 方式开源。适合你希望“用我代码的人也应该把改进开源出来”的场景。选择建议是想快速扩大社区影响力选 MIT 或 Apache 2.0特别在乎代码保持开源考虑 GPL。创建仓库时可以直接选 License 模板也可以之后往仓库根目录添加 LICENSE 文件。5.4 Release 和 Tag给用户一个稳定的版本入口很多新手只知道把代码推到 main 分支却不知道要给正式版本打标签。Tag 是 Git 层面的版本标记Release 是 GitHub 层面为这个 tag 附加的说明文档和二进制产物。当你的项目到达某个稳定节点时建议在网页端 Releases 页面创建一个新 Release填版本号建议遵循v1.0.0三段式语义化版本、写清本次变更、附上可执行文件或安装包。这样用户不需要 clone 源码直接下载 Release 里的产物就能用。维护 Release 也是项目长期健康度的体现。一个连续发布过多个版本、每版都有清晰 changelog 的仓库给人的信任感远高于只有一个光秃秃的 main 分支的仓库。6. 进阶玩法Actions、Codespaces、Copilot能省不少重复劳动6.1 GitHub Actions让 PR 自动跑测试在多人协作场景下最繁琐的环节不是写代码而是每次提交后重复做同一套验证工作安装依赖、跑格式检查、跑单元测试、构建产物。GitHub Actions 就是把这个流程沉淀成自动化工作流的官方方案代码推上去或 PR 创建时GitHub 会在云端容器里自动执行你定义好的任务。一个最基本的 Python CI 工作流在仓库根目录建.github/workflows/ci.ymlname: CI on: push: branches: [main] pull_request: jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-pythonv5 with: python-version: 3.12 - run: pip install -r requirements.txt - run: pytest这段配置的含义当有人向 main 分支 push 或创建任意 PR 时触发test任务任务跑在最新版 Ubuntu 容器里先检出代码、安装 Python 环境、安装依赖、执行 pytest。每个 PR 上都会显示检查通过或失败的结果维护者看到绿勾才敢合并。Actions 不要求你从零写所有东西。GitHub Marketplace 里有大量现成的 action 可以直接拼接常见操作像 checkout 代码、setup 语言环境、上传构建产物、发布到云服务器都有现成的轮子。6.2 Codespaces浏览器里的完整开发环境Codespaces 是 GitHub 官方提供的云开发环境。你不需要在本地安装任何依赖只要在仓库页面点 Code → Codespaces → Create codespace几秒钟后浏览器里就会出现一个完整的 VS Code 界面里面已经按仓库配置准备好了运行环境。它特别适合三个场景在新电脑上临时改代码、review 别人的 PR 时想实际跑一下代码、新人加入项目时不需要在本地折腾半天环境。如果你希望 Codespaces 启动时自动装好依赖可以在仓库里加一个.devcontainer/devcontainer.json文件里面声明用什么镜像、装哪些包比如一个 Node 项目的配置{ image: mcr.microsoft.com/devcontainers/universal:2, postCreateCommand: npm install, customizations: { vscode: { extensions: [esbenp.prettier-vscode] } } }Codespaces 不是要取代本地开发环境而是给你一个按需使用的弹性选项对临时贡献者特别友好。6.3 Copilot用了半年之后的真实体验GitHub Copilot 现在是很多编辑器标配的 AI 编程助手装官方插件并登录 GitHub 账号后就能在编辑器里触发补全。我用下来的体会是它写模板代码、单元测试、常用工具函数确实快但前提是你得给它足够的上下文。我的习惯是在函数上方用注释写清“输入是什么、输出是什么、边界条件有哪些”再让 Copilot 补全。比如# 解析用户上传的 csv 文件返回字段名列表和每行数据。 # 文件可能为空为空时返回空列表。它生成的代码明显比直接甩一句“写个 csv 解析器”要靠谱得多。Copilot 还能辅助 Code Review在 PR 里自动分析代码并给出优化建议相当于给代码审查加了一双“第二眼睛”但最终判断必须由人来做。凡是涉及并发、安全认证、资金计算的逻辑我都会逐行人工检查不让 AI 的输出蒙混过关。7. 高频报错排查认证失败、push 被拒、仓库过大怎么办7.1 认证失败和 “could not read Username” 的处理路径推送或克隆时看到Authentication failed或could not read Username for https://github.com第一件事不是换网络而是检查认证方式。赚钱的排查顺序是先git remote -v看远端地址是 HTTPS 还是 SSH。如果是 HTTPS 方式报认证失败一般是密码或 token 不对。GitHub 已经不支持只用账号密码推送代码必须使用 Personal Access Token 或 SSH Key。去 Settings → Developer settings → Personal access tokens 生成一个新 token然后替换原来的认证信息。如果是 SSH 方式报错先跑ssh -T gitgithub.com看到Hi 用户名说明 SSH 没问题问题出在仓库权限层面看到Permission denied则说明公钥没配好或不是当前账号的密钥。很多人不知道如何查看当前用户ssh -T gitgithub.com这条命令的输出会直接告诉你是哪个账号在连接配合.ssh/config文件可以做多账号切换但新手阶段不建议折腾太多保持一把密钥对应一个账号最简单。7.2 push 被拒! [rejected]背后在保护什么新手第一次遇到! [rejected] ... failed to push some refs往往会慌其实这条报错的含义很简单远端分支上存在你本地还没有的提交如果你强行 push远端历史会被你的本地历史覆盖掉Git 出于安全拒绝执行。正确的处理方式先拉取远端的最新改动再推送git pull --rebase origin main git push origin main这里我建议用--rebase而不是默认的 merge。区别在于rebase 会把你的本地提交“搬运”到远端最新提交之后历史呈一条干净的直线默认 merge 会生成一个合并提交多人频繁提交时历史会逐渐变得一团乱麻。如果你在功能分支上提交了很多条零散的 commitpull 之前还可以先把它们整理一下git rebase -i HEAD~NN 是你想整理的提交数量。这个命令会打开交互界面让你把多条提交合并成一条并统一修改提交信息。整理后再 pull --rebase、pushPR 的历史会非常清爽。另外如果你看到protected branch hook declined那不是报错而是分支保护规则在正常工作。main 分支被配置成必须走 PR 和 review 才能合并你的直接 push 被规则拦截。处理方式很简单本地分支 push 到同名功能分支然后去网页端创建 PR。7.3 仓库越来越大、克隆越来越慢怎么办一个仓库变得臃肿最常见的原因是把大文件提交进了 Git 历史。Git 每 clone 一次会下载整个历史里所有文件的所有版本。文件提交进去之后就算后来删了历史里依然存在仓库体积不会变小。如果项目还在早期且协作者不多最直接的办法是用git filter-repo或 BFG 重写历史把大文件从所有历史提交中彻底抹掉。但这条操作是破坏性的所有协作者都需要重新 clone 或强制更新本地副本。所以做之前一定要确认团队都能接受并且有完整备份。更推荐的做法是日常预防提交前看文件大小超过 50MB 的文件不要直接进 Git 仓库。图片、视频、模型文件、编译产物优先用 Git LFS 或对象存储。新手要 clone 大项目时用--depth1浅克隆先解决当下需求。如果你只是给别人提供下载最优雅的方案是把可执行文件挂在 Release 页面别人直接下载 Release 产物完全不需要碰 git 历史。7.4 页面不稳定、下载慢的自查顺序写这一节前先说清楚GitHub 是境外平台访问速度受多种因素影响本人在常规网络环境下基本能正常使用。如果你遇到网页打开缓慢、资源加载不完整的情况我建议按下面的顺序自查而不是去折腾一些来路不明的第三方工具。第一步确认本地基础网络是正常的。打开其他常用网站看是否都能正常访问。如果是整个网络都慢问题出在本地网络环境而不是 GitHub。第二步刷新本地 DNS 缓存。DNS 缓存过期可能导致域名解析异常。Windows 下用ipconfig /flushdnsmacOS 下用sudo dscacheutil -flushcache第三步查看 GitHub 官方状态页githubstatus.com确认平台本身没有发生故障。如果状态页显示所有系统正常那问题几乎都在本地网络环节。第四步排查本地安全软件或防火墙拦截。暂时关闭安全软件后重试如果能正常访问就把 GitHub 相关域名加到白名单里。第五步如果你是公司或校园网络环境可能存在网关策略限制这类情况最佳做法是咨询网络管理员了解是否有合规的访问途径。总体来说正规使用路径永远是官方网页、官方客户端和官方命令行。为了图快安装来路不明的所谓“下载工具”轻则无效浪费时间重则泄露账号凭据得不偿失。最后分享一个小习惯每周花一点点时间看看 GitHub 的 Trending 和 Explore 页面把 star 过的项目定期分类整理顺手清掉那些已经不维护的仓库。收藏一百个项目然后再也想不起来不如弄懂一个项目并把它真正跑起来。我第一次 push 成功时看着屏幕上刷出来的提交记录心里的感觉和第一次搭好个人博客是一样的。GitHub 值得你花时间你会越用越顺。