简介面向Git初学者与有一定经验的开发者这份GitHub全流程教程覆盖账号注册、仓库创建与公开/私有设置、本地克隆、代码提交与推送、分支管理与合并并延伸至Pull Request、Issue等协作机制帮助建立规范的版本控制与项目管理流程。教程按操作顺序逐步讲解配合git clone、git add、git commit、git push、git branch、git merge等具体命令示例适合日常开发、团队协作和开源贡献场景也可作为新员工Git培训材料。资源为单个docx文档大小约17KB结构清晰下载后即可快速查阅。目前已有1331人学习边读边练可规避分支混乱、误推送等常见问题加速代码迭代与团队协同效率。1. GitHub 使用教程的起点先想清楚它到底是代码托管还是开发平台网上的 GitHub 使用教程多半只教你点鼠标注册、新建仓库、上传文件。但真正把 GitHub 用起来的人会发现它从来不是一个网盘而是一整套开发协作平台。如果你正在学 Git或者团队刚开始用 GitHub 协作这篇教程会从本地仓库怎么建、分支怎么管一路讲到 Actions 自动构建、Pages 发站点、Codespaces 云开发把整条链路走通。全文按新手的操作顺序排熟手可以直接跳到第 4 章和第 5 章看参数和踩坑。读完你会明白那些看起来“很专业”的仓库其实只是把分支、PR 和自动化工作流用对了。2. 建仓库到第一次 push本地、远程和 SSH 的最小闭环2.1 本地仓库、远程仓库和 Fork三个概念分清再动手很多人第一次接触 GitHub 就被三个概念绕晕本地仓库local repository、远程仓库remote repository、Fork。先把这个分清楚后面所有操作才不容易出错。本地仓库是你自己电脑目录里的.git文件夹它记录了这个项目所有的提交历史。git init之后这个目录就变成一个独立的版本库不联网也能提交。远程仓库是托管在 GitHub 服务器上的那一份它是团队共享的“真身”push把本地提交推上去pull把远程新提交拉下来。Fork 则是在 GitHub 服务器上复制别人的仓库到你自己账号下然后你从自己账号 clone 到本地这就是参与开源项目的标准路径。三个概念最常见的混淆点是 Fork 和 clone。Clone 是把远程仓库复制到本地Fork 是在云端复制一份仓库到你的账号。看别人的代码只需要 clone想参与贡献才需要 Fork。注意Fork 出来的仓库和原仓库是两条独立的线后面要定期同步上游否则提 PR 时冲突会非常痛苦。另外一个本地仓库可以挂多个远程地址Git 里叫 remote默认名字是origin你自己 fork 的仓库和upstream原仓库用git remote -v就能看到当前挂载了哪些远程地址。2.2 选 HTTPS 还是 SSH用 SSH 方式配置免密登录新建仓库时 GitHub 会给你两个远程地址格式HTTPS 和 SSH。新手很容易随便复制一个实际上这两者的后续体验差别很大。HTTPS 每次 push 都要验证身份虽然现在系统凭据管理器可以帮你缓存 token但遇到团队新人的电脑还是会被卡一下。SSH 则是配置一次后续长期免密日常开发我基本都用 SSH。生成 SSH 密钥的代码ssh-keygen -t ed25519 -C youexample.com # 一路回车即可默认保存到 ~/.ssh/id_ed25519 cat ~/.ssh/id_ed25519.pub # 复制输出的完整内容粘贴到 GitHub Settings - SSH and GPG keys - New SSH key参数说明-t ed25519指定用 ed25519 非对称加密算法它比旧的 RSA 密钥短而且安全性并不弱-C后面是注释建议填你注册 GitHub 的邮箱方便以后在多台机器上分辨哪把钥匙是谁的。配置完成后用下面这条命令验证ssh -T gitgithub.com # 第一次连接会询问是否信任主机指纹输入 yes # 看到 Hi username! Youve successfully authenticated 就代表成功这里有个实操经验id_ed25519.pub是公钥可以随便给id_ed25519是私钥绝对不能给任何人更不能打进仓库后面第 5 章会专门讲这个坑。多台电脑办公的场景每台机器生成一把独立的密钥在 GitHub 后台用不同的 Title 区分比如office-mac、home-pc比到处复制同一把私钥安全得多。如果你的公司电脑有统一的 SSH 配置要求那就按公司的规矩来个人项目另外配一把单独的密钥。2.3 最小闭环git init 到 git push -u origin main在 GitHub 网页上新建仓库时建议一个选项都不要勾让仓库保持完全空白。很多教程让你勾选 README、.gitignore、license结果本地仓库初始化后跟远程仓库历史对不上第一次 push 就被拒。正确做法是先建空仓库拿到远程地址再从本地推上去。本地操作的最小闭环git init # 当前目录变成 Git 仓库 git add . # 把所有改动加入暂存区 git commit -m first commit # 生成第一个提交 git branch -M main # 把默认分支改名为 main git remote add origin gitgithub.com:你的用户名/仓库名.git git remote -v # 确认远程地址是否正确 git push -u origin main # 首次推送并绑定上游引用这段命令的逻辑要说一下git init之后当前目录有了.git但没有任何提交git add .是把所有文件放入暂存区这一步最容易出错add .会把你还没意识到的.env、大文件、临时目录全带进去第一次建议先git status看看再决定 add 什么。git commit必须有消息团队习惯上加feat:、fix:、docs:这类前缀后续生成 changelog 会非常省事。git branch -M main是强制把分支从master改名成main原因是 Git 早期版本默认分支叫 masterGitHub 默认用 main两边对齐能少很多麻烦。git remote add origin把本地仓库关联到远程origin只是约定俗成的名字你甚至可以叫它github但没必要。用git remote -v检查地址是最便宜的后悔药很多人 push 到别人仓库就是因为这里看漏了一眼。最后的git push -u origin main-u参数把本地 main 分支和远程 main 分支绑定成上下游关系之后直接git push和git pull就不用再带参数。如果远程仓库不是空的比如勾选了 READMEpush 会报failed to push some refs。这种情况原因是本地和远程的历史没有交集解决方法是先git pull origin main --rebase把远程 README 拉下来和你的第一次提交合在一起再 push。这里绝对不要用git push -f强推覆盖第一次提交就把远程记录砸掉后面团队的协作历史会非常难看。3. 分支协作与 Pull Request多人开发的完整动线3.1 保护 main 分支为什么开发分支不能直接推主分支单人开发时直接往 main 推没什么感觉一旦两个人以上协作直接在 main 上提交就会迅速失控今天 A 推了一个改动明天 B 不知道上下文又推了一个改动出问题时根本没法定位是谁、在哪个 PR 引入了故障。所以多人协作的第一步不是写代码而是把 main 分支保护起来。保护分支的做法在 GitHub 上是 Settings - Branches - Add branch protection ruleBranch name pattern 填main然后把Require a pull request before merging打开approvals 数量小团队设 1 个就够再勾选Block force pushes。这样任何人都不能直接 push 到 main所有改动必须走 PR至少一个 review 通过才能合并。这个规则背后的道理很简单main 分支代表的是“随时可以发布”的状态。如果 release 出问题了回滚一个 PR 是明确的操作回滚一堆直接提交则变成考古。小团队经常觉得走 PR 流程太重我的经验是哪怕只有两个人也值得把 main 保护起来。不保护 main等于把自己的工作台给别人留了一个随时能改乱的后门。配置保护规则只需要一次但省下来的排查时间远超过那点流程成本。3.2 一次标准 PR 的全流程从 checkout -b 到 Review 合并Pull Request 是 GitHub 协作的核心闭环开发者从最新的代码拉出一个分支做自己的改动推上去请求把这个分支合入 main经过 review 后合并。一次标准的 PR 操作如下git fetch upstream # 先拉取上游仓库最新提交 git checkout -b feature/login upstream/main # 从最新 main 创建功能分支 git add . git commit -m feat: 增加登录页 # 提交你的改动 git push -u origin feature/login # 推到自己的远程仓库推送完成后GitHub 仓库页会自动出现一个黄色横幅“Compare pull request”点进去选择 base 分支main和 compare 分支feature/login然后填写 PR 标题和描述。描述不要写“做了个功能”这种废话要写清楚为什么做、改了什么、自测结果如何开源项目通常还会要求列出测试步骤。Reviewer 在 Files changed 页面看 diff可以逐行留 commentapprove 或 request changes。你收到修改意见后在本地继续 commit 再 pushPR 会自动更新不需要重新建。GitHub 合并 PR 时有三个选项很多人一直没分清。Create a merge commit 保留这个分支上所有 commit历史完整但 main 分支图上会有大量交错的线Squash and merge 把所有 commit 压缩成一条合并到 main历史干净适合功能分支上堆了几十个无意义的小提交Rebase and merge 把分支的 commit 一个个重放到 main 头部历史线性但每个 commit 保留。我的默认建议是团队统一用 Squash and merge只有安全审计类改动才需要用 Rebase and merge 保留逐 commit 的痕迹。这些默认选项可以在 Settings - General - Allow squash merging 里配置。3.3 同步上游与解决冲突rebase 和 merge 的取舍Fork 出来的仓库会随着原仓库的更新不断落后提 PR 之前必须先把上游最新代码合并进来。同步上游的标准操作git remote add upstream https://github.com/原作者/仓库名.git git fetch upstream git checkout main git merge upstream/main git push origin maingit fetch upstream只是把上游的提交下载到本地不会动你当前的工作区它只是更新了一个叫upstream/main的远程追踪指针。git merge upstream/main才真正把上游主线的历史合并进你的本地 main最后push同步到你自己的 GitHub 仓库。这一步做完你 Fork 的仓库就和原仓库对齐了。如果冲突出在你的功能分支上有两种处理方式。一种是 merge直接在功能分支上把upstream/main合并进来简单但会把上游的主干历史混进你的分支PR 的 diff 里会掺杂大量别人的改动。另一种是 rebase把你功能分支的所有提交“重放”到上游 main 的最新提交之后历史干净冲突也更好解决。我在处理个人功能分支时的操作是git checkout feature/login git fetch upstream git rebase upstream/main # 若报冲突打开冲突文件搜索 HEAD保留需要的代码 git add 冲突文件路径 git rebase --continue # 全部解决后因为提交哈希已变化push 需要带 lease 参数强推 git push --force-with-lease origin feature/login--force-with-lease和--force的区别非常关键--force是无条件覆盖远程分支有把队友刚推的提交冲掉的风险--force-with-lease只有当远程分支还停留在你上次 fetch 的状态时才允许覆盖否则拒绝这能在 rebase 后安全地更新 PR。记住一句原则公共分支绝不 rebase个人 feature 分支 rebase 后强推一定要用带lease的版本。4. 高级功能落地Actions 自动化、Pages 部署和 Codespaces 云开发4.1 GitHub Actions 最小工作流push 后自动测试并上传构建产物GitHub Actions 是 GitHub 官方内置的 CI/CD 工具。你只要在仓库里放一个.github/workflows/xxx.yml文件GitHub 检测到 push、PR、打 tag、定时器这些事件后就会自动在虚拟机里执行你定义好的工作流。这个功能对新手来说是最容易见到效果的进阶功能代码一推上去自动装依赖、跑测试、做构建省掉本地手动验证的重复劳动。一个 Node 项目的最小工作流文件name: CI on: push: branches: [main] pull_request: branches: [main] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-nodev4 with: node-version: 20 cache: npm - run: npm ci - run: npm test - run: npm run build - uses: actions/upload-artifactv4 with: name: dist-${{ github.sha }} path: dist这个文件里的每个字段都要说清楚on定义了触发器这里指的是 push 到 main 和对 main 的 PR 都会触发还可以加workflow_dispatch支持手动在 Actions 页面点击运行。jobs下面可以写多个任务默认并行执行如果后续构建的 job 依赖测试 job就在后面加一行needs: build。runs-on: ubuntu-latest指定 runner 的操作系统GitHub 托管 runner 还支持windows-latest和macos-latest没有特殊需求用 ubuntu 就够了。actions/checkoutv4是最常用的官方 action作用是把仓库代码检出到 runner 的工作目录几乎每个工作流的第一个 step 都是它。actions/setup-nodev4用来装 Nodewith.node-version: 20指定版本cache: npm让 Actions 缓存 npm 依赖下次跑能省不少时间。注意这里的v4是 action 的 tag 版本号不要用main这类分支引用别人仓库更新可能被带到不受控的版本。npm ci和npm install的区别要讲清楚ci严格按package-lock.json安装先删 node_modules 再装干净、快速、可复现CI 环境就应该用ci而不是install。最后upload-artifact把构建产物的 dist 目录打包上传可以在 Actions 页面直接下载name里用${{ github.sha }}是当前提交的哈希避免多次运行产物互相覆盖。Actions 的免费额度对个人项目基本够用私有仓库的免费分钟数会比公开仓库少一些。另外注意一个安全设计fork 来的 PR 默认无法读取仓库的 secrets这是为了防止有人通过恶意 PR 偷密钥不要在 Actions 设置里强行关掉这个保护。4.2 GitHub Pages个人主页和项目文档的免费站点GitHub Pages 可以把仓库里的静态文件直接变成一个公开网站最适合个人主页、项目文档、前端 demo 这类场景不需要单独买服务器和域名。配置路径有两条按你的项目类型选择。最简单的方式是分支部署仓库 Settings - Pages - Source 选择Deploy from a branch分支选 main、目录选/root只要 main 根目录里有index.html每次 push 后 GitHub 会自动把代码发布成站点。用户名.github.io 这种个人主页仓库默认就是这种方式一个 HTML 文件加几次提交个人介绍页就上线了。如果项目是 Vite、VuePress、Jekyll 这类需要构建的站点就得用 Actions 部署。构建完的产物在 dist 目录需要通过 workfl: 上传并发布name: Deploy to Pages on: push: branches: [main] permissions: contents: read pages: write id-token: write jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-nodev4 with: node-version: 20 - run: npm ci - run: npm run build - uses: actions/upload-pages-artifactv3 with: path: dist deploy: needs: build runs-on: ubuntu-latest environment: name: github-pages url: ${{ steps.deployment.outputs.page_url }} steps: - id: deployment uses: actions/deploy-pagesv4这个工作流里最容易漏的是permissions块pages: write是给 workflow 写入 Pages 的权限id-token: write是 GitHub OIDC 认证需要两个都缺的话 deploy 阶段会报 403很多人第一次配置都卡在这里。environment里url字段用了steps.deployment.outputs.page_url这是一个从 deploy-pages action 的输出里取值的方法可以在 Actions 运行页直接看到发布后的站点地址。还有一个高频坑是path写错Vite 构建产物默认在 distVuePress 默认在src/.vuepress/distHexo 在 public先本地构建一次确认产物目录再填这个值。4.3 Codespaces把仓库变成开箱即用的云开发环境Codespaces 是 GitHub 官方提供的云端开发环境不需要在本地安装任何 IDE仓库页面点 Code 按钮 - Codespaces - Create codespace on main几秒钟就能打开一个浏览器里的 VS Code环境按照仓库配置自动装好依赖。适合的场景是新成员加入项目不想花半天装环境、你临时要改一个从未接触过的仓库、或者演示项目时环境崩了现场救火。Codespaces 的环境配置放在仓库的.devcontainer/devcontainer.json文件里把这个文件提交到仓库所有人打开同一个仓库的 Codespaces 就会得到同样的开发环境{ name: Node.js 20 workspace, image: mcr.microsoft.com/devcontainers/javascript-node:20, features: { ghcr.io/devcontainers/features/docker-in-docker:2: {} }, customizations: { vscode: { extensions: [ esbenp.prettier-vscode, dbaeumer.vscode-eslint ] } }, postCreateCommand: npm install }关键参数解释image指定基础镜像这里用的是微软官方 devcontainers 镜像里面预装了 Node 20features是可选组件docker-in-docker让容器里还能跑 Dockercustomizations.vscode.extensions声明打开环境时自动安装的 VS Code 扩展新成员一进来自动装好 Prettier 和 ESLintpostCreateCommand在容器创建后执行通常会跑npm install或者初始化脚本。修改 devcontainer.json 后要提交到仓库再重新创建 Codespaces 才能生效。Codespaces 是按运行时长计费的账号有免费额度约满后个人用户需要升级到付费方案或企业计划。它不是一个可以一直挂着的免费云电脑用完记得关掉这个费用陷阱我在实际项目里见过不少人踩。5. GitHub 使用避坑clone 慢、误提交和 PR 冲突的 5 条血泪经验5.1 clone 大仓库失败或卡住浅克隆与镜像下载的取舍现象git clone一个比较大的仓库时进度停在 99% 报错常见错误是RPC failed; curl 56 OpenSSL SSL_read: Connection was reset, errno 10054或者remote ended unexpectedly。再点一次还是卡在同一个位置git 不会自动断点续传。原因仓库历史里面积累了大量二进制文件或者某个提交本身特别大一次要传输的 blob 太多网络长时间占用后被重置。这类问题在 clone 初期很难察觉因为进度条前面看不出异常99% 时崩是最折磨人的。解决如果你只需要最新代码而不需要全部历史用浅克隆git clone --depth 1 --branch main gitgithub.com:user/repo.git # --depth 1 只拉取最近一次提交体积可以减少一个数量级 # 之后确实需要历史时再执行 git fetch --unshallow 补全如果连仓库都很大但只想要其中某个目录配合 sparse-checkoutgit clone --filterblob:none --sparse gitgithub.com:user/repo.git cd repo git sparse-checkout set src docs--filterblob:none的意思是提交和目录树的元数据照常下载实际文件内容按需获取--sparse让工作区先只保留根目录之后再通过sparse-checkout set按需把需要的目录检出到本地。 另外一个常见场景是下载 Release 里的压缩包几百 MB 的 zip 从 GitHub 页面直接下载容易中断。这种场景可以找当前可用的 github 镜像站点把 Release 下载链接里的域名换成镜像域名再下载。镜像站点是第三方维护的可靠性参差不齐今天能用明天失效很正常下载完一定要核对一下 SHA256 校验值再接进项目里。顺便说一句别把镜像域名写死在脚本里这是明显的脆弱依赖。5.2 误提交超过 100MB 的文件如何让 push 不再被拒现象git push时被服务器直接拒绝报错里写着File big_model.zip is 104.38 MB; this exceeds GitHubs file size limit of 100 MB。这个限制是 GitHub 对单个文件的硬性规定本地 commit 已经生成了但推送就是过不去。原因开发时把模型文件、数据集、安装包这类体积大的东西git add .带了进去而 GitHub 单文件不能超过 100MB整个仓库也建议不要超过 1GB。就算你用的是 Git LFS免费额度也只有 1GB 存储和每月 1GB 的带宽超出就要付费。解决如果 commit 还没推上去先把这个文件从暂存区摘出来git rm --cached big_model.zip echo big_model.zip .gitignore git commit -m chore: remove large filegit rm --cached只会把文件从 Git 索引删除不会动你磁盘上的原文件配合.gitignore让它以后不再被误加。但如果这个 commit 已经推上去了本地删掉没用远程历史里还躺着这个大文件必须重写历史。重写历史目前最省力的工具是 git filter-repo它是 Python 包先pip install git-filter-repo再执行git filter-repo --path big_model.zip --invert-paths # --path 指定要删除的文件--invert-paths 表示保留除它之外的所有内容这个命令会把所有分支、所有提交历史里这个文件的记录全部清掉然后由于安全考虑会把 remote origin 移除需要重新git remote add origin。重写历史后所有协作者都必须重新 clone那些还拿着旧仓库副本的人如果继续 push等于又把大文件的历史带了回来这需要团队统一行动。以后想往仓库放真正的二进制大件规范做法是用 Git LFS而不是硬塞仓库。5.3 密钥和 .env 被推上去了先删历史再轮换密钥现象push 完打开 GitHub 仓库发现.env文件老老实实躺在文件列表里里面是你的数据库密码、API Key或者没这么显眼是某种日志文件里打了一行AWS_ACCESS_KEY_IDAKIA...。这个现象在刚学 Git 的人身上高发。原因git add .把所有文件都带进去了而.env、config/secrets.yml这类文件默认没有被忽略。很多人以为私有仓库无所谓实际上 Git 仓库里一旦出现过密钥每个 clone 过的人本地都留着一份副本私有仓库不等于不泄露。解决处理顺序非常关键顺序错了等于白忙。第一步立刻去相关服务商把密钥吊销或轮换这是最重要的动作因为你后面花时间去清理历史的时候密钥一直在暴露状态。第二步才是清理仓库历史git filter-repo --path .env --invert-paths --force # --force 是因为 filter-repo 要求学生工作区干净先提交当前改动再用 git remote add origin gitgithub.com:user/repo.git git push origin --force --all git push origin --force --tags第三步确认所有分支、所有 tag 都不再包含该文件GitHub 仓库页搜索这个文件名确认已经找不到。最后一步把本地、同事手里所有可能复制过这个密钥的位置都轮换掉。GitHub 的 secret scanning 会对公开仓库里的已知格式 token 发警告但它只是提醒不会替你清理。真正治本的习惯是第一次git add之前先git status看一眼或者从一开始就把.env加进全局.gitignore。5.4 PR 显示冲突但本地没改同步上游分支的正确顺序现象GitHub 的 PR 页面显示 “This branch has conflicts”你切回本地分支试着 merge 一下 main提示一切正常没有冲突。这是很多人第一次看到 PR 冲突时都会懵的场景。原因GitHub 上 PR 的冲突检测不是拿你本地分支去比而是拿你推在远程的分支和当前目标分支在服务器上的最新状态做对比。目标分支在你 push 之后又被别人合并了别的功能这些新代码和你的改动冲突了。你本地没 merge 过这些新提交自然测不出来。解决把上游最新代码同步到你的功能分支重新解决冲突再推上去git checkout feature/login git fetch upstream git rebase upstream/main # 冲突文件里搜索 HEAD手动整理成最终代码 git add 冲突文件 git rebase --continue git push --force-with-lease origin feature/login这里用 rebase 而不是 merge是因为 rebase 会把你的提交重放到上游最新点PR 的 diff 干净只有你自己改过的东西如果用 merge 同步你的分支历史里会混入上游的提交PR 的 diff 会变成“你分支和 main 的全量差异”reviewer 看到一堆不属于你的改动非常痛苦。注意如果你参与的是别人仓库的 Fork同步源是upstream/main而不是origin/mainorigin指向的是你自己 Fork 的仓库这个概念搞混的话 fetch 了半天同步了个寂寞。5.5 github打不开或页面资源加载失败从 DNS 到镜像站的排查顺序现象github.com 主站能打开但头像、raw.githubusercontent.com 的图片加载不出来或者整个页面转圈几秒后报错也可能是昨天还能开今天突然打不开电脑重启后恢复了第二天又不行。这个现象在开发社区里非常高频很多人的第一个 GitHub 使用教程就是从这个问题开始的。原因这类问题大多不在 GitHub 本身而在域名解析环节。本地 DNS 缓存可能存了过期的解析结果或者当前网络环境使用的 DNS 服务器给出的解析指向了延迟很高的节点。页面资源走的是 CDN仓库代码走的是 SSH 或 HTTPS两者链路不同所以经常出现“页面开不了但 clone 正常”的混合状态。解决按顺序来不要上来就改一堆配置。第一步刷新本地 DNS 缓存Windows 执行ipconfig /flushdnsmacOS 执行sudo dscacheutil -flushcache让系统重新发起域名解析。第二步换公共 DNS把系统 DNS 改成223.5.5.5和119.29.29.29这是相对干净且响应快的公共解析服务影响范围小随时可以改回来自动获取。第三步如果只是下载 Release 里的资源文件走第 5.1 节说的 github 镜像站点下载完成后核对 SHA256 再使用。如果以上都试过仍然频繁失败可以考虑给常用域名配置 hosts 映射。具体做法是用nslookup github.com查询当前可用的 IP把它固定到系统 hosts 文件里跳过 DNS 解析直接连接。注意这种方式的有效期不稳定因为 GitHub 的 IP 节点会调整hosts 里配的 IP 过几天可能就不再好用只适合临时应急不建议提交到配置文件里长期依赖。这类网络症状需要按页面、clone、Release 下载分别定位别把问题都归到一个原因上分开排查才找得准。6. 把 GitHub 用成工作台模板仓库、Issue 标签和 CLI 提效高阶用户和普通用户的区别往往不在会不会敲命令而在有没有把 GitHub 从“代码存放处”变成开发流程的一部分。这里分享三个我现在新项目必做的动作。第一是模板仓库。在仓库 Settings 里勾选Template repository这个仓库就变成模板源新建项目时在 GitHub 首页点Use this template按钮直接复制整套目录结构、CI 配置、License 到新仓库省得每次从零搭脚手架。新项目第一步永远是先选模板而不是git init。第二是 Issue 规范化在仓库里建.github/ISSUE_TEMPLATE/bug_report.yaml给 bug 报告定义问题描述、复现步骤、环境信息这些必填字段配上 bug、enhancement 这类 label收到的 Issues 质量会高很多。第三是用 GitHub 官方 CLI 把重复操作变成一条命令gh repo create myapp --template my-org/go-starter --public gh pr create --title feat: 实现登录 --body Closes #12 --fill gh pr merge --squash --delete-branchgh是 GitHub 官方命令行工具登录一次之后可以把网页上的操作全在终端里完成。--template参数从模板仓库初始化新项目Closes #12是 GitHub 支持的自动闭合关键字PR 合并时对应 issue 自动关闭--squash合并后--delete-branch把远程分支一起清掉保持仓库整洁。验证一套流程是否规范我会看三个指标PR 合并后 issue 是否自动关闭、main 历史是否干净线性、分支列表里有没有堆积的 feature 分支。我现在的习惯是把这些命令写成脚本放进团队的工程化文档里新人照着跑一遍就能完成一次标准交付比自己点网页统计多了。希望帮到你。本文还有配套的精品资源点击获取
GitHub使用教程：从Git SSH到Actions自动化，分支PR云开发全攻略
简介面向Git初学者与有一定经验的开发者这份GitHub全流程教程覆盖账号注册、仓库创建与公开/私有设置、本地克隆、代码提交与推送、分支管理与合并并延伸至Pull Request、Issue等协作机制帮助建立规范的版本控制与项目管理流程。教程按操作顺序逐步讲解配合git clone、git add、git commit、git push、git branch、git merge等具体命令示例适合日常开发、团队协作和开源贡献场景也可作为新员工Git培训材料。资源为单个docx文档大小约17KB结构清晰下载后即可快速查阅。目前已有1331人学习边读边练可规避分支混乱、误推送等常见问题加速代码迭代与团队协同效率。1. GitHub 使用教程的起点先想清楚它到底是代码托管还是开发平台网上的 GitHub 使用教程多半只教你点鼠标注册、新建仓库、上传文件。但真正把 GitHub 用起来的人会发现它从来不是一个网盘而是一整套开发协作平台。如果你正在学 Git或者团队刚开始用 GitHub 协作这篇教程会从本地仓库怎么建、分支怎么管一路讲到 Actions 自动构建、Pages 发站点、Codespaces 云开发把整条链路走通。全文按新手的操作顺序排熟手可以直接跳到第 4 章和第 5 章看参数和踩坑。读完你会明白那些看起来“很专业”的仓库其实只是把分支、PR 和自动化工作流用对了。2. 建仓库到第一次 push本地、远程和 SSH 的最小闭环2.1 本地仓库、远程仓库和 Fork三个概念分清再动手很多人第一次接触 GitHub 就被三个概念绕晕本地仓库local repository、远程仓库remote repository、Fork。先把这个分清楚后面所有操作才不容易出错。本地仓库是你自己电脑目录里的.git文件夹它记录了这个项目所有的提交历史。git init之后这个目录就变成一个独立的版本库不联网也能提交。远程仓库是托管在 GitHub 服务器上的那一份它是团队共享的“真身”push把本地提交推上去pull把远程新提交拉下来。Fork 则是在 GitHub 服务器上复制别人的仓库到你自己账号下然后你从自己账号 clone 到本地这就是参与开源项目的标准路径。三个概念最常见的混淆点是 Fork 和 clone。Clone 是把远程仓库复制到本地Fork 是在云端复制一份仓库到你的账号。看别人的代码只需要 clone想参与贡献才需要 Fork。注意Fork 出来的仓库和原仓库是两条独立的线后面要定期同步上游否则提 PR 时冲突会非常痛苦。另外一个本地仓库可以挂多个远程地址Git 里叫 remote默认名字是origin你自己 fork 的仓库和upstream原仓库用git remote -v就能看到当前挂载了哪些远程地址。2.2 选 HTTPS 还是 SSH用 SSH 方式配置免密登录新建仓库时 GitHub 会给你两个远程地址格式HTTPS 和 SSH。新手很容易随便复制一个实际上这两者的后续体验差别很大。HTTPS 每次 push 都要验证身份虽然现在系统凭据管理器可以帮你缓存 token但遇到团队新人的电脑还是会被卡一下。SSH 则是配置一次后续长期免密日常开发我基本都用 SSH。生成 SSH 密钥的代码ssh-keygen -t ed25519 -C youexample.com # 一路回车即可默认保存到 ~/.ssh/id_ed25519 cat ~/.ssh/id_ed25519.pub # 复制输出的完整内容粘贴到 GitHub Settings - SSH and GPG keys - New SSH key参数说明-t ed25519指定用 ed25519 非对称加密算法它比旧的 RSA 密钥短而且安全性并不弱-C后面是注释建议填你注册 GitHub 的邮箱方便以后在多台机器上分辨哪把钥匙是谁的。配置完成后用下面这条命令验证ssh -T gitgithub.com # 第一次连接会询问是否信任主机指纹输入 yes # 看到 Hi username! Youve successfully authenticated 就代表成功这里有个实操经验id_ed25519.pub是公钥可以随便给id_ed25519是私钥绝对不能给任何人更不能打进仓库后面第 5 章会专门讲这个坑。多台电脑办公的场景每台机器生成一把独立的密钥在 GitHub 后台用不同的 Title 区分比如office-mac、home-pc比到处复制同一把私钥安全得多。如果你的公司电脑有统一的 SSH 配置要求那就按公司的规矩来个人项目另外配一把单独的密钥。2.3 最小闭环git init 到 git push -u origin main在 GitHub 网页上新建仓库时建议一个选项都不要勾让仓库保持完全空白。很多教程让你勾选 README、.gitignore、license结果本地仓库初始化后跟远程仓库历史对不上第一次 push 就被拒。正确做法是先建空仓库拿到远程地址再从本地推上去。本地操作的最小闭环git init # 当前目录变成 Git 仓库 git add . # 把所有改动加入暂存区 git commit -m first commit # 生成第一个提交 git branch -M main # 把默认分支改名为 main git remote add origin gitgithub.com:你的用户名/仓库名.git git remote -v # 确认远程地址是否正确 git push -u origin main # 首次推送并绑定上游引用这段命令的逻辑要说一下git init之后当前目录有了.git但没有任何提交git add .是把所有文件放入暂存区这一步最容易出错add .会把你还没意识到的.env、大文件、临时目录全带进去第一次建议先git status看看再决定 add 什么。git commit必须有消息团队习惯上加feat:、fix:、docs:这类前缀后续生成 changelog 会非常省事。git branch -M main是强制把分支从master改名成main原因是 Git 早期版本默认分支叫 masterGitHub 默认用 main两边对齐能少很多麻烦。git remote add origin把本地仓库关联到远程origin只是约定俗成的名字你甚至可以叫它github但没必要。用git remote -v检查地址是最便宜的后悔药很多人 push 到别人仓库就是因为这里看漏了一眼。最后的git push -u origin main-u参数把本地 main 分支和远程 main 分支绑定成上下游关系之后直接git push和git pull就不用再带参数。如果远程仓库不是空的比如勾选了 READMEpush 会报failed to push some refs。这种情况原因是本地和远程的历史没有交集解决方法是先git pull origin main --rebase把远程 README 拉下来和你的第一次提交合在一起再 push。这里绝对不要用git push -f强推覆盖第一次提交就把远程记录砸掉后面团队的协作历史会非常难看。3. 分支协作与 Pull Request多人开发的完整动线3.1 保护 main 分支为什么开发分支不能直接推主分支单人开发时直接往 main 推没什么感觉一旦两个人以上协作直接在 main 上提交就会迅速失控今天 A 推了一个改动明天 B 不知道上下文又推了一个改动出问题时根本没法定位是谁、在哪个 PR 引入了故障。所以多人协作的第一步不是写代码而是把 main 分支保护起来。保护分支的做法在 GitHub 上是 Settings - Branches - Add branch protection ruleBranch name pattern 填main然后把Require a pull request before merging打开approvals 数量小团队设 1 个就够再勾选Block force pushes。这样任何人都不能直接 push 到 main所有改动必须走 PR至少一个 review 通过才能合并。这个规则背后的道理很简单main 分支代表的是“随时可以发布”的状态。如果 release 出问题了回滚一个 PR 是明确的操作回滚一堆直接提交则变成考古。小团队经常觉得走 PR 流程太重我的经验是哪怕只有两个人也值得把 main 保护起来。不保护 main等于把自己的工作台给别人留了一个随时能改乱的后门。配置保护规则只需要一次但省下来的排查时间远超过那点流程成本。3.2 一次标准 PR 的全流程从 checkout -b 到 Review 合并Pull Request 是 GitHub 协作的核心闭环开发者从最新的代码拉出一个分支做自己的改动推上去请求把这个分支合入 main经过 review 后合并。一次标准的 PR 操作如下git fetch upstream # 先拉取上游仓库最新提交 git checkout -b feature/login upstream/main # 从最新 main 创建功能分支 git add . git commit -m feat: 增加登录页 # 提交你的改动 git push -u origin feature/login # 推到自己的远程仓库推送完成后GitHub 仓库页会自动出现一个黄色横幅“Compare pull request”点进去选择 base 分支main和 compare 分支feature/login然后填写 PR 标题和描述。描述不要写“做了个功能”这种废话要写清楚为什么做、改了什么、自测结果如何开源项目通常还会要求列出测试步骤。Reviewer 在 Files changed 页面看 diff可以逐行留 commentapprove 或 request changes。你收到修改意见后在本地继续 commit 再 pushPR 会自动更新不需要重新建。GitHub 合并 PR 时有三个选项很多人一直没分清。Create a merge commit 保留这个分支上所有 commit历史完整但 main 分支图上会有大量交错的线Squash and merge 把所有 commit 压缩成一条合并到 main历史干净适合功能分支上堆了几十个无意义的小提交Rebase and merge 把分支的 commit 一个个重放到 main 头部历史线性但每个 commit 保留。我的默认建议是团队统一用 Squash and merge只有安全审计类改动才需要用 Rebase and merge 保留逐 commit 的痕迹。这些默认选项可以在 Settings - General - Allow squash merging 里配置。3.3 同步上游与解决冲突rebase 和 merge 的取舍Fork 出来的仓库会随着原仓库的更新不断落后提 PR 之前必须先把上游最新代码合并进来。同步上游的标准操作git remote add upstream https://github.com/原作者/仓库名.git git fetch upstream git checkout main git merge upstream/main git push origin maingit fetch upstream只是把上游的提交下载到本地不会动你当前的工作区它只是更新了一个叫upstream/main的远程追踪指针。git merge upstream/main才真正把上游主线的历史合并进你的本地 main最后push同步到你自己的 GitHub 仓库。这一步做完你 Fork 的仓库就和原仓库对齐了。如果冲突出在你的功能分支上有两种处理方式。一种是 merge直接在功能分支上把upstream/main合并进来简单但会把上游的主干历史混进你的分支PR 的 diff 里会掺杂大量别人的改动。另一种是 rebase把你功能分支的所有提交“重放”到上游 main 的最新提交之后历史干净冲突也更好解决。我在处理个人功能分支时的操作是git checkout feature/login git fetch upstream git rebase upstream/main # 若报冲突打开冲突文件搜索 HEAD保留需要的代码 git add 冲突文件路径 git rebase --continue # 全部解决后因为提交哈希已变化push 需要带 lease 参数强推 git push --force-with-lease origin feature/login--force-with-lease和--force的区别非常关键--force是无条件覆盖远程分支有把队友刚推的提交冲掉的风险--force-with-lease只有当远程分支还停留在你上次 fetch 的状态时才允许覆盖否则拒绝这能在 rebase 后安全地更新 PR。记住一句原则公共分支绝不 rebase个人 feature 分支 rebase 后强推一定要用带lease的版本。4. 高级功能落地Actions 自动化、Pages 部署和 Codespaces 云开发4.1 GitHub Actions 最小工作流push 后自动测试并上传构建产物GitHub Actions 是 GitHub 官方内置的 CI/CD 工具。你只要在仓库里放一个.github/workflows/xxx.yml文件GitHub 检测到 push、PR、打 tag、定时器这些事件后就会自动在虚拟机里执行你定义好的工作流。这个功能对新手来说是最容易见到效果的进阶功能代码一推上去自动装依赖、跑测试、做构建省掉本地手动验证的重复劳动。一个 Node 项目的最小工作流文件name: CI on: push: branches: [main] pull_request: branches: [main] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-nodev4 with: node-version: 20 cache: npm - run: npm ci - run: npm test - run: npm run build - uses: actions/upload-artifactv4 with: name: dist-${{ github.sha }} path: dist这个文件里的每个字段都要说清楚on定义了触发器这里指的是 push 到 main 和对 main 的 PR 都会触发还可以加workflow_dispatch支持手动在 Actions 页面点击运行。jobs下面可以写多个任务默认并行执行如果后续构建的 job 依赖测试 job就在后面加一行needs: build。runs-on: ubuntu-latest指定 runner 的操作系统GitHub 托管 runner 还支持windows-latest和macos-latest没有特殊需求用 ubuntu 就够了。actions/checkoutv4是最常用的官方 action作用是把仓库代码检出到 runner 的工作目录几乎每个工作流的第一个 step 都是它。actions/setup-nodev4用来装 Nodewith.node-version: 20指定版本cache: npm让 Actions 缓存 npm 依赖下次跑能省不少时间。注意这里的v4是 action 的 tag 版本号不要用main这类分支引用别人仓库更新可能被带到不受控的版本。npm ci和npm install的区别要讲清楚ci严格按package-lock.json安装先删 node_modules 再装干净、快速、可复现CI 环境就应该用ci而不是install。最后upload-artifact把构建产物的 dist 目录打包上传可以在 Actions 页面直接下载name里用${{ github.sha }}是当前提交的哈希避免多次运行产物互相覆盖。Actions 的免费额度对个人项目基本够用私有仓库的免费分钟数会比公开仓库少一些。另外注意一个安全设计fork 来的 PR 默认无法读取仓库的 secrets这是为了防止有人通过恶意 PR 偷密钥不要在 Actions 设置里强行关掉这个保护。4.2 GitHub Pages个人主页和项目文档的免费站点GitHub Pages 可以把仓库里的静态文件直接变成一个公开网站最适合个人主页、项目文档、前端 demo 这类场景不需要单独买服务器和域名。配置路径有两条按你的项目类型选择。最简单的方式是分支部署仓库 Settings - Pages - Source 选择Deploy from a branch分支选 main、目录选/root只要 main 根目录里有index.html每次 push 后 GitHub 会自动把代码发布成站点。用户名.github.io 这种个人主页仓库默认就是这种方式一个 HTML 文件加几次提交个人介绍页就上线了。如果项目是 Vite、VuePress、Jekyll 这类需要构建的站点就得用 Actions 部署。构建完的产物在 dist 目录需要通过 workfl: 上传并发布name: Deploy to Pages on: push: branches: [main] permissions: contents: read pages: write id-token: write jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-nodev4 with: node-version: 20 - run: npm ci - run: npm run build - uses: actions/upload-pages-artifactv3 with: path: dist deploy: needs: build runs-on: ubuntu-latest environment: name: github-pages url: ${{ steps.deployment.outputs.page_url }} steps: - id: deployment uses: actions/deploy-pagesv4这个工作流里最容易漏的是permissions块pages: write是给 workflow 写入 Pages 的权限id-token: write是 GitHub OIDC 认证需要两个都缺的话 deploy 阶段会报 403很多人第一次配置都卡在这里。environment里url字段用了steps.deployment.outputs.page_url这是一个从 deploy-pages action 的输出里取值的方法可以在 Actions 运行页直接看到发布后的站点地址。还有一个高频坑是path写错Vite 构建产物默认在 distVuePress 默认在src/.vuepress/distHexo 在 public先本地构建一次确认产物目录再填这个值。4.3 Codespaces把仓库变成开箱即用的云开发环境Codespaces 是 GitHub 官方提供的云端开发环境不需要在本地安装任何 IDE仓库页面点 Code 按钮 - Codespaces - Create codespace on main几秒钟就能打开一个浏览器里的 VS Code环境按照仓库配置自动装好依赖。适合的场景是新成员加入项目不想花半天装环境、你临时要改一个从未接触过的仓库、或者演示项目时环境崩了现场救火。Codespaces 的环境配置放在仓库的.devcontainer/devcontainer.json文件里把这个文件提交到仓库所有人打开同一个仓库的 Codespaces 就会得到同样的开发环境{ name: Node.js 20 workspace, image: mcr.microsoft.com/devcontainers/javascript-node:20, features: { ghcr.io/devcontainers/features/docker-in-docker:2: {} }, customizations: { vscode: { extensions: [ esbenp.prettier-vscode, dbaeumer.vscode-eslint ] } }, postCreateCommand: npm install }关键参数解释image指定基础镜像这里用的是微软官方 devcontainers 镜像里面预装了 Node 20features是可选组件docker-in-docker让容器里还能跑 Dockercustomizations.vscode.extensions声明打开环境时自动安装的 VS Code 扩展新成员一进来自动装好 Prettier 和 ESLintpostCreateCommand在容器创建后执行通常会跑npm install或者初始化脚本。修改 devcontainer.json 后要提交到仓库再重新创建 Codespaces 才能生效。Codespaces 是按运行时长计费的账号有免费额度约满后个人用户需要升级到付费方案或企业计划。它不是一个可以一直挂着的免费云电脑用完记得关掉这个费用陷阱我在实际项目里见过不少人踩。5. GitHub 使用避坑clone 慢、误提交和 PR 冲突的 5 条血泪经验5.1 clone 大仓库失败或卡住浅克隆与镜像下载的取舍现象git clone一个比较大的仓库时进度停在 99% 报错常见错误是RPC failed; curl 56 OpenSSL SSL_read: Connection was reset, errno 10054或者remote ended unexpectedly。再点一次还是卡在同一个位置git 不会自动断点续传。原因仓库历史里面积累了大量二进制文件或者某个提交本身特别大一次要传输的 blob 太多网络长时间占用后被重置。这类问题在 clone 初期很难察觉因为进度条前面看不出异常99% 时崩是最折磨人的。解决如果你只需要最新代码而不需要全部历史用浅克隆git clone --depth 1 --branch main gitgithub.com:user/repo.git # --depth 1 只拉取最近一次提交体积可以减少一个数量级 # 之后确实需要历史时再执行 git fetch --unshallow 补全如果连仓库都很大但只想要其中某个目录配合 sparse-checkoutgit clone --filterblob:none --sparse gitgithub.com:user/repo.git cd repo git sparse-checkout set src docs--filterblob:none的意思是提交和目录树的元数据照常下载实际文件内容按需获取--sparse让工作区先只保留根目录之后再通过sparse-checkout set按需把需要的目录检出到本地。 另外一个常见场景是下载 Release 里的压缩包几百 MB 的 zip 从 GitHub 页面直接下载容易中断。这种场景可以找当前可用的 github 镜像站点把 Release 下载链接里的域名换成镜像域名再下载。镜像站点是第三方维护的可靠性参差不齐今天能用明天失效很正常下载完一定要核对一下 SHA256 校验值再接进项目里。顺便说一句别把镜像域名写死在脚本里这是明显的脆弱依赖。5.2 误提交超过 100MB 的文件如何让 push 不再被拒现象git push时被服务器直接拒绝报错里写着File big_model.zip is 104.38 MB; this exceeds GitHubs file size limit of 100 MB。这个限制是 GitHub 对单个文件的硬性规定本地 commit 已经生成了但推送就是过不去。原因开发时把模型文件、数据集、安装包这类体积大的东西git add .带了进去而 GitHub 单文件不能超过 100MB整个仓库也建议不要超过 1GB。就算你用的是 Git LFS免费额度也只有 1GB 存储和每月 1GB 的带宽超出就要付费。解决如果 commit 还没推上去先把这个文件从暂存区摘出来git rm --cached big_model.zip echo big_model.zip .gitignore git commit -m chore: remove large filegit rm --cached只会把文件从 Git 索引删除不会动你磁盘上的原文件配合.gitignore让它以后不再被误加。但如果这个 commit 已经推上去了本地删掉没用远程历史里还躺着这个大文件必须重写历史。重写历史目前最省力的工具是 git filter-repo它是 Python 包先pip install git-filter-repo再执行git filter-repo --path big_model.zip --invert-paths # --path 指定要删除的文件--invert-paths 表示保留除它之外的所有内容这个命令会把所有分支、所有提交历史里这个文件的记录全部清掉然后由于安全考虑会把 remote origin 移除需要重新git remote add origin。重写历史后所有协作者都必须重新 clone那些还拿着旧仓库副本的人如果继续 push等于又把大文件的历史带了回来这需要团队统一行动。以后想往仓库放真正的二进制大件规范做法是用 Git LFS而不是硬塞仓库。5.3 密钥和 .env 被推上去了先删历史再轮换密钥现象push 完打开 GitHub 仓库发现.env文件老老实实躺在文件列表里里面是你的数据库密码、API Key或者没这么显眼是某种日志文件里打了一行AWS_ACCESS_KEY_IDAKIA...。这个现象在刚学 Git 的人身上高发。原因git add .把所有文件都带进去了而.env、config/secrets.yml这类文件默认没有被忽略。很多人以为私有仓库无所谓实际上 Git 仓库里一旦出现过密钥每个 clone 过的人本地都留着一份副本私有仓库不等于不泄露。解决处理顺序非常关键顺序错了等于白忙。第一步立刻去相关服务商把密钥吊销或轮换这是最重要的动作因为你后面花时间去清理历史的时候密钥一直在暴露状态。第二步才是清理仓库历史git filter-repo --path .env --invert-paths --force # --force 是因为 filter-repo 要求学生工作区干净先提交当前改动再用 git remote add origin gitgithub.com:user/repo.git git push origin --force --all git push origin --force --tags第三步确认所有分支、所有 tag 都不再包含该文件GitHub 仓库页搜索这个文件名确认已经找不到。最后一步把本地、同事手里所有可能复制过这个密钥的位置都轮换掉。GitHub 的 secret scanning 会对公开仓库里的已知格式 token 发警告但它只是提醒不会替你清理。真正治本的习惯是第一次git add之前先git status看一眼或者从一开始就把.env加进全局.gitignore。5.4 PR 显示冲突但本地没改同步上游分支的正确顺序现象GitHub 的 PR 页面显示 “This branch has conflicts”你切回本地分支试着 merge 一下 main提示一切正常没有冲突。这是很多人第一次看到 PR 冲突时都会懵的场景。原因GitHub 上 PR 的冲突检测不是拿你本地分支去比而是拿你推在远程的分支和当前目标分支在服务器上的最新状态做对比。目标分支在你 push 之后又被别人合并了别的功能这些新代码和你的改动冲突了。你本地没 merge 过这些新提交自然测不出来。解决把上游最新代码同步到你的功能分支重新解决冲突再推上去git checkout feature/login git fetch upstream git rebase upstream/main # 冲突文件里搜索 HEAD手动整理成最终代码 git add 冲突文件 git rebase --continue git push --force-with-lease origin feature/login这里用 rebase 而不是 merge是因为 rebase 会把你的提交重放到上游最新点PR 的 diff 干净只有你自己改过的东西如果用 merge 同步你的分支历史里会混入上游的提交PR 的 diff 会变成“你分支和 main 的全量差异”reviewer 看到一堆不属于你的改动非常痛苦。注意如果你参与的是别人仓库的 Fork同步源是upstream/main而不是origin/mainorigin指向的是你自己 Fork 的仓库这个概念搞混的话 fetch 了半天同步了个寂寞。5.5 github打不开或页面资源加载失败从 DNS 到镜像站的排查顺序现象github.com 主站能打开但头像、raw.githubusercontent.com 的图片加载不出来或者整个页面转圈几秒后报错也可能是昨天还能开今天突然打不开电脑重启后恢复了第二天又不行。这个现象在开发社区里非常高频很多人的第一个 GitHub 使用教程就是从这个问题开始的。原因这类问题大多不在 GitHub 本身而在域名解析环节。本地 DNS 缓存可能存了过期的解析结果或者当前网络环境使用的 DNS 服务器给出的解析指向了延迟很高的节点。页面资源走的是 CDN仓库代码走的是 SSH 或 HTTPS两者链路不同所以经常出现“页面开不了但 clone 正常”的混合状态。解决按顺序来不要上来就改一堆配置。第一步刷新本地 DNS 缓存Windows 执行ipconfig /flushdnsmacOS 执行sudo dscacheutil -flushcache让系统重新发起域名解析。第二步换公共 DNS把系统 DNS 改成223.5.5.5和119.29.29.29这是相对干净且响应快的公共解析服务影响范围小随时可以改回来自动获取。第三步如果只是下载 Release 里的资源文件走第 5.1 节说的 github 镜像站点下载完成后核对 SHA256 再使用。如果以上都试过仍然频繁失败可以考虑给常用域名配置 hosts 映射。具体做法是用nslookup github.com查询当前可用的 IP把它固定到系统 hosts 文件里跳过 DNS 解析直接连接。注意这种方式的有效期不稳定因为 GitHub 的 IP 节点会调整hosts 里配的 IP 过几天可能就不再好用只适合临时应急不建议提交到配置文件里长期依赖。这类网络症状需要按页面、clone、Release 下载分别定位别把问题都归到一个原因上分开排查才找得准。6. 把 GitHub 用成工作台模板仓库、Issue 标签和 CLI 提效高阶用户和普通用户的区别往往不在会不会敲命令而在有没有把 GitHub 从“代码存放处”变成开发流程的一部分。这里分享三个我现在新项目必做的动作。第一是模板仓库。在仓库 Settings 里勾选Template repository这个仓库就变成模板源新建项目时在 GitHub 首页点Use this template按钮直接复制整套目录结构、CI 配置、License 到新仓库省得每次从零搭脚手架。新项目第一步永远是先选模板而不是git init。第二是 Issue 规范化在仓库里建.github/ISSUE_TEMPLATE/bug_report.yaml给 bug 报告定义问题描述、复现步骤、环境信息这些必填字段配上 bug、enhancement 这类 label收到的 Issues 质量会高很多。第三是用 GitHub 官方 CLI 把重复操作变成一条命令gh repo create myapp --template my-org/go-starter --public gh pr create --title feat: 实现登录 --body Closes #12 --fill gh pr merge --squash --delete-branchgh是 GitHub 官方命令行工具登录一次之后可以把网页上的操作全在终端里完成。--template参数从模板仓库初始化新项目Closes #12是 GitHub 支持的自动闭合关键字PR 合并时对应 issue 自动关闭--squash合并后--delete-branch把远程分支一起清掉保持仓库整洁。验证一套流程是否规范我会看三个指标PR 合并后 issue 是否自动关闭、main 历史是否干净线性、分支列表里有没有堆积的 feature 分支。我现在的习惯是把这些命令写成脚本放进团队的工程化文档里新人照着跑一遍就能完成一次标准交付比自己点网页统计多了。希望帮到你。本文还有配套的精品资源点击获取
