1. 先把概念理顺Git 和 GitHub 到底谁是谁“GitHub 安装及使用”这个题目十个来问的人里有八个问的其实是两件事一是怎么把 Git 这个工具装到自己电脑上二是怎么把本地写的东西传到 GitHub 上去。这两个问题拆开看都不复杂混在一起就容易乱。我一般会先跟人说清楚Git 是装在你机器上的版本控制工具GitHub 是一个跑在云端的代码托管网站它俩的关系有点像你本地记账用的账本和你放在共享空间里供团队查阅的账目平台。你可以只装 Git 不用 GitHub也可以只用 GitHub 网页端传文件不装 Git但真正想把它用顺手两边都得会一点。这篇文章我打算按“装什么→怎么装→怎么连起来→日常怎么用→出问题怎么救”的顺序捋一遍。适合两类人一类是刚接触代码托管、完全没碰过命令行的小白另一类是装过 Git 但一直靠图形界面点按钮、遇到报错就懵的朋友。我会尽量把每个选项背后的原因说清楚因为你只有知道每个开关在干嘛下次换台机器或者换个系统才不至于重新摸索一遍。装软件这件事本身没什么技术含量真正值钱的是配置项的取舍和踩过的坑这部分我会重点讲。1.1 本地版本控制与远程托管的分工我常拿写论文来类比。Git 就是你在电脑上给每一版论文存一个带说明的快照哪天导师说“还是第二版好”你能立刻翻回去GitHub 则是把这份带历史的文件夹整体复制一份放到云端好处是换电脑能接着写、多人能同时在同一份稿子上改、改崩了还能找回来。所以严格来说“安装 GitHub”这个说法是不准确的。你能安装的东西有三种得看自己的需求Git 命令行工具核心装了它才有git这个命令是所有图形界面的底层。GitHub DesktopGitHub 官方出的桌面客户端图形化操作适合完全不想碰命令行的人。编辑器内置的 Git 能力VS Code、JetBrains 全家桶里都自带 Git 面板本质上还是调用你系统里装好的 Git。我的建议是Git 命令行必装图形界面按需装。哪怕你平时都用客户端点按钮也把命令行装上因为排查问题的第一步永远是打开终端敲一条git status图形界面把太多信息藏起来了出错时反而更难判断。1.2 为什么建议从命令行入手而不是只依赖图形界面图形界面在“看一眼改了什么、点一下提交”这种日常操作上确实又快又直观我也不否认 GitHub Desktop 对新手很友好。但有几类场景界面会直接把路堵死合并冲突需要手工编辑冲突标记的时候、要把某几次提交挪到另一个分支的时候、要临时保存当前改动去处理紧急 bug 的时候。这些操作在命令行里就是几条命令在图形界面里要么没有入口要么藏在好几层菜单下面。更麻烦的是图形界面通常只展示“结果”不展示“它替你执行了什么命令”你学不到东西换个客户端又得重新适应。提示不需要一开始就把命令背下来。我的做法是先用命令行做几遍最基础的“改→提交→推送”等身体记住节奏了再装个客户端提速。两者不是二选一是先后关系。2. 环境准备各平台 Git 客户端安装全流程这一节是最容易出问题也最容易被跳过的部分。很多人装完 Git 就直接开始提交结果第一次提交就报“请告诉我你是谁”或者代码推上去之后整个文件的行尾符全变了回头 diff 出来几千行改动看着就想删库重来。这些问题的根源基本都在安装环节和装完之后那几条配置命令上。所以我的做法是装的过程慢慢来装完立刻做一次最小化配置。所谓最小化配置就是至少把身份信息、默认分支名、行尾符处理策略这三件事定下来。剩下的可以后面按需加但这三条是每次提交都要用到的早配早省心。2.1 Windows 平台的安装与安装向导逐项解读Windows 用户从 Git 官方站点下载安装包双击运行后会看到一个选项挺多的向导。别一路“下一步”下面这几个页面值得停一下。Select Components 页面建议勾上Windows Explorer Integration这样在任意文件夹右键就能直接“在此处打开 Git Bash”省掉每次cd半天目录的麻烦。Associate .git* configuration files with the default text editor也可以勾方便直接编辑配置文件。Choosing the default editor 页面这个决定 Git 在需要你输入提交信息时弹哪个编辑器。默认的 Vim 对新手不友好进去之后不知道怎么退出按Esc然后输入:wq回车就行这是第一个要记的救命操作。我一般直接选 VS Code 或 Notepad改完保存关闭窗口提交就完成了。Adjusting your PATH environment 页面这一页最关键。三个选项里选中间的Git from the command line and also from 3rd-party software。意思是 Git 命令在 CMD、PowerShell、Git Bash 里都能用同时第三方工具也能调用它。选第一项会导致你在 PowerShell 里敲git提示找不到命令选第三项会把一堆 Linux 工具塞进系统路径可能和系统自带命令打架。Configuring the line ending conversions 页面选Checkout Windows-style, commit Unix-style line endings。原因是 Windows 和类 Unix 系统表示换行的方式不同这个选项让 Git 在检出时自动转成 Windows 风格、提交时自动转回 Unix 风格团队协作时不会因为换行符产生一整屏的无意义改动。后面的 HTTPS 传输后端选Use the OpenSSL library凭据管理器选Git Credential Manager终端模拟器选Use MinTTY其余保持默认即可。凭据管理器这个要特别说一下它会把你第一次输入的身份凭据存进系统凭据库后面推送就不用反复输入了非常省事。2.2 macOS 与 Linux 平台的安装方式macOS 上有个坑你直接在终端敲git --version系统会提示你安装命令行开发者工具装完之后确实有git命令了但那是系统捆绑的版本可能落后好几个大版本而且升级依赖系统更新比较被动。我更推荐用 Homebrew 装# 先装 Homebrew如果还没有 /bin/bash -c $(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh) # 安装 Git brew install git # 确认用的是 Homebrew 版而不是系统版 which git # 期望输出类似 /opt/homebrew/bin/git 或 /usr/local/bin/gitLinux 就简单多了直接走包管理器# Debian / Ubuntu 系 sudo apt update sudo apt install git # Fedora / RHEL 系 sudo dnf install git # Arch 系 sudo pacman -S git装完用git --version确认一下版本号能看到具体数字就说明 PATH 里的git已经指向正确位置了。如果输出的路径不是你想用的那个检查一下 PATH 顺序多半是旧版本排在前面。2.3 安装后的验证与最小化初始配置装完之后别急着建仓库先花两分钟做配置。这些设置会写进用户目录下的全局配置文件一次配好机器上所有仓库通用。# 确认安装成功 git --version # 配置身份信息提交记录里会带上这两项 git config --global user.name Your Name git config --global user.email youexample.com # 把默认分支名设为 main git config --global init.defaultBranch main # 让 Git 记住凭据避免反复登录 git config --global credential.helper store # 检查所有配置来自哪个文件 git config --list --show-origin这里要解释两个“为什么”。为什么用户邮箱要认真填GitHub 是靠提交记录里的邮箱把提交归属到你账号上的。如果邮箱和账号注册邮箱对不上提交虽然能推上去但不会显示成你的头像和贡献记录团队里别人也搞不清这是谁写的。如果你想保护隐私GitHub 提供了一个专用的匿名邮箱格式可以在账号设置里找到用它同样能正确归属。为什么默认分支名要改成 main早期 Git 默认分支叫 master后来这个习惯改了GitHub 新建仓库的默认分支是 main。如果你本地是 master、远程是 main第一次推送会多出一步映射操作新手很容易在这里卡住。干脆本地也设成 main两边对齐。注意credential.helper store会把凭据以明文形式保存在用户目录下。如果你用的是多人共用的电脑改用git config --global credential.helper manager走系统凭据库会更稳妥。3. 账号与远程仓库从零建起第一个仓库本地环境弄好了接下来是云端那一半。这一步的目标是让本地的一个文件夹和 GitHub 上的一个仓库建立起稳定的双向通道。通道建好之后你在本地提交敲一条命令就能同步上去别人也能看到。我见过不少人卡在这一步不是因为操作难而是因为一开始就打开了错误的入口。比如在网页上直接拖拽上传了一堆文件结果本地没有对应的 Git 仓库后面想改一个字符都得重新上传一遍历史记录完全断裂。所以我的建议是仓库一定要先建在本地或者用克隆的方式建立别用网页拖拽当日常手段。3.1 注册账号与仓库初始化选项怎么选注册流程没什么可说的邮箱、密码、用户名。用户名建议用英文短名因为它会出现在仓库地址里改名字会导致旧链接失效。新建仓库时有几个选项值得掰扯选项建议理由Repository name英文小写加连字符出现在 URL 里中文和空格会被转义成一串百分号编码很难看Description建议填仓库列表页会显示自己也方便回忆Public / Private按需学习练手用 Private 更安心需要展示时再改Add a README file新手建议勾勾了仓库会有一个初始提交克隆下来就能直接用Add .gitignore按语言选提前过滤掉不该提交的文件省掉后面的清理工作Choose a license开源再选自己用不到打算让别人用得明确授权条款这里有个容易踩的坑如果你打算把一个已经存在的本地文件夹推上去新建仓库时不要勾选任何初始化文件。因为一旦远程有了 README 或别的文件而本地又是从零开始的两边的历史没有共同祖先推送时会被拒绝你就得先拉取再合并多绕一圈。空仓库配本地已有代码是最顺的路径。3.2 用 SSH 密钥打通本地与远程连接本地和远程有两条路HTTPS 和 SSH。HTTPS 用账号加令牌认证SSH 用一对密钥认证。我个人长期用 SSH配一次之后几乎不用再管推送时也不会弹出登录框打断思路。生成密钥对# 生成一对 ed25519 密钥比 RSA 更短更安全 ssh-keygen -t ed25519 -C youexample.com # 连按三次回车默认路径、空密码短语、确认 # 生成的文件在 ~/.ssh/ 下id_ed25519私钥和 id_ed25519.pub公钥 # 查看公钥内容并复制 cat ~/.ssh/id_ed25519.pub复制出来的那一整行粘到 GitHub 账号设置的 SSH keys 页面里标题随便起一个能认出来的名字比如“家里台式机”。然后测试连接ssh -T gitgithub.com第一次连接会问你是否信任这个主机输入yes回车。如果看到类似“Hi 你的用户名! Youve successfully authenticated”但末尾说“does not provide shell access”这就是成功了最后那句是正常的说明认证通过但该服务不提供交互式终端。提示私钥文件绝不能外传也不要提交进任何仓库。私钥泄露等于别人可以以你的身份推送代码。如果怀疑泄露了立刻去账号设置里删掉对应的公钥重新生成一对。如果 SSH 这条路一直不通用 HTTPS 也完全可以只是首次推送需要认证按提示在浏览器里授权一次即可凭据管理器会替你记住。3.3 README、License、.gitignore 三个文件的取舍仓库根目录下这三个文件看着不起眼其实决定了别人第一眼对项目的判断也决定了你自己维护起来顺不顺。README.md是仓库的门面打开仓库页面默认渲染的就是它。最低限度写清楚三件事这东西是干什么的、怎么跑起来、目录结构大概是什么样。我见过很多仓库点进去只有一句项目名连怎么安装都不写三个月后自己回来都忘了怎么启动。写 README 不用追求华丽## 项目简介## 快速开始## 目录说明三段式就够用。.gitignore是过滤清单列在里面的是“永远不要提交的文件”。典型的该忽略内容包括依赖目录node_modules/、venv/、构建产物dist/、build/、*.class、IDE 配置.idea/、.vscode/里的个人设置、系统文件.DS_Store、Thumbs.db、以及任何含密钥的本地配置文件。License是授权声明。如果你只是自己用或者公司内部项目可以不管一旦希望别人能合法使用、修改你的代码就必须明确选一个。没有许可证的公开仓库严格来说别人是没有使用授权的这一点很多人没意识到。4. 日常高频操作把工作流跑顺前面都是准备工作这一节才是每天真正要重复的动作。我的经验是日常操作其实就那么五六条命令把它们变成肌肉记忆之后Git 就不再是一个需要“学”的东西而是一个顺手工具。4.1 克隆、修改、提交、推送的四步循环这是最核心的循环百分之八十的时间都在这个循环里转。# 1. 克隆远程仓库到本地只需做一次 git clone gitgithub.com:用户名/仓库名.git cd 仓库名 # 2. 每次开始工作前先同步最新的远程改动 git pull # 3. 修改文件后查看当前状态 git status # 4. 把改动加入暂存区 git add 文件名 # 添加指定文件 git add . # 添加所有改动慎用先看清楚 status 输出 # 5. 提交到本地仓库写好说明 git commit -m 修复登录页手机号校验逻辑 # 6. 推送到远程 git push这里面最值得展开的是git add .和git commit -m。git add .会把你当前目录下所有改动一股脑加进去包括你可能不想提交的临时调试代码、本地生成的日志文件。我自己的习惯是先git status看清楚有哪些改动再决定是git add .还是逐个文件名添加。多花五秒钟看一眼能省掉后面撤销的十分钟。git commit -m里的那句话很多人写成“修改”“更新”“fix bug”。这种信息三天后自己都看不懂。我一般按“做了什么 为什么”来写比如“把超时时间从 3 秒改成 10 秒因为弱网环境下频繁失败”。长度不用纠结说清楚就行。4.2 分支、合并与冲突处理一个人写代码直接在主分支上改也能跑但只要涉及多人协作或者要同时推进两件事分支就是必需品。可以理解为主分支是已经稳定的版本你开一个新分支去做实验做完了再合并回去实验失败直接删掉分支主分支毫发无损。# 查看所有分支 git branch -a # 创建并切换到新分支 git switch -c feature/login # 在新分支上正常 add / commit # ... # 切回主分支并同步 git switch main git pull # 把新分支合并进来 git merge feature/login # 推送主分支 git push冲突是怎么来的两个人改了同一个文件的同一块区域。合并时 Git 无法判断该保留哪一版就把两版都标出来让你决定 HEAD 超时时间 3 超时时间 10 feature/login处理方式是手工把这段改成你想要的结果然后把、、这三行标记删掉保存再git add那个文件最后git commit完成合并。判断标准只有一个合并之后这段代码逻辑上是对的别管是哪一版。注意冲突时不建议用“全部采用我的”或者“全部采用对方的”一键处理那种操作在团队协作里非常危险容易把别人辛苦改的逻辑覆盖掉。逐段看慢一点但安全。4.3 回退与撤销reset、revert、restore 的区别与选择这是新手最容易搞混的一组命令用错了真的会丢代码。我用一张表说清楚。场景命令说明改错了文件还没 addgit restore 文件名把工作区改动丢弃回到上次提交的样子已经 add 了想撤出暂存区git restore --staged 文件名保留文件改动只是不再准备提交提交信息写错了还没推送git commit --amend修改最近一次提交会改写提交 ID提交错了还没推送想彻底退回git reset --soft HEAD~1撤销提交但保留改动改动回到暂存区提交错了已经推送了git revert 提交ID生成一个反向提交来抵消历史完整保留关键区别在于reset是改写历史revert是追加历史。已经推到远程、别人可能已经拉取过的提交绝对不能用reset去改写否则别人的本地历史和远程就对不上下次拉取会一片混乱。这种情况下用revert它虽然会让历史里多出一条“反向操作”的记录但所有人都能平滑同步。--soft、--mixed、--hard三个参数的区别也值得记一下--soft只移动分支指针改动全部保留在暂存区--mixed是默认值改动保留在工作区但不暂存--hard会连同改动一起丢弃这是最危险的一个执行前一定要确认没有想留的东西。5. 协作与工程化实践能自己完成提交推送之后下一步就是让别人也能参与进来以及让仓库长期保持整洁。这部分不是必答题但做过一次之后你对整个协作流程的理解会上一个台阶。5.1 Pull Request 流程与 Code Review 要点Pull Request简称 PR的意思是我把我的分支推上去了请仓库维护者看看要不要合并进主分支。它不是 Git 自带的命令是 GitHub 这类平台在 Git 之上加的一层协作机制。标准流程是这样从主分支切出功能分支在分支上提交推到远程同名分支网页上会自动提示可以发起 PR。填写标题和描述说明这次改了什么、为什么改、怎么验证。然后等维护者审查。作为提交方有几件事特别影响对方的审查体验PR 别太大。一个 PR 改三十个文件、涉及五个不相关的功能审查的人根本无从下手。按功能拆分每个 PR 只做一件事哪怕因此多提几个 PR整体效率反而更高。描述里附上复现步骤或截图能省掉大量来回追问。作为审查方重点看逻辑正确性、边界情况、有没有引入新的隐患格式和命名这种能靠工具自动检查的就别占用人力。提意见的时候说清楚“为什么”只写“这样不好”对方也不知道该怎么改。意见分歧大的地方直接开个语音聊五分钟比在评论里来回打字一小时有效。5.2 .gitignore 与仓库瘦身仓库一旦变大克隆和拉取都会变慢而且这种问题是不可逆的——文件提交进去了即使后来删掉历史记录里还留着仓库体积依然那么大。预防胜于治疗。项目一开始就把.gitignore写好常见的模板可以直接用平台提供的语言模板生成在此基础上补充自己项目特有的路径。有个简单判断法任何能用命令重新生成的产物都不该进仓库。依赖、编译输出、缓存、日志全属于这一类。如果已经不小心把大文件提交进去了处理办法是先删掉文件并提交一次让它不再出现在最新版本里如果体积问题很严重需要用专门的历史重写工具去清理整个提交链但这类操作会改写所有提交 ID必须通知所有协作者重新克隆不能随便用。我的建议是能在源头上拦住就别走到这一步。另外提醒一句仓库里那个记录忽略规则的配置文件本身要提交因为它是团队共享的而你的个人编辑器配置、本地路径设置这类东西应该放进全局忽略文件里别塞进项目仓库。5.3 提交信息规范与提交粒度提交信息这件事看起来是形式实际上是团队协作的润滑剂。半年后排查一个 bug你需要靠git log快速定位是哪次改动引入的如果历史里全是“更新”“修改”那这个仓库的历史基本等于没用。我常用的格式是第一行一句话概括不超过五十个字空一行然后分点写具体做了什么、为什么这么做、有什么需要注意的。如果关联了某个问题编号写在第一行末尾方便检索。提交粒度上我踩过的坑是“攒一大堆一起提交”。写了两天代码中间改了十七个文件最后一次性提交提交信息只能写“完成登录功能”。这种提交没法回退到某个中间状态也没法单独挑出某个改动应用到别的分支。比较好的节奏是每完成一个逻辑上独立的改动就提交一次哪怕这个改动只有三行。拆得细回退的时候才灵活。6. 常见问题与排查速查这一节基本是我这些年遇到过的报错合集。我把它们按现象归类配上排查顺序遇到问题时可以按表对照。6.1 身份认证与权限报错报错现象常见原因处理方式Permission denied (publickey)SSH 密钥没配好或没加到账号检查~/.ssh/下密钥是否存在公钥是否已添加到账号设置用ssh -T测试Repository not found地址拼错或没有该仓库权限核对远程地址确认自己有权访问私有仓库需要对应授权推送时反复要求输入凭据凭据辅助工具未生效检查credential.helper配置重新认证一次Please tell me who you are没配用户名和邮箱执行全局配置命令注意拼写排查这类问题的通用思路是先确认身份再确认权限最后确认地址。先跑git config --list看身份信息在不在再跑ssh -T看认证通不通最后git remote -v看地址对不对。这三个命令基本能覆盖九成的连接问题。6.2 冲突、行尾符与大小写问题有三个隐蔽性很强的问题平时不出事一出事就很难查。行尾符导致的全文件 diff如果你改了文件里的一行git diff却显示整个文件都变了八成是行尾符不一致。安装时选对转换选项能避免大部分情况跨平台协作的项目可以在仓库根目录加一个属性配置文件明确指定文本文件统一用某种行尾符。文件名大小写变更没被识别Git 默认不区分文件名大小写。你把Utils.js改成utils.jsGit 可能认为没变化。解决方式是分两步改名先改成一个完全不同的名字提交再改成目标名字提交或者用专门的重命名命令强制记录。合并时出现大量无关文件的冲突通常是某个协作者把不该提交的文件依赖目录、构建产物提交进去了。处理掉这些文件并加入忽略清单才能从根上解决。6.3 误提交敏感信息与文件丢失的补救误提交了密钥或密码这是最需要严肃对待的一类问题。要记住一个前提只要提交并且推送过就应该默认它已经泄露了即使你马上删掉文件历史记录里依然可以翻出来。正确的处理顺序是第一步立刻去对应的服务方那里把这个密钥作废并重新生成这是止损的关键第二步再把文件从仓库里移除并加入忽略清单第三步如果确实需要清理历史再用历史重写工具处理并且通知所有协作者重新克隆。顺序不能反。很多人先把文件删了觉得万事大吉密钥其实还在历史里躺着等于什么都没做。文件丢失的找回最常见的是执行了reset --hard之后发现改错了。别慌只要这个改动曾经被add过就还有救。用git reflog可以看到所有分支指针的移动记录找到操作前那个提交 ID然后git reset --hard 那个ID或者git cherry-pick把内容捞回来。reflog这个命令值得记住它是误操作之后的第一道保险默认保留几十天的记录。提示reflog只对已经进入 Git 对象库的内容有效。如果文件从头到尾没被add过就被删了Git 是不知道它存在过的这种情况只能靠系统级的文件恢复手段所以写代码勤提交就是最好的备份。7. 踩坑之后的几点个人体会我用这套工具也有些年头了回头看真正让我效率提升的不是学会了多少高级命令而是几个习惯。第一个习惯是开工前先拉取。不管昨天有没有人改进来先git pull把远程最新的改动同步下来再动手。我吃过最大的亏就是本地闷头改了一整天晚上推送时发现别人白天已经改过同一个文件冲突一大片重做了一遍。第二个习惯是提交前必看 status。这个动作只要五秒但能挡住绝大多数“不小心把配置、日志、测试数据提交上去”的事故。我现在的肌肉记忆是git add之后一定再跑一次git status确认清单里没有意外文件再敲提交。第三个习惯是分支要短命。功能分支开出来就尽快做完合并掉拖得越久主分支和它的差距越大合并时的冲突越难处理。我一般把一个功能控制在两三天内能合回去的规模如果实在做不完也要经常把主分支的更新合并进来别让它俩越走越远。最后一个体会是关于学习的顺序。我见过太多人一上来就啃变基、拣选、子模块这些进阶内容结果最基础的提交推送都磕磕绊绊。我的建议是先把克隆、拉取、提交、推送、分支这五件事练到不用想用上一两个月等这些操作不会打断你的思路了再去碰那些高级命令。到那时候你会发现很多高级操作其实是为了解决你真正遇到过的问题而存在的理解起来会顺畅得多。工具终究是为做事服务的够用、稳定、不添乱比什么都会一点更重要。