很多同学第一次接触 GitHub 的体验并不愉快。计算机导论课老师强调“GitHub 是计算机专业学生的必修课”你下载了一个安装包却不知道安装对象是什么接着是 SSH 密钥、远程仓库、分支、Pull Request。这个过程在 2020 年的教程中非常典型工具一直是这些只是网页界面换了新外观。我写这篇“快速入手”教程就是想让你用一个下午的时间把整条链路完整跑通——从装好 Git 和 GitHub Desktop到第一次把项目推到远程仓库再到掌握日常协作和排错。这篇文章适合完全没有用过版本控制系统的同学也适合那些装过 Git 但一直停留在git init阶段、不敢往后走的人。2020 年之后的 GitHub 在交互上已经非常友好真正让新手卡住的反而是网上教程太散讲安装的只讲安装讲推送的又假设你已经配好了 SSH。所以我打算把这条链路串成一条完整的故事线你跟着一步步操作就好。1. 计算机专业为什么绕不开GitHub先搞清楚它解决的是什么问题1.1 版本控制一个人写代码和一群人写代码完全是两件事哪怕你只是一个人写课程设计版本控制也能带来巨大的安全感。想象一下这个场景你晚上改了一个关键的排序算法保存文件、关闭电脑。第二天发现逻辑全错了想回到昨晚之前的版本但已经找不到任何备份。如果你把项目放进 Git这个问题就变得极其简单——每次提交都是一个快照只要你按照习惯提交任何一份历史版本都能一键找回。多人协作的时候版本控制的价值更加直接。一个团队里好几个同学同时改同一个项目如果没有统一的工具最常见的做法是“最后一个人把文件发给其他人”或者干脆通过网盘同步整个文件夹。这种办法偶尔能跑通但只要两个人同时改了同一个文件你会发现覆盖、丢失代码、不知道怎么合并的问题接踵而来。Git 的解决办法是每个人都有自己的完整仓库各自提交然后通过分支合并机制把改动统一汇总。它不保证所有冲突自动解决但保证每次冲突都能被明确地、有记录地处理。GitHub 则是建立在 Git 之上的代码托管平台。它的核心价值不只是“把代码放到云端”还包括围绕代码的一整套协作机制Issue 讨论问题、Pull Request 审查代码、Actions 自动执行构建和测试。对一个计算机专业学生来说GitHub 是课程作业、开源项目、实习简历、求职作品集之间的那道共同桥梁。1.2 GitHub 在专业学习中的真实位置2020 年有一个很多人没太注意的变化GitHub 把新仓库的默认分支名从master改成了main。这个改动影响很大因为早期教程里到处写的是git push -u origin master你照着敲到了 2020 版以后很可能会因为分支名对不上而报错。我后面会专门说这个问题但你现在只要记住一个结论在网页上创建的新仓库默认分支是main本地初始化并推送时自己也要统一用main。另外2020 年的 GitHub 网页端做过一次大改版仓库首页的信息密度更大Pull Request 入口更明显很多操作按钮的位置都和旧版完全不同了。这一版也是我第一次真正把 GitHub 当作日常工具的时间点所以我这篇教程默认你打开的是新版界面并且把 2020 之后依然适用的命令和流程一并讲清楚。2. 2020版安装的完整落地方案Windows、macOS与Linux三条路线2.1 先分清你要装的“GitHub”到底是什么很多人会把三样东西混为一谈。Git是本地版本控制工具是一堆命令行命令GitHub是远程代码托管网站你通过浏览器访问它GitHub Desktop是官方图形客户端让你不用敲命令也能完成大部分操作。新手最稳妥的组合是先安装 Git学会基本命令行同时安装 GitHub Desktop 作为可视化辅助。两条路都能走通时你对版本控制的理解才会立体。工具选择的参考可以看这张表都是 2020 年以来最常用的方案工具作用适合场景Git 命令行本地版本管理的核心所有场景尤其工作后必备GitHub Desktop图形化日常操作新手入门、快速查看提交历史GitHub 网页端远程仓库管理、PR 审核创建仓库、协作审查代码2.2 Windows 部署 Git 与 GitHub DesktopWindows 上安装 Git直接到 Git 官网下载 Windows 版本即可。2020 年那会儿的稳定版本在 2.28 左右现在版本号虽然变了安装流程差别不大。选择 64 位安装包双击运行然后一路关注几个关键选项。第一是Select Components建议把 “Git Bash Here” 和 “Git GUI Here” 勾上。“Git Bash Here” 会在你右键文件夹时直接打开一个命令行窗口这对后来的操作特别方便——你不用每次打开命令提示符再手动 cd 到项目目录。第二是Adjusting your PATH environment选择中间选项 “Git from the command line and also from 3rd-party software”这样你在任何终端工具里都能直接使用git命令。第三是行结束符转换选项Windows 上默认选Checkout Windows-style, commit Unix-style line endings这个选项能避免很多换行符相关的坑。图形客户端方面安装 GitHub Desktop 更简单。到官网下载安装包安装完成后打开登录你的 GitHub 账号它会自动读取你账号名下的仓库列表。以后你看到某个仓库想直接拉下来在 GitHub Desktop 里点 “Clone repository”选好本地路径就能完成。macOS 和 Linux 下则简单很多。macOS 上安装 Xcode 的命令行工具会在很多场景下自动触发你也可以在终端里执行xcode-select --install它会弹出图形安装界面。安装完成后直接开发工具还是不够干净很多同学会借助包管理器这里我不过多展开你记住命令git --version能正常输出版本号就说明安装成功了。Linux 各发行版的包管理器名称不同。Debian/Ubuntu 一路直接执行sudo apt update sudo apt install git -y装完之后用git --version验证。无论哪个系统Git 安装包本身不会自带图形界面它只是一个命令行工具集所以安装完第一件事不是“打开 Git”而是打开终端执行命令。2.3 安装之后先验证环境安装完再顺手做两件小事。第一是打开终端敲git --version确认没有提示“不是内部或外部命令”之类的错误。如果报错先检查安装时 PATH 选项是否选对不能跳过第二个小技巧是在项目文件夹里右键看有没有 “Git Bash Here” 选项。没有的话重装一次把组件勾上。到这里你的机器上已经有了 Git 这个本地版本控制核心。但 GitHub 远程协作还需要一个身份认证步骤否则你只能看代码不能提交代码。这一步很多人第一次没看懂我单独用一章讲。3. 本地身份与SSH密钥装完之后必须完成的第一个配置3.1 配置用户名和邮箱防止提交记录“张冠李戴”Git 在你本地做每次提交时都会给这次提交记录记一个作者信息。如果不配置系统有时候会猜一个默认值比如从 Windows 用户名里面提取这样你在 GitHub 上的提交记录就会显示成乱七八糟的陌生人甚至完全没有关联到你的账号。打开终端执行下面两条命令把它替换成你自己的用户名和邮箱git config --global user.name 你的GitHub用户名 git config --global user.email 你注册GitHub用的邮箱--global表示全局生效也就是这台机器上所有 Git 仓库都默认使用这个身份。如果你在某个项目里临时想用不同身份可以去掉--global在项目目录里重新执行这样子配置只对当前项目生效。这一步和你的密码一点关系都没有其实是每个提交记录的“作者签名”。验证配置是否写对git config --global --list会看到user.name和user.email这两行。这里需要强调一下邮箱最好填写注册 GitHub 时使用的邮箱否则 GitHub 在统计你的贡献图时可能不认账你的绿色格子会一直不亮。3.2 用 SSH 密钥代替每次输密码从本地向 GitHub 推送代码常见的方式有两种HTTPS 和 SSH。用 HTTPS 推送时GitHub 会要求你提供账号密码或者个人访问令牌每次操作都要输入很烦。用 SSH 的方式你的本地机器会生成一对密钥一个是私钥留在本地一个是公钥放到 GitHub 后台。之后本地和 GitHub 之间建立连接时GitHub 用公钥验证你是否持有对应的私钥传输过程本身也更安全。生成密钥的命令如下在终端执行ssh-keygen -t rsa -b 4096 -C 你注册GitHub用的邮箱-t指定算法类型是 RSA-b指定 4096 位的长度-C只是给你这个密钥加一个注释方便辨识它可以是任意字符串。执行后会问你保存位置默认是C:\Users\你的用户名\.ssh\id_rsa在 macOS/Linux 下是~/.ssh/id_rsa直接回车采用默认值。下一步是设置口令passphrase它会问你是否为私钥设置密码。我建议设置哪怕是一个简单的口令也行。这样即使有人拿到你的私钥文件没有口令也没法使用。如果嫌麻烦也可以直接回车留空但这相当于把家门钥匙放在脚垫下面日常可以心里得有数。密钥生成完成后屏幕上会显示一段指纹信息并且告诉你密钥已经保存。接下来要做的是把公钥内容复制出来不同系统操作略有不同。Windows 终端里可以这样clip ~/.ssh/id_rsa.pubmacOS 用pbcopy ~/.ssh/id_rsa.pubLinux 可以先在终端输出再手动复制cat ~/.ssh/id_rsa.pub复制到的内容是一整行以ssh-rsa开头的长字符串这就是你的公钥。3.3 把公钥添加到 GitHub 后台并验证连接现在打开 GitHub 网页登录后点击右上角头像进入Settings在左侧菜单找到SSH and GPG keys然后点击New SSH key。Title 可以填“我的笔记本”“实验室台式机”之类这样将来你换电脑时能分清楚是哪台机器的密钥。Key 那一栏把刚才复制的公钥粘贴进去最后点Add SSH key。注意不要粘贴错了把私钥内容或者整行回车符都带进去会导致格式错误。一个常见的错误是把id_rsa私钥而不是id_rsa.pub公钥的内容放上去。好在公钥开头特征非常明显看到ssh-rsa AAAA...就没错。添加完之后验证是否真正连通ssh -T gitgithub.com如果正确你会看到类似这句话Hi 你的用户名! Youve successfully authenticated, but GitHub does not provide shell access.看到这个内容就可以放心了说明本地到 GitHub 的加密通道已经打通。以后推送代码不需要再来回输密码后面所有操作会顺畅非常多。4. 第一次完整推送项目从git init到远程仓库的全流程4.1 准备一个可演示的本地项目我假设你手上没有任何现成项目我们从零开始建一个简单目录。随便在哪个位置新建一个文件夹名字用拼音或英文都可以比如demo-project。我建议你刻意用英文名因为 Git 和很多命令行工具对中文路径的处理偶尔会有些小麻烦能避则避。在这个文件夹里新建一个 README.md 文件内容先写一句话# demo-project 这是用于第一次上传 GitHub 的测试项目。README 文件是 GitHub 仓库的门面它会在仓库首页自动渲染显示。你以后看任何开源项目第一眼看到的就是这个文件。现在先把它当一个普通的说明文件用。4.2 初始化仓库并完成第一次提交在项目文件夹里右键选择 “Git Bash Here”或者用终端cd进入这个目录然后执行git init这一步会在当前目录生成一个隐藏的.git文件夹所有版本历史、配置信息都存在里面。这个文件夹就是“仓库”目录里其他文件是仓库里的内容。很多人会疑惑为什么我不能直接把项目文件夹传到 GitHub因为 GitHub 需要的是 Git 能识别的仓库格式而不是简单文件云盘。接着把文件加入暂存区并提交git add README.md git commit -m first commitgit add是把修改加入暂存区git commit是把暂存区的内容固化成一个历史版本。提交信息-m后面跟着的字符串是对这次改动的说明。你可以随时执行git status查看当前仓库状态它会清楚告诉你哪些文件被改过、哪些还没提交。刚接触 Git 时养成每改一个功能就提交一次的习惯比一次提交几百个文件要科学得多。4.3 创建远程仓库并关联在 GitHub 网页右上角点击加号选择New repository。Repository name 填demo-project和本地文件夹名保持一致。这样的话以后不管谁 clone都知道该放哪个目录省心。描述可写可不写可见性可以选 Private尤其课程作业这类代码建议先私有避免被判定为抄袭隐患。创建页面下什么都不用初始化README 文件你已经写在本地了不用勾选 GitHub 自动生成的 README。创建完成后页面会显示一条类似这样的命令git remote add origin gitgithub.com:你的用户名/demo-project.gitremote add表示给这个远程仓库起个别名叫origin。这个别名是 Git 社区约定俗成的默认叫法表示“主要的远程仓库”。执行这条命令然后推送git branch -M main git push -u origin main第一行的git branch -M main是把本地分支从默认的master重命名为main。第二行的-u意思是把本地main分支和远程origin/main分支关联起来这样以后你在本地直接git pushGit 就知道该推到哪里。执行过程中第一次可能需要确认 GitHub 的 host key终端问你Are you sure you want to continue connecting输入yes回车即可。推送成功后刷新 GitHub 网页你应该能看到demo-project仓库里出现了 README.md 文件提交信息写着first commit。4.4 推送成功的标准与分支名称细节这里特别说一下分支名的问题。如果你在本地执行的是git push -u origin master而网页仓库默认分支是main两个分支并不会自动合并你会看到一个推送成功、但网页上却看不到文件的怪现象。因为在 GitHub 上这个仓库默认展示的main分支是空的你推送到的master分支孤零零挂在一边。解决办法就一条推送之前先统一分支名。用git branch -M main把本地分支改名或者用git push -u origin main推送 main。如果已经在网页上看到了master分支也可以在仓库页面的分支切换下拉菜单里删除或重命名。我建议你从一开始就用main省得和 2020 版之后的所有教程对齐时一头雾水。5. 日常协作高频操作分支、Pull Request与合并冲突实战5.1 分工协作的基础套路单个项目一个人推来推去其实还体现不出 Git 的优势。你要面对的真实场景通常是三个人同时做一个课程设计你负责前端页面A 同学负责后端接口B 同学负责数据库脚本大家都要改同一个仓库。组织方式一般是这样的仓库所有者创建一个main分支作为稳定主干这个分支上的代码应当保证随时可以运行。每个人需要开发新功能时从main分出去一个自己的分支比如feature/login-page在自己的分支上随意提交、随意折腾不影响主干。功能做完后再把分支合并回main。命令行操作如下。第一次拿到别人的仓库时用克隆的方式下载到本地git clone gitgithub.com:你的用户名/demo-project.git进入项目目录后创建并切换到自己工作的分支git checkout -b feature/readme-update-b的意思是“新建分支并切换过去”。这之后你的所有提交都会落在feature/readme-update上main主干完全不受影响。5.2 从分支到 Pull Request 的完整流程分支开发完成后把分支推送到远程git add . git commit -m 更新README说明文档 git push -u origin feature/readme-update然后在 GitHub 仓库页面上你会看到一条黄色或绿色的提示条feature/readme-update had recent pushes旁边有个Compare pull request按钮。点击它相当于向仓库所有者发出一个请求“我想把自己的分支合并进主分支请你审核一下。” Pull Request 的界面里可以写清楚这次改动做了什么也可以让协作者在讨论区留言。团队项目里通常需要至少一个其他人看一眼代码确认没问题后才点Merge pull request。这套流程的精髓在于不是所有人都能直接往main分支上写改动要经过审查。对于学生团队来说它听起来有点重但稍微大一点的项目这种约束非常有用。如果你和同学之间还没有固定的组织架构可以先由一个人当仓库所有者其他人 fork 或者直接作为 collaborator 推分支两种方式都可以。collaborator 模式对小团队更简单因为大家都能直接推分支不需要绕道 fork。5.3 合并冲突第一眼会慌说实话不难合并冲突大概是很多新手最恐惧的四个字但它本质上就是双方改了同一片区域Git 不知道该听谁的。我用一个最简单例子说明。你和 B 同学都在README.md里加了同一句话但内容不同。你执行git merge或合并 Pull Request 时Git 会停下来告诉你冲突了需要你手动决定留下哪个版本。打开冲突文件你会看到类似的内容 HEAD 这是你当前分支里的内容 这是其他分支里的内容 feature/other-branch和之间是当前分支的内容和之间是另一个分支的内容。你要做的就是把尖括号、等号这些标记删掉保留正确内容如果两段都要就都留着。改完之后git add README.md git commit -m 解决README冲突然后继续推送。第一遇到冲突时不要慌先打开文件看git 已经帮她把冲突位置都标出来了。最好的降低冲突方式是开工之前先把别人推上来的最新代码拉下来让每个人的起始点尽量接近。6. 常见错误与排查清单2020版本之后依然会踩的坑6.1 安装阶段的常见坑安装 Git 后最常见的问题是打开终端敲git却提示找不到命令。这个基本就是 PATH 环境变量没配好或者安装时选择了错误的 PATH 选项。不必手动去改环境变量重装一次 Git在 “Adjusting your PATH environment” 那一页选择中间选项安装完成后重新打开一个终端问题一般就解决了。“Git Bash Here” 不出现的坑也类似重装时记得勾选组件。另外一个容易忽略的问题是2020 年那年有不少电脑仍在使用 32 位 Windows或者 Windows 7 环境导致新版 Git 安装包不兼容。如果遇到这种情况去官网下载一个历史版本比如 2.28 之前支持旧系统的版本功能上完全够用。当然这只适合还在使用旧系统的特殊场景新电脑不用纠结。6.2 推送阶段的报错对照表我把 2020 版之后新手最常遇到的报错整理成一个表每条都附上了对应的处理思路。你碰到的时候可以直接对照。报错信息常见原因处理方式Permission denied (publickey)SSH 密钥没配对或私钥口令输错执行ssh -T gitgithub.com确认公钥已添加到后台fatal: repository ... not found仓库名拼错或该仓库不存在或权限不足核对仓库地址确认你在该仓库的 collaborator 名单里Updates were rejected because the remote contains work远程仓库有本地没有的提交执行git pull --rebase origin main再重新推送error: src refspec main does not match any本地还不存在 main 分支或者还没 commit先git add和git commit再推送connect to host ... : Operation timed out网络临时不稳定检查网络连通性换个时段或换个网络重新尝试其中Updates were rejected是最常见的。原因通常是两种一个是你在网页上创建仓库时顺手勾选了初始化 README远程因此多了一个本地没有的提交另一个是协作者在你本地提交之后又往远程推了新代码。处理方式基本都是先git pull --rebase把自己的改动放到最新代码之上再推送。--rebase的好处是让提交历史保持线性看起来更干净。6.3 换行符与大文件的隐藏坑Windows 和 Linux/macOS 的换行符不一样前者是 CRLF后者是 LF。Git 默认会做转换但团队里如果有人关掉了这个转换选项你就可能在 diff 里看到大量毫无意义的红绿全行变化——明明没改内容Git 却认为每一行都变了。统一做法是在仓库根部创建一个.gitattributes文件明确指定文本文件的换行规则这样所有成员不管什么系统提交时都使用一致的标准。还有一类问题是仓库文件体积。GitHub 对单个文件默认有 100MB 的大小限制并且不建议任何人把大文件直接塞进 Git 仓库。课程设计中的数据集、模型权重、编译产物这类文件应该被.gitignore排除或者改用 Git LFS 这类扩展方案。新手不需要一开始就学会 Git LFS但一定要学会.gitignore比如node_modules/、target/、__pycache__/这些生成目录都不应该进入版本控制。等你哪天不小心把 200MB 的日志文件提交上去再想从历史里彻底清除就会非常狼狈。7. 计算机专业的学习姿势把GitHub用成自己的成长工具7.1 从“收藏夹”到“提交记录”很多人把 GitHub 当成了一个巨大的收藏夹看到好的项目就点个 Star然后就没有然后了。这不怪你因为阅读别人的代码本来就是一件成本很高的事。但 GitHub 真正的学习价值是从第一行代码的提交开始的。你可以把所有课程作业、实验报告、小组设计全部放进仓库坚持“每次动手之后立即提交”。不用写多专业的 commit message只要写清楚“完成了什么”就好。一个月下来你会发现自己的提交记录就是一部完整的过程文档哪天做了什么、改了什么、哪次实验卡了很久。面试时最真实的项目经验其实就是这一条条提交记录。这比临时拼凑一个“会说话的机器人”项目要让人信服得多。7.2 阅读源码、参与开源和搭建作品集进入计算机专业高年级之后你应该尝试做这样一件事找一个经常使用的库或框架去看它的 GitHub 仓库。不需要读懂全部源码只挑自己用过的那个模块看看别人是怎么组织函数、怎么写文档、怎么处理异常情况的。GitHub 网页上的文件跳转很流畅点进文件再点函数定义就能一路追踪。这一套动作坚持几次之后你阅读代码的能力会有肉眼可见的提升。如果觉得自己基础不错还可以从good first issue开始参与开源。GitHub 的 issue 列表里经常会有“适合新手”标签的任务比如修一个文档错误、补一个测试用例。提交第一个 Pull Request 的过程虽然有点紧张但收到陌生人认真 review 的体验和老师批改作业完全不同。这里我要提醒一句参与开源最重要的不是代码多厉害而是学会遵循项目已有的规范和沟通方式这恰恰是课堂里很少教的事情。7.3 2020版本之后的新手建议最后说几条我自己的体会。第一命令不用全部背下来理解工作流比记忆命令重要得多。你只要记住clone、add、commit、push、pull这几个高频命令日常已经足够用剩下的命令遇到再查查几次自然就记住了。第二遇到报错先看报错原文再复制到搜索引擎不要盲目重装软件大多数问题不是安装包坏了而是操作顺序或者配置缺少某一步。第三把你的仓库保持干净、保持小步提交这不是为了好看而是为了将来排查问题时能快速定位。我自己一直保留一个习惯每次课程项目落地第一件事就是初始化一个 Git 仓库并同时创建.gitignore。等到项目交付的时候我会再看一遍提交历史把那些写着“fix typo”“update code”的信息整理清楚这些记录本身就是一份最好的项目复盘。你能看到开始时的笨拙、中途的卡顿和后来的熟练这种成长曲线会一直陪着你的专业生涯。