简介GitHub是目前最流行的代码托管与协作平台这份教程从新手入门讲到高级功能面向刚接触版本控制的开发者也适合已有一定经验但希望系统梳理工作流的用户。文档覆盖注册账号时的邮箱验证、账户类型选择到创建公开或私有仓库、克隆仓库到本地、用git add/commit/push完成提交与推送再到分支创建与合并、Pull Request代码审查、Issue问题跟踪等完整环节并给出了参与开源项目的实用建议涵盖代码质量管理与团队协作习惯的养成。资源包内仅含1个docx文档体积17KB采用图文步骤讲解命令与操作节点清晰可快速定位查阅。目前已有1331人学习下载作为日常开发的随查手册十分实用既能帮助读者理解Git核心命令与团队协作模式减少操作失误又能为关注开源的技术爱好者提供从旁观到贡献的路径参考有助于积累真实项目经验并扩大职业社交圈最终提升代码管理与协作开发效率无论是个人项目还是团队协作都能直接套用。1. 先说清楚GitHub 到底在解决什么问题如果你刚接触 GitHub多半会以为它就是个“存代码的网盘”。真用起来你会发现它解决的是三件网盘根本做不到的事第一代码的每一次变更都有完整记录谁改的、为什么改、改了哪几行随时可以回溯第二多人协作时不用再互相传压缩包分支、合并、审查这套流程把冲突变成可处理的工作项第三它不只是仓库还能自动跑测试、发布页面、检查依赖漏洞。这篇教程按“从新手入门到高级功能全掌握”的顺序把建仓库、写提交、做分支、走 PR、配 Actions 这些环节拆开讲每一段都给你可以直接照抄的命令和参数也把那些不讲清楚就一定会踩的坑提前标出来。适合刚入门的人也适合用了几个月但一直靠网页点来点去、想真正把协作流程理顺的开发者。2. 从零开始建仓库、配 SSH、让本地代码和 GitHub 连起来2.1 账号与仓库你做的第一个决定会影响后面所有事注册账号这一步没什么好展开的但创建仓库时的几个选项很多人是随手点的。默认仓库名、描述、Public 还是 Private、要不要 README、要不要 .gitignore 模板这几个选项目后会直接影响你的协作方式。Public 意味着任何人都能看见你的代码可以用你的仓库做 issue 提反馈也可以 fork 出去自己改。开源项目的起点往往就是一个 Public 仓库。Private 则适合公司项目或者还没想好要不要公开的代码。需要注意的是Private 仓库不等于“完全保密”如果你后来把协作者加进来对方可以看到完整历史和所有分支。初始化选项里我建议勾选 README 但不勾选 .gitignore。README 能让你 clone 下来第一眼就看到项目说明.gitignore 用 GitHub 内置模板生成反而容易出错因为模板太全会把该提交的文件也忽略掉。更稳的做法是本地建好项目后自己写一份精简的 .gitignore后面第 5 章会专门讲。还有一个容易忽略的东西是仓库的默认分支名。GitHub 现在默认是 main老项目常见的是 master。这本身不影响功能但如果你已经在本地用惯了 master或者公司内部规范要求用 main最好一开始就统一后期改默认分支要额外执行命令还要处理远端分支指向属于自己能避免的麻烦。2.2 配好 SSH不输密码的前提是一次性把密钥对生成对用 HTTPS 协议 clone 和 push 也不是不行但每次都要输用户名和 Token而 Token 长得很别扭复制粘贴容易出错。SSH 配好之后本地与 GitHub 之间的连接用密钥对完成身份认证push pull 都不再需要输入任何口令。生成密钥对的命令如下建议直接按这个参数走ssh-keygen -t ed25519 -C your_emailexample.com -f ~/.ssh/github_ed25519这条命令做了三件事-t ed25519指定用 Ed25519 算法它是目前 SSH 密钥里安全性和性能都更优的选择老教程里常见的 RSA 4096 还可以用但没必要再新建-C是加注释作用只是帮你区分这把钥匙是给哪个平台或哪台机器用的-f指定保存路径和文件名避免默认生成的 id_ed25519 和公司内部用的密钥混在一起。执行之后会在~/.ssh/下生成两个文件github_ed25519是私钥留在本机不要给任何人github_ed25519.pub是公钥内容可以安全展示。查看公钥内容cat ~/.ssh/github_ed25519.pub把输出的整行内容复制到 GitHub 网页右上角头像 → Settings → SSH and GPG keys → New SSH key粘贴保存。这里有个容易翻车的细节新生成但没被系统认出来的密钥不会在你第一次连接时自动被使用。需要在~/.ssh/config里写明这个密钥的用途Host github.com HostName github.com User git IdentityFile ~/.ssh/github_ed25519 IdentitiesOnly yesIdentityFile指定了连接 GitHub 时使用的私钥路径IdentitiesOnly yes的意思是不要尝试当前 ssh-agent 里加载的所有密钥只用这一把。如果你机器上有多个 SSH 密钥不加这行配置SSH 会逐个尝试GitHub 那边失败几次后会直接断开连接现象就是一直提示 permission denied。验证是否生效ssh -T gitgithub.com看到Hi username! Youve successfully authenticated就说明通了。这里有个玄学点很多人明明配好了第一次执行这条命令还是被问Are you sure you want to continue connecting这是正常的输入 yes 回车即可它会写入 known_hosts之后就不再问。2.3 第一次 push把本地仓库和远端仓库接上网SSH 配好后就可以建立本地与 GitHub 的关联了。假设你在 GitHub 上新建了一个空仓库不勾任何初始化选项本地已经有项目代码那么核心命令只有这一段cd my-project git init git add . git commit -m chore: initial commit git branch -M main git remote add origin gitgithub.com:username/my-project.git git push -u origin main逐条说git init把当前目录变成 Git 仓库git add .把所有文件加入暂存区注意这一步会把你没写 .gitignore 就产生的临时文件也加进去所以一定先确认目录里没有 node_modules、.env、dist 这类内容git commit提交并写提交信息建议格式用类型: 描述这个习惯越早养成越好git branch -M main把当前分支强制命名为 main忽略原来叫什么名字git remote add origin把远端的仓库地址登记成本地的 origin 别名最后git push -u origin main推送并绑定上游。-u参数值得单独记住它的全称是--set-upstream作用是将本地的 main 分支与远端的 main 建立跟踪关系。建立之后以后在 main 分支上直接输入git push和git pull就可以不用再重复写远端名和分支名。远端 URL 是 HTTPS 还是 SSH 写法决定你后续是否要反复输入认证信息。git remote add这一步改起来也容易用git remote set-url origin 新地址即可但最好第一次就直接用gitgithub.com:开头的 SSH 地址减少后续麻烦。第一次 push 常遇到的报错是failed to push some refs。这个报错大半是因为远端仓库里已经有文件比如创建仓库时勾了 README而本地仓库和自己没有共同的历史。处理方法分两种如果那些文件不需要直接在 GitHub 网页上删掉或忽略它然后重新 push如果需要保留就先git pull origin main --allow-unrelated-histories把两边历史合并再 push。--allow-unrelated-histories是专门用来合并两个没有共同祖先的仓库的参数不加这个参数 Git 会拒绝合并。3. 协作的起点分支、PR 与 Code Review 的完整闭环3.1 分支模型main 不是给你直接提交的单人开发时在 main 上直接提交没什么大问题但一旦有第二个人加入你就得认真对待分支。GitHub 上最常见的协作模型是main 分支始终保持可用状态任何新功能、bugfix 都从 main 切出一个新分支在分支上开发最后通过 Pull Request 合回 main。切分支的命令和它背后的机制值得讲清楚git checkout main git pull git checkout -b feature/refactor-login这里先回到 main 并拉取最新内容确保新分支是从最新代码切出来的。新手最容易犯的错是没先执行git pull直接在当前旧代码上切分支这样开发完提交 PR 后合并时就会冒出大量冲突。git checkout -b是“创建并切换分支”的组合命令等于git branch 分支名再加git checkout 分支名。分支名建议用类型/描述的格式比如feature/xxx、fix/xxx、docs/xxx。这条路子跑顺之后你会发现分支名本身就在描述一次变更的目的配合提交信息整个历史像一份可读的日志。开发过程中在分支上正常提交提交次数可以很多。这里有个惯例每个提交只做一件事。不要在一个提交里同时改功能代码、格式化代码、删掉一个旧文件这会给后面 Code Review 制造巨大的噪音。3.2 Pull Request 流程从创建到合并分支开发完成、提交也写好后先推送到远端再创建 PRgit push -u origin feature/refactor-login推送完成后GitHub 网页会在这个分支的旁边显出Compare pull request按钮点击进入创建页面。PR 的标题要写清楚“做什么”描述里写“为什么做、怎么做、测试情况”模板可以用仓库里的 PULL_REQUEST_TEMPLATE这个稍微后面再提。创建 PR 时有几个字段会直接影响体验Reviewer至少拉一个人来审查这比测试更早帮你发现设计问题。Assignee指派给自己或多个人表示这个 PR 谁对它负责。Labels打上bug、feature、WIP这些标签方便过滤。Milestone如果需要关联发布计划可以在里程碑里归类。PR 合并有三种方式它们的本质区别在于提交历史如何处理合并方式历史行为适用场景Create a merge commit保留分支全部提交产生一个合并提交需要完整保留每步变更的长期分支Squash and merge把分支所有提交压缩成一个提交功能逻辑整体成块历史要干净Rebase and merge把分支提交逐个变基到目标分支想要线性历史且保留每个提交我一般对开发分支用 Squash and merge因为一个 PR 内部那些fix typo、wip之类的中间提交没必要出现在主干历史里。但也有例外如果分支做的是一个独立的大功能且内部有清晰的阶段性提交保持原样用 Create a merge commit 更合理。Rebase and merge 用起来最“优雅”但冲突处理成本高适合熟练团队。3.3 Code Review 审什么四个维度比“看能不能跑”更重要PR 流程里最容易流于形式的就是 Review。很多人就是打开 diff 扫一眼看到没有语法错误就 Approve结果上线后出问题才回来翻历史。我一般按四个维度看第一看这次变更是否解决了它描述的问题。尤其是修 bug 的 PR先复现问题场景再对着改动判断逻辑是否真正闭合而不是只改了表面现象。第二看边界条件。比如改了一个日期格式化函数就要检查它是否处理了夏令时、0 点、空字符串传参。GitHub 的 diff 页面可以把代码展开到上下文耐心看上下文才能在思路上发现边界漏洞。第三看是否有不必要的“顺便修改”。格式化变化、重构无关代码、增删了没用的依赖这种噪音会污染历史。Review 时可以直接要求把这些内容挪到独立 PR 里。第四看自动化是否能替代人工。重复的逻辑检查写成测试比人肉 Review 可靠得多Review 时要求补单测、补集成测试这是提高仓库健康度最直接的方式。审查时发现小问题可以直接在 diff 的对应行上发起评论提交 review 时选择 Request changes这个 PR 就会被挡住。作者修改后 push 新提交reviewer 需要重新看一遍变更点。这个来回是协作中最高价值的环节不要因为在群里口头说一句“我看了没问题”就跳过 page review。4. 让 GitHub 帮你干活Actions、Pages 和自动化4.1 Actions 的组成workflow、job、step 三个层次GitHub Actions 是这个平台最值得花时间学的功能。它的价值在于把测试、构建、发布这些重复劳动全部放到云端每次 push 或 PR 都能自动跑一遍而且完全不用自己维护服务器。Actions 的配置文件放在仓库的.github/workflows/目录下一个 YAML 文件就是一个 workflow。先看一个前端项目最小可用的例子name: CI on: push: branches: [ main ] pull_request: branches: [ main ] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-nodev4 with: node-version: 20 cache: npm - run: npm ci - run: npm test这个文件里三个层次要分清。on是触发器这里写的是 main 分支收到 push 或 PR 时启动jobs定义一组任务每个 job 在独立的环境中运行steps是一个 job 内按顺序执行的步骤。actions/checkout把代码拉进运行环境没有它后面什么都做不了actions/setup-node安装指定版本的 Nodecache: npm会自动缓存依赖目录让后续运行更快npm ci按 lock 文件精确安装依赖和npm install的区别是它不会改动 lock 文件CI 里必须用它最后npm test跑测试。只要这个文件被推送到仓库GitHub 就会自动检测并执行。在 Actions 标签页能看到每次运行的日志哪一步失败会以红色标出进去看具体的报错信息即可。这里有一个新手常见误区workflow 里写不了cd到子目录再执行命令这种方式来进入子项目更可靠的做法是在每个run前加working-directory: 子目录或者用defaults.run.working-directory统一指定。4.2 Secrets 与环境变量不要把密码写进 yaml很多人第一个自动化 workflow 成功了就开始往 yaml 里填敏感信息。这里有一条红线必须记住push 到 GitHub 的代码和配置默认对所有能看到仓库的人可见Public 仓库是对所有人可见任何密钥、Token、口令都不能写进 workflow 文件。GitHub 提供了 Secrets 机制来存敏感值。网页端进入仓库 Settings → Secrets and variables → Actions在这里添加一个名为DEPLOY_TOKEN之类的变量然后在 workflow 里引用- name: Deploy env: DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }} run: ./deploy.sh${{ secrets.DEPLOY_TOKEN }}是模板表达式在 workflow 运行时才会被替换成实际值日志里会自动脱敏。注意环境变量在 step 级别声明时只在该 step 内可用如果是整个 job 都要用把它放到 job 级别的env里。还需要区分 Secrets 和普通变量。不需要保密的值比如分支名、超时时间、环境标识应该放到 Environment variables同样在 Settings 里配置但所有人可读。如果 workflow 里同时需要 variables 和 secrets写法是分别用${{ vars.XXX }}和${{ secrets.XXX }}引用。很多人没注意到它们分开存储导致同样的值存两份改一处漏一处这个细节在项目大了之后就会变成隐患。4.3 GitHub Pages 静态站点仓库即网站GitHub Pages 是 Action 之外另一个“零成本上线网站”的手段。它可以从仓库直接发布一个静态网站适合个人主页、项目文档、前端 demo。它最常见的使用方式有两种直接从分支发布或者用 Actions 构建后发布。从分支发布是最简单的方式。仓库 Settings → Pages → Build and deployment 选择 Deploy from a branch选 main 分支的/docs目录或仓库根目录保存后几分钟内就能通过https://用户名.github.io/仓库名/访问。这里有个坑如果你直接选根目录发布那么仓库里所有文件都会被公开到网站上包括任何不该公开的文件更合理的选择是只发布/docs目录或者在本地构建后只 push 构建产物目录。用 Actions 构建再发布可以把构建过程留在云端。一个 Vite 项目的 Pages 部署 workflow 可以在actions/configure-pagesv4和actions/deploy-pagesv4的组合下完成也可以直接用第三方 action但那样等于信任别人的代码需要在 Marketplace 上确认它维护活跃。Pages 适合的规模是静态页面和轻量 demo。不要试图把动态接口、数据库或服务端渲染跑在 Pages 上它不是服务器只是静态空间。4.4 Dependabot 和 Security 反馈让机器人盯着依赖GitHub 内置的安全功能可以直接打开。仓库 Settings → Code security and analysis把 Dependabot alerts 和 Dependabot security updates 都启用。启用后GitHub 会扫描你的依赖清单文件package.json、requirements.txt、Gemfile 等发现已知漏洞时会推送提醒严重漏洞甚至会自动生成修复 PR。这个功能是白送的“运维员工”但很多人忽略一个实际问题Dependabot 生成的 PR 一般只升级一个依赖数量一多就是一大批 PR 要处理。常见处理策略是每周固定一个时间统一处理这些 PR按优先级分批合。因为依赖更新是最容易产生破坏性变更的改动一旦升级版本引入兼容问题排查成本会明显高于功能代码。把升级依赖变成和功能开发一样的流程走分支、跑 CI、再合入 main。不要直接在 main 上点击合并 Dependabot PR除非仓库有足够的自动测试覆盖。5. 避坑新手几乎都会踩的五个 GitHub 坑5.1 clone 失败、push 超时不全是网络问题现象git clone卡住不动或者git push跑到一半报connection reset by peer再或者提示fatal: unable to access。原因这个要分两块看。第一块是本地网络确实不稳定企业内网、校园网这类环境经常会有这种随机断连第二块更隐蔽是你的 Git 全局代理配置或防火墙策略干扰了 SSH 协议的连接。很多人一遇到超时就去开代理或找镜像但其实是自己环境里的残留配置在捣乱。解决先确认网络状态然后检查 Git 配置git config --global --list看看有没有http.proxy或https.proxy这类配置如果发现把代理地址和当前网络对不上就先清理掉git config --global --unset http.proxy git config --global --unset https.proxySSH 协议排查类似检查~/.ssh/config里是否有多余的 ProxyCommand。如果本机一切正常但就是连 GitHub 失败常见做法是换一个网络环境做对比验证公司网络和手机热点各试一次能快速确定问题出在哪一端。另一个实用的招是给关键仓库配一个备用远端。比如把项目同时推到 GitHub 和国内的 Gitee日常以 GitHub 为主网络严重抖动时可以从 Gitee clone不让自己被单一平台卡死git remote add gitee gitgitee.com:username/my-project.git git push gitee main git pull gitee main5.2 代码提交到了 main想撤销却发现历史一团乱现象你本来想提交到 feature 分支结果在 main 上连着提交了三次才发现。网上一搜有人教git reset --hard HEAD~3一执行本地未提交的新代码也全都丢了。原因git reset --hard会把工作区直接回退到指定提交任何未提交的修改会被覆盖。这不是“撤销”命令是“丢弃”命令。新手把二混在一起是血泪教训里最高频的一条。解决如果你的提交已经 push 到远端了就别再用 reset 去改写历史。正确做法是用 revert 生成一个反向提交git revert HEAD~2..HEAD git push origin maingit revert不删历史而是加一个相反的分支提交把之前的变更抵消掉。远端 main 的提交记录会多一条Revert提交但这保证了历史和所有协作者的状态一致。如果本地还没有 push且确认本地没有未提交的修改想彻底抹掉这些提交才考虑git reset --hard。任何时候想用 reset 前执行一下git status看看有没有未提交的内容这是后悔药的标准前置检查。5.3 分支名大小写不一致GitHub 上的分支乱套了现象本地建了分支Feature/Loginpush 上去发现 GitHub 上还有一个feature/login两个分支并存提交越看越乱。原因Linux 和 macOS 的文件系统默认区分大小写GitHub 服务端在处理分支名时有一部分操作不区分两者标准不一致冒出看起来“重名”的分支。解决第一定规矩分支名一律小写用/做层级用-做单词分隔比如feature/user-profile第二如果已经出现重复分支在 GitHub 网页上删除一个再在本地用git fetch --prune清理过期记录。这属于团队规范问题靠命令解决不了根子规则写在 README 或 CONTRIBUTING 里最有效。5.4 .gitignore 没生效文件明明被忽略了还在提交现象写了.gitignore把node_modules/和.env加进去了但执行git add .之后git status里还是能看到这些文件。原因.gitignore只对尚未被跟踪的文件生效。如果某个文件在被加入.gitignore之前已经被git add或git commit过它就处于被跟踪状态忽略规则管不到它。解决把已跟踪的受控文件从 Git 索引中移除再让它被忽略git rm -r --cached node_modules git rm --cached .env--cached关键字的意思是只从 Git 的索引里移除不删除本地文件。执行完后把变更 commit 掉这些文件从此以后就不再被跟踪了。分类讨论一下写.gitignore时的选择node_modules/这种目录整体忽略没问题*.log这类通配符要注意粒度过宽会误伤.env是必须忽略的但如果你希望团队有一个模板参考就放.env.example到仓库里。5.5 不小心把大文件提交了仓库体积膨胀现象本地仓库越来越大clone 一次要等很久GitHub 网页上看到仓库大小显示几百 MB但其实源码只有几十 MB。原因有人把数据库文件、打包产物、视频、模型权重这类大文件直接 commit 进 Git 历史。最隐蔽的问题是就算后来删掉了这些文件它们还留在历史提交里Git 仓库大小不会变小。解决预防比治理划算。单文件超过 50MB 就要考虑是不是该进仓库超过 100MBGitHub 的硬限制会直接拒绝 push。需要管理大文件时用 Git LFSLarge File Storage而不是普通 Gitgit lfs install git lfs track *.psd git add .gitattributes git add file.psd git commit -m add design filegit lfs track会把文件类型写入.gitattributes记录这份仓库要按 LFS 规则处理哪些扩展名。如果仓库已经因为历史大文件膨胀修正手段是在本地用git filter-repo重写历史再强制推送。这属于高阶操作会改写所有协作者共享的历史请先与团队确认再对仓库做一个完整备份。6. 进阶玩法gh 命令行、搜索语法和项目体检6.1 用 gh 命令行把常见操作从网页搬回终端安装了 GitHub CLI命令名是gh之后很多管理类操作就不用再切窗口登录网页了。首次使用需要认证gh auth login执行后选择 GitHub.com再选 HTTPS按提示在浏览器完成授权。认证完就可以直接干活。创建 PR 是最常用的场景gh pr create --title feat: 重构登录流程 --body 详细说明变更内容 --reviewer username--reviewer可以直接指定审查人省去切到网页再找人这一步。查看当前分支已提交的 PR 状态gh pr status它会列出当前分支关联的 PR 是 open、draft 还是已经 merged比频繁刷新网页优雅得多。查看仓库概况gh repo view username/my-project个人觉得 gh 最有价值的不是省几次鼠标点击而是它把 GitHub 的操作平面和本地命令行统一了写脚本批量处理 issue、批量关 PR 成为可能——这才是它和网页端拉开差距的地方。6.2 用搜索语法精准找到代码段而不是仓库GitHub 的搜索走的不是百度式全文匹配。它的搜索语法很值得专门花半小时学。举个例子你想找一个“用 Vue 3 写拖拽排序”的代码参考普通搜索vue draggable会返回一堆仓库质量参差不齐。精准做法是language:TypeScript topic:vue draggablelanguage:限定代码语言topic:限定主题。更细致地搜代码片段filename:utils.ts user:username搜索范围、文件名的匹配规则可以和关键词自由组合。还有几个实用的限定符限定符作用stars:100仓库大于 100 星过滤低质项目path:src/指定代码在 src 目录下author:用户名按提交者过滤 commitcreated:2023-01-01只搜指定时间后创建的内容这套搜索对工作场景最大的价值是“老代码换新框架”时做技术调研你能直接读到别人已经落地的代码结构和提交记录比自己从零试错要快得多。6.3 给仓库做一次健康度体检最后分享一个我隔一段时间就会给仓库做的检查清单。它不是跑一个工具就能出结果的而是按几个问题过一遍确认仓库“健康”。第一看 README 是否写得像自己需要用时的样子。项目是干什么的、怎么装、怎么跑、怎么测这几段缺了一个新人进来可能要浪费一整天摸索。第二看是否有 CI 覆盖。没有 workflow 的仓库相当于没设防谁都能提交坏代码进来。第三看 issue 和 PR 的闭环率超过 90% 的 PR 被及时合入说明协作通畅堆积几百个没处理的 issue说明维护者已经失去对项目的掌控。第四看依赖有没有定期更新Security 页签有没有待处理的警报。做一次体检之后把发现的问题转成 1 到 3 个具体动作比如补一个 workflow、写一段 README、清一轮 issue。GitHub 是个工具真正让仓库活起来的是持续的小改进而不是某一次大调整。我用这个清单给不少新手团队收拾过仓库最后的那句提醒永远是同一句先学会看历史再学会改历史。提交信息写清楚分支名字起明白PR 描述别偷懒——这些不花什么时间但能给你自己省下大量翻历史、查旧账的时间。希望帮到你。本文还有配套的精品资源点击获取