1. 项目概述为什么每个开发者都绕不开Git如果你刚入行或者正准备踏入软件开发这个领域听到“Git”这个词的频率可能仅次于“Hello World”。它不是一个炫酷的新框架也不是一个能直接产出漂亮界面的工具但它却是现代软件开发的基石是连接你与全球数百万开发者协作网络的桥梁。简单来说Git是一个分布式版本控制系统。但“版本控制”这四个字背后藏着的是我们每天开发中那些最琐碎又最要命的痛点昨天改好的代码今天想回退怎么办两个人同时改了同一个文件怎么合并怎么知道这个功能是哪个版本引入的Bug我见过太多新手一开始对Git敬而远之只会在图形化界面里点“提交”和“推送”一旦遇到冲突Conflict就手足无措甚至有人用复制文件夹的方式来“备份”版本。这就像用记事本写长篇论文没有撤销没有历史记录没有协作可能。而Git就是给你的代码世界加上了一个“时光机”和“平行宇宙管理器”。它记录每一次修改Commit允许你创建独立的分支Branch进行试验并能优雅地合并Merge成果。从个人项目到像Linux内核这样超大规模的开源协作Git都是事实上的标准。所以无论你是前端、后端、移动端还是算法工程师无论你用Windows、macOS还是LinuxGit都是你工具箱里必须熟练使用的第一把“螺丝刀”。接下来的内容我会从一个多年一线开发者的视角带你从零开始不仅学会Git的基本操作更理解其设计哲学和在实际工作中如何高效、安全地使用它避开那些我早期踩过的坑。2. 核心概念与工作流解析理解Git的“世界观”在动手敲命令之前花点时间理解Git的核心思想至关重要。这能让你在遇到问题时不是死记硬背命令而是知道该朝哪个方向思考。2.1 仓库、工作区、暂存区与版本库这是Git最核心的四个概念理解了它们就理解了Git大半的工作方式。仓库Repository 一个被Git管理的项目目录里面包含所有的项目文件和Git的历史记录数据。它通常对应你本地的一个文件夹或者远程服务器如GitHub、Gitee上的一个项目地址。工作区Working Directory 就是你电脑上能直接看到、编辑的那些文件。你在这里进行增删改查。暂存区Staging Area / Index 这是一个非常关键且独特的概念。你可以把它想象成一个“准备台”或“购物车”。工作区的改动不会直接进入版本历史你需要先通过git add命令将改动“放入”暂存区。这允许你对提交进行精细控制比如只提交某个功能的修改而忽略调试时临时加的打印语句。版本库Repository特指.git目录 本地仓库根目录下的.git隐藏文件夹。这是Git的“数据库”你所有的提交历史、分支信息、标签等都存储在这里。千万不要手动修改这个文件夹里的内容。工作流程可以概括为工作区 - (git add) - 暂存区 - (git commit) - 版本库。提示很多新手困惑于“为什么改了文件还要git add”。这正是Git设计的精妙之处——它让你有机会在提交前“预览”和“组装”你的这次提交。比如你同时修复了两个Bug但想分成两次提交记录就可以分别add对应的文件再commit。2.2 提交、分支与合并提交Commit 一次提交就是一次版本快照。它包含了暂存区里所有文件的当前状态、提交者信息、时间戳和一个唯一的哈希值如a1b2c3d。每次提交都会指向它的父提交形成一条历史链。分支Branch 分支本质上只是一个指向某个提交的轻量级可移动指针。默认的主分支通常叫main或master。创建新分支如git branch feature-login几乎零成本因为它只是新建了一个指针。你可以在新分支上独立开发而不会影响主分支。合并Merge 将一个分支的修改整合到另一个分支的过程。最常用的场景是将功能分支合并回主分支。Git会尝试自动合并如果两个分支修改了同一文件的同一区域则会产生“冲突”需要人工解决。2.3 分布式 vs 集中式这是Git与SVN等旧式版本控制系统的根本区别。在Git中每个开发者的本地仓库都是一个完整的版本库拥有全部历史记录。远程仓库如GitHub只是大家同步变更的一个公共节点。这意味着你可以在飞机上、在没有网络的地方自由地提交、创建分支、查看历史。网络只是在你需要与他人同步push/pull时才需要。这种设计带来了极强的健壮性和灵活性。3. 从零开始Git的安装与基础配置3.1 跨平台安装指南Git官方支持所有主流平台。我强烈建议从官网下载以确保版本最新和安全。Windows 访问 git-scm.com 下载.exe安装包。安装过程基本一路“Next”但有几个关键选项选择默认编辑器 安装程序会提示“Choosing the default editor used by Git”。对于大多数中国开发者如果习惯用VSCode可以在这里修改路径指向VSCode的code命令需要提前将VSCode加入系统PATH。如果留空或选择其他不熟悉的编辑器如Vim后续在终端里触发编辑提交信息时可能会手足无措。对于纯新手可以选择“Use Windows‘ default console editor”或记事本Notepad作为起步。调整PATH环境 建议选择“Git from the command line and also from 3rd-party software”这样既能在CMD/PowerShell中使用Git也能被其他软件如IDE调用。换行符处理 选择“Checkout Windows-style, commit Unix-style line endings”推荐。这能最大程度避免Windows和Unix/Linux系统之间因换行符CRLF vs LF不同导致的文件“被全部修改”的假象。macOS 最简单的方法是安装Homebrew包管理器然后执行brew install git。也可以从官网下载.pkg安装包。Linux (Ubuntu/Debian) 使用包管理器如sudo apt update sudo apt install git。安装完成后打开终端Windows上叫Git Bash或CMD/PowerShell输入git --version看到版本号即表示安装成功。3.2 必不可少的初始配置安装后第一件事是配置你的用户身份这个信息会写入你的每一次提交是责任的体现。# 设置全局用户名和邮箱--global表示对所有仓库生效 git config --global user.name 你的姓名 git config --global user.email 你的邮箱example.com # 检查配置 git config --global --list实操心得 邮箱最好使用你常用的、真实的邮箱特别是在公司或开源项目中这便于协作沟通。如果你有多个身份例如公司项目和个人项目使用不同邮箱可以在具体的仓库目录下执行不带--global的命令进行局部覆盖。常用配置优化# 让命令行输出带颜色更易读 git config --global color.ui auto # 设置默认分支名为 main更中立的名称 git config --global init.defaultBranch main # 为常用命令设置别名提升效率 git config --global alias.st status # git st 代替 git status git config --global alias.co checkout # git co 代替 git checkout git config --global alias.br branch # git br 代替 git branch git config --global alias.ci commit # git ci 代替 git commit git config --global alias.unstage reset HEAD -- # git unstage file 撤销暂存4. 日常开发核心命令全解与实战掌握了概念和配置我们进入实战环节。下面这些命令构成了你90%的日常Git操作。4.1 仓库创建与克隆git init 在当前目录初始化一个新的Git仓库。执行后会产生一个.git文件夹。mkdir my-project cd my-project git initgit clone 这是你接触开源项目或加入团队项目最常用的方式。它会把远程仓库的整个历史和数据复制到本地。# 克隆一个远程仓库 git clone https://github.com/username/repo.git # 克隆到指定目录 git clone https://github.com/username/repo.git my-local-folder4.2 文件状态管理与提交这是最核心的循环修改 - 暂存 - 提交。git status 你的“仪表盘”。随时运行它查看工作区和暂存区的状态。哪些文件被修改了modified但未暂存哪些文件是新创建的untracked哪些文件已暂存staged准备提交一目了然。git add 将文件从工作区放入暂存区。git add file.txt # 添加单个文件 git add src/ # 添加整个目录 git add . # 添加当前目录下所有变更最常用但需谨慎 git add -p # 交互式暂存可以按代码块hunk选择性添加非常强大注意git add .会添加所有未跟踪和已修改的文件。在提交前务必用git status确认暂存区的内容是否是你想要的避免提交了临时文件或配置文件。git commit 将暂存区的内容创建一个永久的快照保存到版本库。git commit -m “修复了用户登录失败的Bug” # -m 后直接跟提交信息提交信息规范 好的提交信息至关重要。建议采用类似“类型: 简短描述”的格式例如feat: 新增用户头像上传功能fix: 修复首页在iOS下的滚动卡顿docs: 更新API接口文档style: 调整代码格式无功能变化refactor: 重构用户认证模块这能让历史记录清晰可读也便于工具自动生成更新日志。git restore与git reset 撤销操作。git restore --staged file 将文件从暂存区撤回到工作区取消git add。git restore file 丢弃工作区对某个文件的修改恢复到最近一次提交或暂存的状态危险操作未提交的修改会丢失。git reset HEAD~1软重置。撤销最近一次提交但保留工作区的修改。相当于提交错了但改动的代码还想留着。git reset --hard HEAD~1硬重置。彻底撤销最近一次提交并且丢弃工作区的所有相关修改。非常危险除非确定不需要那些改动否则慎用。4.3 分支操作与合并策略分支是Git的“杀手级”功能让你能并行开发多个功能。git branch 查看、创建、删除分支。git branch # 列出所有本地分支当前分支前有* git branch feature-xxx # 创建名为feature-xxx的新分支 git branch -d feature-xxx # 删除已合并的分支 git branch -D feature-xxx # 强制删除未合并的分支git checkout与git switch 切换分支。git checkout feature-xxx 切换到feature-xxx分支较老的命令功能多但易混淆。git switch feature-xxx Git 2.23版本引入的专用于切换分支的命令更清晰。推荐使用。git switch -c new-feature 创建并切换到新分支-c代表create。git merge 合并分支。通常我们在功能开发完成后切换回主分支进行合并。git switch main # 首先确保你在主分支上 git merge feature-login # 将feature-login分支合并到当前分支main合并冲突解决 如果两个分支修改了同一处Git无法自动合并会标记为冲突状态。文件内会有类似 HEAD,, feature-login的标记。你需要手动编辑文件保留想要的代码删除这些标记然后执行git add 解决后的文件和git commit来完成合并。git rebase 变基。另一个整合分支变化的方法。它会把当前分支的提交“重新播放”在目标分支的最新提交之后从而产生一条更线性的历史。黄金法则不要在公共分支如main上执行rebase只对你自己的本地分支使用。git switch feature-xxx git rebase main # 将feature-xxx的修改“挪到”main分支的最新提交之后Rebase过程中也可能遇到冲突解决方式与merge类似解决后执行git rebase --continue。4.4 查看历史与版本穿梭git log 查看提交历史。我常用一些美化参数git log --oneline --graph --all --decorate # --oneline 单行显示 # --graph 图形化显示分支合并历史 # --all 显示所有分支 # --decorate 显示分支和标签名git diff 查看差异。git diff # 工作区与暂存区的差异 git diff --staged # 暂存区与最新提交的差异 git diff HEAD~2 HEAD # 比较两个历史提交 git diff branchA..branchB # 比较两个分支的最新提交5. 远程协作Push, Pull, Fetch 与团队工作流个人开发在本地即可但团队协作离不开远程仓库。5.1 远程仓库关联与同步git remote 管理远程仓库地址。克隆项目后默认的远程仓库别名是origin。git remote -v # 查看远程仓库地址 git remote add upstream https://github.com/original/repo.git # 添加上游仓库常用于Fork的项目git fetch下载远程仓库的最新数据提交、分支等到本地但不自动合并到你的工作分支。这是一个安全的操作让你先看看别人做了什么。git fetch origin # 从origin远程仓库获取更新git pull下载并合并。它相当于git fetchgit merge。如果远程分支有更新它会尝试合并到你的当前分支。git pull origin main # 从origin的main分支拉取更新并合并注意在pull之前建议先commit或stash本地修改避免冲突。git push 将你的本地提交上传到远程仓库。git push origin feature-xxx # 将本地feature-xxx分支推送到远程origin git push -u origin main # 首次推送本地main分支并建立追踪关系以后可以直接git push5.2 常见的团队协作工作流没有最好的工作流只有最适合团队的工作流。这里介绍两种最主流的。GitHub Flow / 功能分支工作流 适用于持续交付的SaaS类产品。主分支main始终是可部署的。任何新功能或修复都从main拉出一个新的功能分支feature/*。在功能分支上开发、提交。开发完成后向main分支发起一个拉取请求Pull Request, PR。经过代码审查Code Review后合并到main并立即部署。简单、直接强调小步快跑。Git Flow 一个更严格、更结构化的模型适合有固定发布周期、需要维护多个版本如生产版、预发布版的项目。存在两个长期分支main代表生产环境和develop代表开发集成环境。功能分支从develop拉出合并回develop。发布时从develop拉出release/*分支用于测试和小修。完成后合并到main和develop。生产环境的紧急修复从main拉出hotfix/*分支修复后合并回main和develop。流程清晰但相对复杂。对于大多数中小型团队和项目我推荐从功能分支工作流开始它简单有效足以应对90%的场景。6. 高级技巧与疑难杂症排坑指南当你熟悉基础操作后这些技巧能极大提升效率和应对复杂情况的能力。6.1 储藏、标签与子模块git stash “储藏”当前工作区和暂存区的修改让你可以清空状态去处理其他事情如紧急Bug事后再恢复。git stash # 储藏当前修改 git stash list # 查看储藏列表 git stash pop # 应用最近一次储藏并删除记录 git stash apply stash{1} # 应用指定的储藏但不删除记录 git stash drop stash{1} # 删除指定的储藏记录git tag 给重要的提交如版本发布打上标签便于标记和回滚。git tag v1.0.0 # 创建轻量标签 git tag -a v1.0.0 -m “正式版发布” # 创建带注释的标签 git push origin v1.0.0 # 将标签推送到远程.gitignore文件 在项目根目录创建此文件列出你希望Git忽略的文件或目录模式如编译产物node_modules/,*.log, IDE配置文件.idea/。这是保持仓库清洁的第一步。6.2 典型问题与解决方案实录提交了错误的信息或漏了文件场景刚执行完git commit -m “msg”发现提交信息写错了或者漏了某个文件。解决使用git commit --amend。# 修改上一次提交的信息 git commit --amend -m “新的提交信息” # 如果漏了文件先add再amend git add missed-file.txt git commit --amend --no-edit # --no-edit 表示不修改提交信息注意--amend会修改历史如果提交已经推送到远程强制推送git push -f需谨慎并确保团队其他成员知晓。git pull时遇到“拒绝合并无关历史”场景本地初始化了仓库添加了远程仓库地址后第一次pull时可能遇到。解决使用--allow-unrelated-histories参数。git pull origin main --allow-unrelated-histories想永久删除某个文件的历史记录如误提交了密码场景敏感信息被提交并推送到了远程。解决这是一个危险操作会重写历史。需要使用git filter-branch或更高效的第三方工具git filter-repo。操作前务必备份仓库并通知所有协作者。流程复杂此处不展开核心思想是使用工具从所有提交中删除该文件。命令行太麻烦图形化工具推荐Git GUI / GitK Git自带的图形工具功能基础。SourceTree Atlassian出品免费功能强大跨平台。Fork 一款设计优秀的付费Git客户端体验很好。IDE集成 VSCode、IntelliJ IDEA等现代IDE的Git集成已经非常完善能满足大部分需求。我个人的习惯是日常查看状态、暂存、提交、解决冲突用IDE复杂历史查看、分支管理、rebase等操作用命令行两者结合效率最高。7. 企业级实践与提交规范深化在团队环境中仅有个人技巧不够需要建立规范。7.1 强制提交信息规范可以通过Git钩子Hook来实现。在项目根目录的.git/hooks目录下有一个commit-msg.sample文件。复制一份并重命名为commit-msg去掉.sample后缀编辑其内容加入对提交信息格式的校验脚本如使用正则表达式匹配前述的feat:、fix:等前缀。这样当提交信息不符合规范时提交会被拒绝。也可以使用像commitlint这样的工具与husky配合在现代前端项目中非常流行。7.2 代码合并与审查流程保护主分支 在GitLab、GitHub等平台上可以设置main分支为“受保护分支”禁止直接推送必须通过合并请求Merge Request / Pull Request并满足条件如至少一个审核通过、CI流水线通过才能合并。Code Review PR/MR是进行代码审查的最佳场所。审查者应关注代码逻辑、设计、可读性、潜在Bug而不仅仅是风格问题风格问题应通过ESLint、Prettier等工具自动化解决。7.3 基于Git的持续集成/持续部署CI/CD这是现代工程实践的标配。通过在仓库中放置一个配置文件如.gitlab-ci.yml或 GitHub Actions的.github/workflows/*.yml可以在每次推送代码或创建PR时自动触发一系列任务运行测试、构建镜像、代码质量扫描、安全检测、部署到测试环境等。Git作为单一事实来源驱动了整个自动化流程。我个人在实际项目中的体会是Git的熟练度直接决定了开发效率和团队协作的顺畅度。初期投入时间系统学习远比遇到问题后零散搜索要划算得多。不要惧怕命令行它给你最直接的控制力也不要排斥图形工具它们能帮你更直观地理解分支结构。最重要的是养成“小步提交清晰描述”的习惯你的提交历史就是你项目最好的成长日记和设计文档。最后分享一个小技巧当你对一系列复杂操作没把握时先在一个临时分支或克隆的副本上操作这是最安全的“后悔药”。
1. 项目概述为什么每个开发者都绕不开Git如果你刚入行或者正准备踏入软件开发这个领域听到“Git”这个词的频率可能仅次于“Hello World”。它不是一个炫酷的新框架也不是一个能直接产出漂亮界面的工具但它却是现代软件开发的基石是连接你与全球数百万开发者协作网络的桥梁。简单来说Git是一个分布式版本控制系统。但“版本控制”这四个字背后藏着的是我们每天开发中那些最琐碎又最要命的痛点昨天改好的代码今天想回退怎么办两个人同时改了同一个文件怎么合并怎么知道这个功能是哪个版本引入的Bug我见过太多新手一开始对Git敬而远之只会在图形化界面里点“提交”和“推送”一旦遇到冲突Conflict就手足无措甚至有人用复制文件夹的方式来“备份”版本。这就像用记事本写长篇论文没有撤销没有历史记录没有协作可能。而Git就是给你的代码世界加上了一个“时光机”和“平行宇宙管理器”。它记录每一次修改Commit允许你创建独立的分支Branch进行试验并能优雅地合并Merge成果。从个人项目到像Linux内核这样超大规模的开源协作Git都是事实上的标准。所以无论你是前端、后端、移动端还是算法工程师无论你用Windows、macOS还是LinuxGit都是你工具箱里必须熟练使用的第一把“螺丝刀”。接下来的内容我会从一个多年一线开发者的视角带你从零开始不仅学会Git的基本操作更理解其设计哲学和在实际工作中如何高效、安全地使用它避开那些我早期踩过的坑。2. 核心概念与工作流解析理解Git的“世界观”在动手敲命令之前花点时间理解Git的核心思想至关重要。这能让你在遇到问题时不是死记硬背命令而是知道该朝哪个方向思考。2.1 仓库、工作区、暂存区与版本库这是Git最核心的四个概念理解了它们就理解了Git大半的工作方式。仓库Repository 一个被Git管理的项目目录里面包含所有的项目文件和Git的历史记录数据。它通常对应你本地的一个文件夹或者远程服务器如GitHub、Gitee上的一个项目地址。工作区Working Directory 就是你电脑上能直接看到、编辑的那些文件。你在这里进行增删改查。暂存区Staging Area / Index 这是一个非常关键且独特的概念。你可以把它想象成一个“准备台”或“购物车”。工作区的改动不会直接进入版本历史你需要先通过git add命令将改动“放入”暂存区。这允许你对提交进行精细控制比如只提交某个功能的修改而忽略调试时临时加的打印语句。版本库Repository特指.git目录 本地仓库根目录下的.git隐藏文件夹。这是Git的“数据库”你所有的提交历史、分支信息、标签等都存储在这里。千万不要手动修改这个文件夹里的内容。工作流程可以概括为工作区 - (git add) - 暂存区 - (git commit) - 版本库。提示很多新手困惑于“为什么改了文件还要git add”。这正是Git设计的精妙之处——它让你有机会在提交前“预览”和“组装”你的这次提交。比如你同时修复了两个Bug但想分成两次提交记录就可以分别add对应的文件再commit。2.2 提交、分支与合并提交Commit 一次提交就是一次版本快照。它包含了暂存区里所有文件的当前状态、提交者信息、时间戳和一个唯一的哈希值如a1b2c3d。每次提交都会指向它的父提交形成一条历史链。分支Branch 分支本质上只是一个指向某个提交的轻量级可移动指针。默认的主分支通常叫main或master。创建新分支如git branch feature-login几乎零成本因为它只是新建了一个指针。你可以在新分支上独立开发而不会影响主分支。合并Merge 将一个分支的修改整合到另一个分支的过程。最常用的场景是将功能分支合并回主分支。Git会尝试自动合并如果两个分支修改了同一文件的同一区域则会产生“冲突”需要人工解决。2.3 分布式 vs 集中式这是Git与SVN等旧式版本控制系统的根本区别。在Git中每个开发者的本地仓库都是一个完整的版本库拥有全部历史记录。远程仓库如GitHub只是大家同步变更的一个公共节点。这意味着你可以在飞机上、在没有网络的地方自由地提交、创建分支、查看历史。网络只是在你需要与他人同步push/pull时才需要。这种设计带来了极强的健壮性和灵活性。3. 从零开始Git的安装与基础配置3.1 跨平台安装指南Git官方支持所有主流平台。我强烈建议从官网下载以确保版本最新和安全。Windows 访问 git-scm.com 下载.exe安装包。安装过程基本一路“Next”但有几个关键选项选择默认编辑器 安装程序会提示“Choosing the default editor used by Git”。对于大多数中国开发者如果习惯用VSCode可以在这里修改路径指向VSCode的code命令需要提前将VSCode加入系统PATH。如果留空或选择其他不熟悉的编辑器如Vim后续在终端里触发编辑提交信息时可能会手足无措。对于纯新手可以选择“Use Windows‘ default console editor”或记事本Notepad作为起步。调整PATH环境 建议选择“Git from the command line and also from 3rd-party software”这样既能在CMD/PowerShell中使用Git也能被其他软件如IDE调用。换行符处理 选择“Checkout Windows-style, commit Unix-style line endings”推荐。这能最大程度避免Windows和Unix/Linux系统之间因换行符CRLF vs LF不同导致的文件“被全部修改”的假象。macOS 最简单的方法是安装Homebrew包管理器然后执行brew install git。也可以从官网下载.pkg安装包。Linux (Ubuntu/Debian) 使用包管理器如sudo apt update sudo apt install git。安装完成后打开终端Windows上叫Git Bash或CMD/PowerShell输入git --version看到版本号即表示安装成功。3.2 必不可少的初始配置安装后第一件事是配置你的用户身份这个信息会写入你的每一次提交是责任的体现。# 设置全局用户名和邮箱--global表示对所有仓库生效 git config --global user.name 你的姓名 git config --global user.email 你的邮箱example.com # 检查配置 git config --global --list实操心得 邮箱最好使用你常用的、真实的邮箱特别是在公司或开源项目中这便于协作沟通。如果你有多个身份例如公司项目和个人项目使用不同邮箱可以在具体的仓库目录下执行不带--global的命令进行局部覆盖。常用配置优化# 让命令行输出带颜色更易读 git config --global color.ui auto # 设置默认分支名为 main更中立的名称 git config --global init.defaultBranch main # 为常用命令设置别名提升效率 git config --global alias.st status # git st 代替 git status git config --global alias.co checkout # git co 代替 git checkout git config --global alias.br branch # git br 代替 git branch git config --global alias.ci commit # git ci 代替 git commit git config --global alias.unstage reset HEAD -- # git unstage file 撤销暂存4. 日常开发核心命令全解与实战掌握了概念和配置我们进入实战环节。下面这些命令构成了你90%的日常Git操作。4.1 仓库创建与克隆git init 在当前目录初始化一个新的Git仓库。执行后会产生一个.git文件夹。mkdir my-project cd my-project git initgit clone 这是你接触开源项目或加入团队项目最常用的方式。它会把远程仓库的整个历史和数据复制到本地。# 克隆一个远程仓库 git clone https://github.com/username/repo.git # 克隆到指定目录 git clone https://github.com/username/repo.git my-local-folder4.2 文件状态管理与提交这是最核心的循环修改 - 暂存 - 提交。git status 你的“仪表盘”。随时运行它查看工作区和暂存区的状态。哪些文件被修改了modified但未暂存哪些文件是新创建的untracked哪些文件已暂存staged准备提交一目了然。git add 将文件从工作区放入暂存区。git add file.txt # 添加单个文件 git add src/ # 添加整个目录 git add . # 添加当前目录下所有变更最常用但需谨慎 git add -p # 交互式暂存可以按代码块hunk选择性添加非常强大注意git add .会添加所有未跟踪和已修改的文件。在提交前务必用git status确认暂存区的内容是否是你想要的避免提交了临时文件或配置文件。git commit 将暂存区的内容创建一个永久的快照保存到版本库。git commit -m “修复了用户登录失败的Bug” # -m 后直接跟提交信息提交信息规范 好的提交信息至关重要。建议采用类似“类型: 简短描述”的格式例如feat: 新增用户头像上传功能fix: 修复首页在iOS下的滚动卡顿docs: 更新API接口文档style: 调整代码格式无功能变化refactor: 重构用户认证模块这能让历史记录清晰可读也便于工具自动生成更新日志。git restore与git reset 撤销操作。git restore --staged file 将文件从暂存区撤回到工作区取消git add。git restore file 丢弃工作区对某个文件的修改恢复到最近一次提交或暂存的状态危险操作未提交的修改会丢失。git reset HEAD~1软重置。撤销最近一次提交但保留工作区的修改。相当于提交错了但改动的代码还想留着。git reset --hard HEAD~1硬重置。彻底撤销最近一次提交并且丢弃工作区的所有相关修改。非常危险除非确定不需要那些改动否则慎用。4.3 分支操作与合并策略分支是Git的“杀手级”功能让你能并行开发多个功能。git branch 查看、创建、删除分支。git branch # 列出所有本地分支当前分支前有* git branch feature-xxx # 创建名为feature-xxx的新分支 git branch -d feature-xxx # 删除已合并的分支 git branch -D feature-xxx # 强制删除未合并的分支git checkout与git switch 切换分支。git checkout feature-xxx 切换到feature-xxx分支较老的命令功能多但易混淆。git switch feature-xxx Git 2.23版本引入的专用于切换分支的命令更清晰。推荐使用。git switch -c new-feature 创建并切换到新分支-c代表create。git merge 合并分支。通常我们在功能开发完成后切换回主分支进行合并。git switch main # 首先确保你在主分支上 git merge feature-login # 将feature-login分支合并到当前分支main合并冲突解决 如果两个分支修改了同一处Git无法自动合并会标记为冲突状态。文件内会有类似 HEAD,, feature-login的标记。你需要手动编辑文件保留想要的代码删除这些标记然后执行git add 解决后的文件和git commit来完成合并。git rebase 变基。另一个整合分支变化的方法。它会把当前分支的提交“重新播放”在目标分支的最新提交之后从而产生一条更线性的历史。黄金法则不要在公共分支如main上执行rebase只对你自己的本地分支使用。git switch feature-xxx git rebase main # 将feature-xxx的修改“挪到”main分支的最新提交之后Rebase过程中也可能遇到冲突解决方式与merge类似解决后执行git rebase --continue。4.4 查看历史与版本穿梭git log 查看提交历史。我常用一些美化参数git log --oneline --graph --all --decorate # --oneline 单行显示 # --graph 图形化显示分支合并历史 # --all 显示所有分支 # --decorate 显示分支和标签名git diff 查看差异。git diff # 工作区与暂存区的差异 git diff --staged # 暂存区与最新提交的差异 git diff HEAD~2 HEAD # 比较两个历史提交 git diff branchA..branchB # 比较两个分支的最新提交5. 远程协作Push, Pull, Fetch 与团队工作流个人开发在本地即可但团队协作离不开远程仓库。5.1 远程仓库关联与同步git remote 管理远程仓库地址。克隆项目后默认的远程仓库别名是origin。git remote -v # 查看远程仓库地址 git remote add upstream https://github.com/original/repo.git # 添加上游仓库常用于Fork的项目git fetch下载远程仓库的最新数据提交、分支等到本地但不自动合并到你的工作分支。这是一个安全的操作让你先看看别人做了什么。git fetch origin # 从origin远程仓库获取更新git pull下载并合并。它相当于git fetchgit merge。如果远程分支有更新它会尝试合并到你的当前分支。git pull origin main # 从origin的main分支拉取更新并合并注意在pull之前建议先commit或stash本地修改避免冲突。git push 将你的本地提交上传到远程仓库。git push origin feature-xxx # 将本地feature-xxx分支推送到远程origin git push -u origin main # 首次推送本地main分支并建立追踪关系以后可以直接git push5.2 常见的团队协作工作流没有最好的工作流只有最适合团队的工作流。这里介绍两种最主流的。GitHub Flow / 功能分支工作流 适用于持续交付的SaaS类产品。主分支main始终是可部署的。任何新功能或修复都从main拉出一个新的功能分支feature/*。在功能分支上开发、提交。开发完成后向main分支发起一个拉取请求Pull Request, PR。经过代码审查Code Review后合并到main并立即部署。简单、直接强调小步快跑。Git Flow 一个更严格、更结构化的模型适合有固定发布周期、需要维护多个版本如生产版、预发布版的项目。存在两个长期分支main代表生产环境和develop代表开发集成环境。功能分支从develop拉出合并回develop。发布时从develop拉出release/*分支用于测试和小修。完成后合并到main和develop。生产环境的紧急修复从main拉出hotfix/*分支修复后合并回main和develop。流程清晰但相对复杂。对于大多数中小型团队和项目我推荐从功能分支工作流开始它简单有效足以应对90%的场景。6. 高级技巧与疑难杂症排坑指南当你熟悉基础操作后这些技巧能极大提升效率和应对复杂情况的能力。6.1 储藏、标签与子模块git stash “储藏”当前工作区和暂存区的修改让你可以清空状态去处理其他事情如紧急Bug事后再恢复。git stash # 储藏当前修改 git stash list # 查看储藏列表 git stash pop # 应用最近一次储藏并删除记录 git stash apply stash{1} # 应用指定的储藏但不删除记录 git stash drop stash{1} # 删除指定的储藏记录git tag 给重要的提交如版本发布打上标签便于标记和回滚。git tag v1.0.0 # 创建轻量标签 git tag -a v1.0.0 -m “正式版发布” # 创建带注释的标签 git push origin v1.0.0 # 将标签推送到远程.gitignore文件 在项目根目录创建此文件列出你希望Git忽略的文件或目录模式如编译产物node_modules/,*.log, IDE配置文件.idea/。这是保持仓库清洁的第一步。6.2 典型问题与解决方案实录提交了错误的信息或漏了文件场景刚执行完git commit -m “msg”发现提交信息写错了或者漏了某个文件。解决使用git commit --amend。# 修改上一次提交的信息 git commit --amend -m “新的提交信息” # 如果漏了文件先add再amend git add missed-file.txt git commit --amend --no-edit # --no-edit 表示不修改提交信息注意--amend会修改历史如果提交已经推送到远程强制推送git push -f需谨慎并确保团队其他成员知晓。git pull时遇到“拒绝合并无关历史”场景本地初始化了仓库添加了远程仓库地址后第一次pull时可能遇到。解决使用--allow-unrelated-histories参数。git pull origin main --allow-unrelated-histories想永久删除某个文件的历史记录如误提交了密码场景敏感信息被提交并推送到了远程。解决这是一个危险操作会重写历史。需要使用git filter-branch或更高效的第三方工具git filter-repo。操作前务必备份仓库并通知所有协作者。流程复杂此处不展开核心思想是使用工具从所有提交中删除该文件。命令行太麻烦图形化工具推荐Git GUI / GitK Git自带的图形工具功能基础。SourceTree Atlassian出品免费功能强大跨平台。Fork 一款设计优秀的付费Git客户端体验很好。IDE集成 VSCode、IntelliJ IDEA等现代IDE的Git集成已经非常完善能满足大部分需求。我个人的习惯是日常查看状态、暂存、提交、解决冲突用IDE复杂历史查看、分支管理、rebase等操作用命令行两者结合效率最高。7. 企业级实践与提交规范深化在团队环境中仅有个人技巧不够需要建立规范。7.1 强制提交信息规范可以通过Git钩子Hook来实现。在项目根目录的.git/hooks目录下有一个commit-msg.sample文件。复制一份并重命名为commit-msg去掉.sample后缀编辑其内容加入对提交信息格式的校验脚本如使用正则表达式匹配前述的feat:、fix:等前缀。这样当提交信息不符合规范时提交会被拒绝。也可以使用像commitlint这样的工具与husky配合在现代前端项目中非常流行。7.2 代码合并与审查流程保护主分支 在GitLab、GitHub等平台上可以设置main分支为“受保护分支”禁止直接推送必须通过合并请求Merge Request / Pull Request并满足条件如至少一个审核通过、CI流水线通过才能合并。Code Review PR/MR是进行代码审查的最佳场所。审查者应关注代码逻辑、设计、可读性、潜在Bug而不仅仅是风格问题风格问题应通过ESLint、Prettier等工具自动化解决。7.3 基于Git的持续集成/持续部署CI/CD这是现代工程实践的标配。通过在仓库中放置一个配置文件如.gitlab-ci.yml或 GitHub Actions的.github/workflows/*.yml可以在每次推送代码或创建PR时自动触发一系列任务运行测试、构建镜像、代码质量扫描、安全检测、部署到测试环境等。Git作为单一事实来源驱动了整个自动化流程。我个人在实际项目中的体会是Git的熟练度直接决定了开发效率和团队协作的顺畅度。初期投入时间系统学习远比遇到问题后零散搜索要划算得多。不要惧怕命令行它给你最直接的控制力也不要排斥图形工具它们能帮你更直观地理解分支结构。最重要的是养成“小步提交清晰描述”的习惯你的提交历史就是你项目最好的成长日记和设计文档。最后分享一个小技巧当你对一系列复杂操作没把握时先在一个临时分支或克隆的副本上操作这是最安全的“后悔药”。
