1. 从“版本管理”到“团队协作”为什么Git是绕不开的基石如果你刚开始接触编程或者刚加入一个技术团队听到最多的工具名字里一定有Git。它可能被描述为“版本控制工具”听起来有点抽象甚至有点枯燥。但我想用一个更贴近现实的比喻来解释Git就像是你写论文、做项目时那个永远不会丢失、可以随时回溯到任何一个历史瞬间的“超级时光机”和“并行宇宙生成器”。想象一下你正在写一份重要的报告。第一天你写了个初稿第二天你大刀阔斧地修改觉得焕然一新第三天你回头一看发现第二天的修改把一些核心论点改坏了但初稿的内容你也记不清了。这时候你多么希望有一个“后悔药”。Git就是这个“后悔药”。它把你每一次的修改我们称之为“提交”都完整地保存下来并打上标签。你可以随时回到上周二下午3点那个版本看看当时写了什么甚至可以基于那个版本开一个新的分支尝试另一种修改思路而完全不影响你现在的主线进度。这还只是个人使用场景。一旦进入团队协作Git的价值呈指数级放大。没有Git的时候团队协作代码可能是这样的小张改好了A文件用U盘拷给小李小李在A文件的基础上加了新功能然后发邮件给老王老王合并时发现冲突了三个人坐在一起对着屏幕一行行比对……效率低下错误百出。Git的出现让多人并行开发、代码合并、历史追溯变得井然有序。它定义了一套现代软件开发的协作流程。所以无论你是前端、后端、算法还是运维工程师Git都是你工具箱里最基础、也最必须的那一把螺丝刀。它不是一个“可选技能”而是一个“生存技能”。这篇教程的目的就是帮你把这把螺丝刀用得顺手、用得精通从安装配置到日常高频命令再到团队协作流程我会结合我过去十年里踩过的坑、总结的最佳实践带你彻底掌握Git。2. 环境准备不仅仅是“下一步”安装很多人觉得安装软件就是一路点击“Next”但Git的安装配置里有几个关键选择直接影响你后续的使用体验。我们分步骤来。2.1 获取Git安装包Git是开源软件官方下载地址是git-scm.com。对于Windows用户这里提供的是Git for Windows安装包它集成了Git Bash一个模拟Linux终端的环境和Git GUI图形界面。macOS用户可以通过Homebrew (brew install git) 或直接下载安装包。Linux用户通常通过包管理器安装如sudo apt-get install git(Ubuntu/Debian) 或sudo yum install git(CentOS/RHEL)。注意国内访问官方下载站可能速度较慢。一个可靠的替代方案是前往腾讯软件中心、华为开源镜像站等国内镜像源搜索“Git for Windows”进行下载确保版本较新即可。2.2 安装过程中的关键配置选项运行安装程序后你会遇到几个重要的配置页面它们不是无关紧要的。选择默认编辑器这是第一个容易踩坑的地方。Git在提交代码、解决冲突时需要你输入信息或编辑内容它会调用一个文本编辑器。默认选项可能是Vim。如果你不熟悉Vim它的操作模式是进入后需要按i才能输入按Esc后输入:wq才能保存退出那么在这里强烈建议你更改为Visual Studio Code或Notepad。以VSCode为例你需要确保VSCode的安装路径已添加到系统环境变量PATH中然后在这里选择Use Visual Studio Code as Gits default editor。这能避免你未来在终端里因为不会退出Vim而手足无措。调整PATH环境建议选择Git from the command line and also from 3rd-party software。这个选项会将Git的可执行文件添加到你的系统PATH环境变量中意味着你不仅能在Git Bash里使用git命令也能在Windows自带的CMD或PowerShell甚至VSCode的内置终端里直接使用git命令非常方便。选择HTTPS传输后端选择默认的OpenSSL即可。它负责处理与远程仓库如GitHub、Gitee通过HTTPS协议通信时的加密。配置行尾换行符转换这是跨平台协作的核心问题。Windows使用回车换行CRLF表示一行结束而Linux/macOS只使用换行LF。如果不对其进行统一会导致整个文件的每一行在差异对比时都显示被修改过污染提交历史。这里推荐选择Checkout Windows-style, commit Unix-style line endings。它的逻辑是当你从仓库拉取代码到本地Windows工作区时Git会自动将LF转换为CRLF方便你在Windows下编辑当你将代码提交到仓库时Git又会自动将CRLF转换回LF。这样仓库中永远保存的是LF格式保证了跨平台的一致性。如果你是纯macOS/Linux开发者可以选择Checkout as-is, commit Unix-style。选择终端模拟器建议选择Use MinTTY。MinTTY是Git Bash默认的终端它比Windows传统控制台ConHost功能更强大支持复制粘贴、更好的字体渲染等。2.3 安装后的第一步全局身份配置安装完成后在任意地方Git Bash、CMD、PowerShell打开终端第一件必须做的事是配置你的用户信息。这个信息会记录在你每一次提交记录里就像你写的每一行代码的“签名”。git config --global user.name 你的姓名或用户名 git config --global user.email 你的邮箱这里的邮箱强烈建议使用你在代码托管平台如GitHub、Gitee注册时使用的邮箱这样平台才能正确地将你的提交与账户关联起来显示你的头像和贡献度。--global参数表示这是全局配置会对本机所有Git仓库生效。你也可以在某个特定的仓库目录下使用不带--global的命令来覆盖全局配置为该仓库设置单独的作者信息但这种情况较少。你可以通过以下命令查看所有配置git config --list3. 核心概念理解Git的“三层存储”模型在狂记命令之前理解Git的核心工作模型至关重要。这能让你在遇到问题时知道该去哪里找答案而不是死记硬背命令。Git的本地仓库结构可以简化为三个区域或三种状态工作区就是你电脑上能直接看到的项目文件夹。你在这里新增、删除、修改文件。暂存区也叫索引区。这是一个中间状态你可以把工作区中准备要提交的更改通过git add命令“挑选”进来。暂存区就像是一个购物车你把这次想买提交的商品放进去。本地仓库通过git commit命令将暂存区里的所有内容打包成一个永久的、带描述的快照保存到本地仓库的历史记录中。这个快照就是一次“提交”。仓库就像是你家里的储物柜里面按顺序摆放着你历次购物提交的包裹。此外还有一个远程仓库比如放在GitHub、Gitee或公司内网GitLab上的仓库。它是团队共享和备份的中心节点。通过git push将本地仓库的提交推送到远程通过git pull或git fetch将远程的更新拉取到本地。这个“工作区 - 暂存区 - 本地仓库 - 远程仓库”的流程是Git最基本的数据流。所有的命令都是围绕在这几个区域之间移动数据而设计的。4. 单人开发实战从零开始一个本地项目让我们抛开团队先看一个人如何用Git管理自己的项目。假设你要创建一个名为my-project的个人学习项目。4.1 创建仓库与首次提交首先在你喜欢的位置创建一个文件夹并进入。mkdir my-project cd my-project接下来将这个目录初始化为一个Git仓库。这个命令会在当前目录下创建一个隐藏的.git文件夹它是Git的“数据库”所有版本信息都存储在这里。git init现在你的my-project目录就是一个Git工作区了。你可以开始创建文件比如一个README.md。echo # My First Git Project README.md使用git status命令查看当前状态。这是你最常用的命令之一它能告诉你工作区和暂存区发生了什么。git status输出会显示Untracked files: README.md意思是Git发现了一个新文件但还没有开始跟踪它。要跟踪这个文件需要把它添加到暂存区git add README.md再次运行git status你会看到Changes to be committed: new file: README.md。这说明README.md已经在购物车暂存区里了。最后将暂存区的内容提交到本地仓库创建一个快照git commit -m Initial commit: add README file-m参数后面是本次提交的说明信息。提交信息至关重要好的提交信息应该像一句简短的祈使句说明这次提交“做了什么”例如“修复登录按钮点击无效的bug”、“添加用户注册API接口”。避免使用“更新了代码”这种模糊的描述。4.2 文件修改、撤销与历史查看现在修改一下README.md文件增加一些内容。然后再次查看状态git status会显示Changes not staged for commit: modified: README.md。这意味着文件被修改了但修改还没有被放入暂存区。你可以再次git add README.md来暂存这次修改。但这里我想引入一个更高效的命令git add .或git add -A。它们会将工作区中所有的更改新增、修改、删除全部添加到暂存区。在单人开发、确认所有改动都需要提交时用这个非常方便。提交后如何查看历史记录使用git loggit log --oneline--oneline参数让输出更简洁只显示提交哈希值的前7位和提交信息。你会看到类似这样的输出a1b2c3d (HEAD - main) Add project description f4e5g6h Initial commit: add README file这里的HEAD是一个指针它指向你当前所在的本地分支这里是main的最新提交。常见场景如何撤销更改场景一修改了文件但还没git add还在工作区想丢弃这些修改回到上次提交的状态。git checkout -- README.md这个命令有点危险因为它会永久丢弃工作区中对指定文件的修改且不可恢复。用之前请确认。场景二已经git add到了暂存区但还没commit想将文件从暂存区撤回到工作区即取消暂存。git reset HEAD README.md这条命令执行后README.md的修改依然存在于工作区但状态变回了“未暂存”。场景三已经commit了但发现提交信息写错了或者漏了文件想重做最后一次提交。git commit --amend -m 新的提交信息这个命令会修改最后一次提交。如果你只是漏了文件可以先git add漏掉的文件再执行git commit --amend这样漏掉的文件就会被合并到上一次提交中而不会产生一个新的提交记录。注意如果已经推送到远程仓库谨慎使用--amend因为这会改变历史需要强制推送可能会给协作者带来麻烦。4.3 理解分支低成本试错的利器分支是Git的“杀手级”特性。你可以把分支想象成一条独立的时间线。默认情况下你工作在main旧版本可能是master分支上这是你的主线。假设你正在开发一个稳定的v1.0功能突然想尝试一个激进的新特性比如把整个界面重写。你不敢直接在主线上修改怕搞砸。这时就可以创建一个新分支git branch feature-redesign # 创建一个名为 feature-redesign 的新分支 git checkout feature-redesign # 切换到新分支或者用一条更简洁的命令git checkout -b feature-redesign # 创建并切换到新分支现在你在feature-redesign分支上的所有提交都不会影响main分支。你可以在这个分支上大胆地修改、提交。如果实验成功你可以将这个分支合并回main分支如果失败直接删除这个分支即可main分支毫发无损。使用git branch命令可以查看所有本地分支当前分支前会有一个*号。5. 团队协作核心远程仓库与Pull Request个人玩转本地仓库只是第一步Git真正的威力在于团队协作。这离不开远程仓库。5.1 关联远程仓库与推送通常你会在GitHub、Gitee或公司的GitLab上创建一个空的远程仓库。创建好后它会提供仓库的HTTPS或SSH地址。假设你本地已经有了一个初始化的项目my-project现在想把它推送到远程。首先你需要告诉本地仓库远程仓库的地址在哪里这个地址我们给它起个名字通常叫origin起源约定俗成的默认名。git remote add origin https://github.com/yourname/my-project.gitgit remote -v可以查看已关联的远程仓库地址。接下来将本地的main分支推送到远程的origin仓库并建立追踪关系git push -u origin main-u参数是--set-upstream的简写它建立了本地main分支与远程origin/main分支的关联。之后在这个分支上你只需要简单地输入git push或git pullGit就知道是和origin/main交互。5.2 克隆、拉取与冲突解决当你要参与一个已存在的项目时第一步是克隆git clone https://github.com/someone/awesome-project.git这条命令会做两件事1. 将整个远程仓库下载到本地2. 自动创建一个名为origin的远程地址指向源仓库3. 自动切换到默认分支通常是main。在团队中远程仓库的代码在不断更新。在你开始工作前和提交前都应该先拉取最新的代码到本地避免基于过时的代码开发。git pull origin maingit pull实际上是git fetch获取远程更新 git merge合并到当前分支 两个操作的组合。冲突是团队协作的必修课。当你和同事修改了同一文件的同一区域Git无法自动决定保留谁的修改时就会产生冲突。执行git pull后如果遇到冲突Git会中断合并并在冲突文件中用特殊标记标出冲突内容 HEAD 你的代码 同事的代码 branch-name你需要手动编辑这个文件保留你想要的部分或者整合两部分删除这些标记。解决完所有冲突文件后使用git add标记它们为已解决然后完成合并提交git add . git commit -m Merge branch main and resolve conflicts5.3 协作流程Fork Pull Request / Merge Request在开源项目或公司使用GitLab/Gitee的企业中最常用的协作模式不是直接向主仓库推送而是通过Fork Pull Request。Fork在GitHub上你点击项目页面的“Fork”按钮这会在你的个人账户下创建一个原项目的完整副本。克隆你自己的Forkgit clone https://github.com/YOURNAME/awesome-project.git创建特性分支git checkout -b fix-typo进行修改并提交修改代码git add,git commit。推送到你的Forkgit push origin fix-typo发起Pull Request在你的Fork仓库页面GitHub会提示你刚刚推送了分支你可以点击“Compare pull request”按钮。填写PR描述说明你的修改目的和内容然后提交给原项目的维护者审核。代码评审与合并维护者审核你的代码提出修改意见。你可以在原分支上继续提交推送后PR会自动更新。审核通过后维护者将你的PR合并到原项目的主分支。这套流程通过代码评审保证了代码质量是开源协作和现代企业开发的黄金标准。6. 进阶技巧与高效命令掌握了基础下面这些命令能极大提升你的效率。git stash临时储藏更改。当你正在一个分支上修改代码突然需要切换到另一个分支处理紧急bug而当前修改又没完成、不想提交。这时可以用git stash把工作区和暂存区的改动“藏起来”让你的工作目录恢复干净。处理完bug后切回原分支执行git stash pop把藏起来的改动恢复出来。git diff查看差异。git diff查看工作区和暂存区的差异git diff --staged查看暂存区和上一次提交的差异git diff HEAD查看工作区和上一次提交的差异。这是代码审查和自查的神器。.gitignore文件一个必须掌握的文件。它告诉Git哪些文件或目录不需要纳入版本管理比如编译产物node_modules/,dist/、本地配置文件、IDE配置文件.vscode/,.idea/、日志文件等。在项目根目录创建这个文件并写入相应的匹配规则可以保持仓库的清洁。例如# 忽略所有 .log 文件 *.log # 忽略 node_modules 目录 node_modules/ # 忽略本地环境配置文件但保留示例文件 .env !.env.examplegit log图形化与过滤git log --oneline --graph --all可以以文本图形的方式展示所有分支的合并历史非常直观。git log -p可以显示每次提交具体修改了哪些内容。交互式变基这是一个高级但强大的功能用于整理提交历史。git rebase -i HEAD~3可以让你对最近的三次提交进行重新排序、合并、修改提交信息等操作。警告同样如果提交已经推送到远程共享分支不要使用rebase来修改历史。7. 实战避坑指南那些我踩过的“坑”最后分享几个从痛苦经历中总结出的经验希望能帮你节省时间。提交信息敷衍了事这是新手和老手都容易犯的错。半年后回头看看到“update”这样的提交信息你完全想不起当时改了啥。强制自己使用清晰的祈使句。许多团队会约定提交信息格式例如“[feat] 新增用户登录功能”、“[fix] 修复首页图片加载失败的问题”。什么都往仓库里塞把node_modules、.DS_Store、*.log这类文件提交上去会让仓库体积暴涨克隆速度变慢。项目一开始就创建并配置好.gitignore文件。可以在gitignore.io这个网站根据你的开发语言和工具生成模板。在错误的分支上开发切分支前务必用git branch或git status确认当前所在分支。养成“先切分支再写代码”的习惯。git pull前有未提交的更改如果本地有未提交的修改git pull可能会失败或导致自动合并产生混乱。在拉取代码前先提交commit或储藏stash你的本地更改。对已推送的共享提交进行amend或rebase这相当于改写了公共历史会导致其他协作者基于旧历史的开发出现严重问题。黄金法则只对尚未推送到远程的本地提交进行历史改写操作。对于共享分支宁愿多一次提交也不要强行修改历史。Git的学习曲线前期可能有些陡峭但一旦你理解了它的工作模型并熟练使用那20%的核心命令它就会成为你开发过程中如呼吸般自然的存在。最好的学习方式就是立即动手创建一个仓库从init,add,commit开始模拟各种场景。遇到问题多查文档git --help或git help多思考命令背后的意图。坚持下去你会发现自己对代码的掌控力达到了一个新的层次。 Git入门到精通：从版本控制到团队协作的完整指南
1. 从“版本管理”到“团队协作”为什么Git是绕不开的基石如果你刚开始接触编程或者刚加入一个技术团队听到最多的工具名字里一定有Git。它可能被描述为“版本控制工具”听起来有点抽象甚至有点枯燥。但我想用一个更贴近现实的比喻来解释Git就像是你写论文、做项目时那个永远不会丢失、可以随时回溯到任何一个历史瞬间的“超级时光机”和“并行宇宙生成器”。想象一下你正在写一份重要的报告。第一天你写了个初稿第二天你大刀阔斧地修改觉得焕然一新第三天你回头一看发现第二天的修改把一些核心论点改坏了但初稿的内容你也记不清了。这时候你多么希望有一个“后悔药”。Git就是这个“后悔药”。它把你每一次的修改我们称之为“提交”都完整地保存下来并打上标签。你可以随时回到上周二下午3点那个版本看看当时写了什么甚至可以基于那个版本开一个新的分支尝试另一种修改思路而完全不影响你现在的主线进度。这还只是个人使用场景。一旦进入团队协作Git的价值呈指数级放大。没有Git的时候团队协作代码可能是这样的小张改好了A文件用U盘拷给小李小李在A文件的基础上加了新功能然后发邮件给老王老王合并时发现冲突了三个人坐在一起对着屏幕一行行比对……效率低下错误百出。Git的出现让多人并行开发、代码合并、历史追溯变得井然有序。它定义了一套现代软件开发的协作流程。所以无论你是前端、后端、算法还是运维工程师Git都是你工具箱里最基础、也最必须的那一把螺丝刀。它不是一个“可选技能”而是一个“生存技能”。这篇教程的目的就是帮你把这把螺丝刀用得顺手、用得精通从安装配置到日常高频命令再到团队协作流程我会结合我过去十年里踩过的坑、总结的最佳实践带你彻底掌握Git。2. 环境准备不仅仅是“下一步”安装很多人觉得安装软件就是一路点击“Next”但Git的安装配置里有几个关键选择直接影响你后续的使用体验。我们分步骤来。2.1 获取Git安装包Git是开源软件官方下载地址是git-scm.com。对于Windows用户这里提供的是Git for Windows安装包它集成了Git Bash一个模拟Linux终端的环境和Git GUI图形界面。macOS用户可以通过Homebrew (brew install git) 或直接下载安装包。Linux用户通常通过包管理器安装如sudo apt-get install git(Ubuntu/Debian) 或sudo yum install git(CentOS/RHEL)。注意国内访问官方下载站可能速度较慢。一个可靠的替代方案是前往腾讯软件中心、华为开源镜像站等国内镜像源搜索“Git for Windows”进行下载确保版本较新即可。2.2 安装过程中的关键配置选项运行安装程序后你会遇到几个重要的配置页面它们不是无关紧要的。选择默认编辑器这是第一个容易踩坑的地方。Git在提交代码、解决冲突时需要你输入信息或编辑内容它会调用一个文本编辑器。默认选项可能是Vim。如果你不熟悉Vim它的操作模式是进入后需要按i才能输入按Esc后输入:wq才能保存退出那么在这里强烈建议你更改为Visual Studio Code或Notepad。以VSCode为例你需要确保VSCode的安装路径已添加到系统环境变量PATH中然后在这里选择Use Visual Studio Code as Gits default editor。这能避免你未来在终端里因为不会退出Vim而手足无措。调整PATH环境建议选择Git from the command line and also from 3rd-party software。这个选项会将Git的可执行文件添加到你的系统PATH环境变量中意味着你不仅能在Git Bash里使用git命令也能在Windows自带的CMD或PowerShell甚至VSCode的内置终端里直接使用git命令非常方便。选择HTTPS传输后端选择默认的OpenSSL即可。它负责处理与远程仓库如GitHub、Gitee通过HTTPS协议通信时的加密。配置行尾换行符转换这是跨平台协作的核心问题。Windows使用回车换行CRLF表示一行结束而Linux/macOS只使用换行LF。如果不对其进行统一会导致整个文件的每一行在差异对比时都显示被修改过污染提交历史。这里推荐选择Checkout Windows-style, commit Unix-style line endings。它的逻辑是当你从仓库拉取代码到本地Windows工作区时Git会自动将LF转换为CRLF方便你在Windows下编辑当你将代码提交到仓库时Git又会自动将CRLF转换回LF。这样仓库中永远保存的是LF格式保证了跨平台的一致性。如果你是纯macOS/Linux开发者可以选择Checkout as-is, commit Unix-style。选择终端模拟器建议选择Use MinTTY。MinTTY是Git Bash默认的终端它比Windows传统控制台ConHost功能更强大支持复制粘贴、更好的字体渲染等。2.3 安装后的第一步全局身份配置安装完成后在任意地方Git Bash、CMD、PowerShell打开终端第一件必须做的事是配置你的用户信息。这个信息会记录在你每一次提交记录里就像你写的每一行代码的“签名”。git config --global user.name 你的姓名或用户名 git config --global user.email 你的邮箱这里的邮箱强烈建议使用你在代码托管平台如GitHub、Gitee注册时使用的邮箱这样平台才能正确地将你的提交与账户关联起来显示你的头像和贡献度。--global参数表示这是全局配置会对本机所有Git仓库生效。你也可以在某个特定的仓库目录下使用不带--global的命令来覆盖全局配置为该仓库设置单独的作者信息但这种情况较少。你可以通过以下命令查看所有配置git config --list3. 核心概念理解Git的“三层存储”模型在狂记命令之前理解Git的核心工作模型至关重要。这能让你在遇到问题时知道该去哪里找答案而不是死记硬背命令。Git的本地仓库结构可以简化为三个区域或三种状态工作区就是你电脑上能直接看到的项目文件夹。你在这里新增、删除、修改文件。暂存区也叫索引区。这是一个中间状态你可以把工作区中准备要提交的更改通过git add命令“挑选”进来。暂存区就像是一个购物车你把这次想买提交的商品放进去。本地仓库通过git commit命令将暂存区里的所有内容打包成一个永久的、带描述的快照保存到本地仓库的历史记录中。这个快照就是一次“提交”。仓库就像是你家里的储物柜里面按顺序摆放着你历次购物提交的包裹。此外还有一个远程仓库比如放在GitHub、Gitee或公司内网GitLab上的仓库。它是团队共享和备份的中心节点。通过git push将本地仓库的提交推送到远程通过git pull或git fetch将远程的更新拉取到本地。这个“工作区 - 暂存区 - 本地仓库 - 远程仓库”的流程是Git最基本的数据流。所有的命令都是围绕在这几个区域之间移动数据而设计的。4. 单人开发实战从零开始一个本地项目让我们抛开团队先看一个人如何用Git管理自己的项目。假设你要创建一个名为my-project的个人学习项目。4.1 创建仓库与首次提交首先在你喜欢的位置创建一个文件夹并进入。mkdir my-project cd my-project接下来将这个目录初始化为一个Git仓库。这个命令会在当前目录下创建一个隐藏的.git文件夹它是Git的“数据库”所有版本信息都存储在这里。git init现在你的my-project目录就是一个Git工作区了。你可以开始创建文件比如一个README.md。echo # My First Git Project README.md使用git status命令查看当前状态。这是你最常用的命令之一它能告诉你工作区和暂存区发生了什么。git status输出会显示Untracked files: README.md意思是Git发现了一个新文件但还没有开始跟踪它。要跟踪这个文件需要把它添加到暂存区git add README.md再次运行git status你会看到Changes to be committed: new file: README.md。这说明README.md已经在购物车暂存区里了。最后将暂存区的内容提交到本地仓库创建一个快照git commit -m Initial commit: add README file-m参数后面是本次提交的说明信息。提交信息至关重要好的提交信息应该像一句简短的祈使句说明这次提交“做了什么”例如“修复登录按钮点击无效的bug”、“添加用户注册API接口”。避免使用“更新了代码”这种模糊的描述。4.2 文件修改、撤销与历史查看现在修改一下README.md文件增加一些内容。然后再次查看状态git status会显示Changes not staged for commit: modified: README.md。这意味着文件被修改了但修改还没有被放入暂存区。你可以再次git add README.md来暂存这次修改。但这里我想引入一个更高效的命令git add .或git add -A。它们会将工作区中所有的更改新增、修改、删除全部添加到暂存区。在单人开发、确认所有改动都需要提交时用这个非常方便。提交后如何查看历史记录使用git loggit log --oneline--oneline参数让输出更简洁只显示提交哈希值的前7位和提交信息。你会看到类似这样的输出a1b2c3d (HEAD - main) Add project description f4e5g6h Initial commit: add README file这里的HEAD是一个指针它指向你当前所在的本地分支这里是main的最新提交。常见场景如何撤销更改场景一修改了文件但还没git add还在工作区想丢弃这些修改回到上次提交的状态。git checkout -- README.md这个命令有点危险因为它会永久丢弃工作区中对指定文件的修改且不可恢复。用之前请确认。场景二已经git add到了暂存区但还没commit想将文件从暂存区撤回到工作区即取消暂存。git reset HEAD README.md这条命令执行后README.md的修改依然存在于工作区但状态变回了“未暂存”。场景三已经commit了但发现提交信息写错了或者漏了文件想重做最后一次提交。git commit --amend -m 新的提交信息这个命令会修改最后一次提交。如果你只是漏了文件可以先git add漏掉的文件再执行git commit --amend这样漏掉的文件就会被合并到上一次提交中而不会产生一个新的提交记录。注意如果已经推送到远程仓库谨慎使用--amend因为这会改变历史需要强制推送可能会给协作者带来麻烦。4.3 理解分支低成本试错的利器分支是Git的“杀手级”特性。你可以把分支想象成一条独立的时间线。默认情况下你工作在main旧版本可能是master分支上这是你的主线。假设你正在开发一个稳定的v1.0功能突然想尝试一个激进的新特性比如把整个界面重写。你不敢直接在主线上修改怕搞砸。这时就可以创建一个新分支git branch feature-redesign # 创建一个名为 feature-redesign 的新分支 git checkout feature-redesign # 切换到新分支或者用一条更简洁的命令git checkout -b feature-redesign # 创建并切换到新分支现在你在feature-redesign分支上的所有提交都不会影响main分支。你可以在这个分支上大胆地修改、提交。如果实验成功你可以将这个分支合并回main分支如果失败直接删除这个分支即可main分支毫发无损。使用git branch命令可以查看所有本地分支当前分支前会有一个*号。5. 团队协作核心远程仓库与Pull Request个人玩转本地仓库只是第一步Git真正的威力在于团队协作。这离不开远程仓库。5.1 关联远程仓库与推送通常你会在GitHub、Gitee或公司的GitLab上创建一个空的远程仓库。创建好后它会提供仓库的HTTPS或SSH地址。假设你本地已经有了一个初始化的项目my-project现在想把它推送到远程。首先你需要告诉本地仓库远程仓库的地址在哪里这个地址我们给它起个名字通常叫origin起源约定俗成的默认名。git remote add origin https://github.com/yourname/my-project.gitgit remote -v可以查看已关联的远程仓库地址。接下来将本地的main分支推送到远程的origin仓库并建立追踪关系git push -u origin main-u参数是--set-upstream的简写它建立了本地main分支与远程origin/main分支的关联。之后在这个分支上你只需要简单地输入git push或git pullGit就知道是和origin/main交互。5.2 克隆、拉取与冲突解决当你要参与一个已存在的项目时第一步是克隆git clone https://github.com/someone/awesome-project.git这条命令会做两件事1. 将整个远程仓库下载到本地2. 自动创建一个名为origin的远程地址指向源仓库3. 自动切换到默认分支通常是main。在团队中远程仓库的代码在不断更新。在你开始工作前和提交前都应该先拉取最新的代码到本地避免基于过时的代码开发。git pull origin maingit pull实际上是git fetch获取远程更新 git merge合并到当前分支 两个操作的组合。冲突是团队协作的必修课。当你和同事修改了同一文件的同一区域Git无法自动决定保留谁的修改时就会产生冲突。执行git pull后如果遇到冲突Git会中断合并并在冲突文件中用特殊标记标出冲突内容 HEAD 你的代码 同事的代码 branch-name你需要手动编辑这个文件保留你想要的部分或者整合两部分删除这些标记。解决完所有冲突文件后使用git add标记它们为已解决然后完成合并提交git add . git commit -m Merge branch main and resolve conflicts5.3 协作流程Fork Pull Request / Merge Request在开源项目或公司使用GitLab/Gitee的企业中最常用的协作模式不是直接向主仓库推送而是通过Fork Pull Request。Fork在GitHub上你点击项目页面的“Fork”按钮这会在你的个人账户下创建一个原项目的完整副本。克隆你自己的Forkgit clone https://github.com/YOURNAME/awesome-project.git创建特性分支git checkout -b fix-typo进行修改并提交修改代码git add,git commit。推送到你的Forkgit push origin fix-typo发起Pull Request在你的Fork仓库页面GitHub会提示你刚刚推送了分支你可以点击“Compare pull request”按钮。填写PR描述说明你的修改目的和内容然后提交给原项目的维护者审核。代码评审与合并维护者审核你的代码提出修改意见。你可以在原分支上继续提交推送后PR会自动更新。审核通过后维护者将你的PR合并到原项目的主分支。这套流程通过代码评审保证了代码质量是开源协作和现代企业开发的黄金标准。6. 进阶技巧与高效命令掌握了基础下面这些命令能极大提升你的效率。git stash临时储藏更改。当你正在一个分支上修改代码突然需要切换到另一个分支处理紧急bug而当前修改又没完成、不想提交。这时可以用git stash把工作区和暂存区的改动“藏起来”让你的工作目录恢复干净。处理完bug后切回原分支执行git stash pop把藏起来的改动恢复出来。git diff查看差异。git diff查看工作区和暂存区的差异git diff --staged查看暂存区和上一次提交的差异git diff HEAD查看工作区和上一次提交的差异。这是代码审查和自查的神器。.gitignore文件一个必须掌握的文件。它告诉Git哪些文件或目录不需要纳入版本管理比如编译产物node_modules/,dist/、本地配置文件、IDE配置文件.vscode/,.idea/、日志文件等。在项目根目录创建这个文件并写入相应的匹配规则可以保持仓库的清洁。例如# 忽略所有 .log 文件 *.log # 忽略 node_modules 目录 node_modules/ # 忽略本地环境配置文件但保留示例文件 .env !.env.examplegit log图形化与过滤git log --oneline --graph --all可以以文本图形的方式展示所有分支的合并历史非常直观。git log -p可以显示每次提交具体修改了哪些内容。交互式变基这是一个高级但强大的功能用于整理提交历史。git rebase -i HEAD~3可以让你对最近的三次提交进行重新排序、合并、修改提交信息等操作。警告同样如果提交已经推送到远程共享分支不要使用rebase来修改历史。7. 实战避坑指南那些我踩过的“坑”最后分享几个从痛苦经历中总结出的经验希望能帮你节省时间。提交信息敷衍了事这是新手和老手都容易犯的错。半年后回头看看到“update”这样的提交信息你完全想不起当时改了啥。强制自己使用清晰的祈使句。许多团队会约定提交信息格式例如“[feat] 新增用户登录功能”、“[fix] 修复首页图片加载失败的问题”。什么都往仓库里塞把node_modules、.DS_Store、*.log这类文件提交上去会让仓库体积暴涨克隆速度变慢。项目一开始就创建并配置好.gitignore文件。可以在gitignore.io这个网站根据你的开发语言和工具生成模板。在错误的分支上开发切分支前务必用git branch或git status确认当前所在分支。养成“先切分支再写代码”的习惯。git pull前有未提交的更改如果本地有未提交的修改git pull可能会失败或导致自动合并产生混乱。在拉取代码前先提交commit或储藏stash你的本地更改。对已推送的共享提交进行amend或rebase这相当于改写了公共历史会导致其他协作者基于旧历史的开发出现严重问题。黄金法则只对尚未推送到远程的本地提交进行历史改写操作。对于共享分支宁愿多一次提交也不要强行修改历史。Git的学习曲线前期可能有些陡峭但一旦你理解了它的工作模型并熟练使用那20%的核心命令它就会成为你开发过程中如呼吸般自然的存在。最好的学习方式就是立即动手创建一个仓库从init,add,commit开始模拟各种场景。遇到问题多查文档git --help或git help多思考命令背后的意图。坚持下去你会发现自己对代码的掌控力达到了一个新的层次。