说实话git这玩意儿我第一天用的时候真的是一头雾水。add、commit、push、pull命令倒是背了好几条但一碰到回滚代码、处理冲突、配置免密这些场景还是两眼一抹黑。后来在团队里陆续带了一些新人发现大家刚接触git时踩的坑基本都差不多要么是安装完不会配置导致提交记录一团乱要么是遇到一个报错就去搜索引擎翻半天再要么就是提交信息写得毫无规范三个月后自己都看不懂当初干了啥。所以我打算把这几年真正用下来觉得最核心、最实用的git使用方式整理成一篇完整的实操笔记。从下载安装、初始配置、日常命令到分支协作、疑难杂症排查再到提交规范和团队配合习惯一次性说清楚。文章不会大篇幅堆砌官方文档式的理论而是尽量围绕“你真正会在项目里用到的东西”来写让新手上手就能用也让有一定经验的开发者可以把细节补齐。先声明这篇主要面向的是日常开发场景不是git源码解析所以我会把每个关键操作背后“为什么这么做”讲明白再把可直接复制的命令给你。1. 安装与初始化配置这一环没弄好后面全是坑git安装本身不难但很多人的问题恰恰出在安装时的选项和装完之后的初始化配置上。这些配置看起来不起眼却决定了你后面的提交记录是不是规范、跨平台协作会不会出现莫名其妙的换行符问题甚至决定了你在公司电脑上能不能顺利推送代码。1.1 各平台安装方式和安装选项的取舍Windows用户我建议直接去git官网下载安装包选64-bit版本就行。下载慢的话可以找国内镜像这类镜像很多用起来没区别。安装过程中有几个选项需要注意虽然默认值也能用但理解了再选会稳妥很多。第一个是“Adjusting your PATH environment”建议选中间项“Git from the command line and also from 3rd-party software”这样可以在cmd、PowerShell以及各种IDE里直接识别git命令。如果选了“Use Git and optional Unix tools from the Command Prompt”在某些环境下反而会覆盖系统自带的find等命令引发诡异问题。第二个是“Checkout Windows-style, commit Unix-style line endings”这个对于跨平台团队协作很关键。Windows默认用CRLF换行Linux/macOS用LF如果你不做统一处理一个文件被来回修改后git会疯狂提示整个文件被改动实际上只是换行符变了。保持默认选项即可git会在提交时自动把CRLF转成LF存进仓库在检出时再转回CRLF。第三个是选择默认编辑器如果你平时不用vi/vim最好在安装时直接改成VS Code或Notepad不然以后commit时要是忘了加-m参数被丢进vim里不知道怎么退出来那真的是会卡到怀疑人生。macOS用户推荐用Homebrew安装一条命令搞定brew install git这样拿到的版本一般比系统自带的要新。Linux用户则根据发行版选择比如Debian/Ubuntu用sudo apt install gitCentOS/RHEL用sudo yum install git。装完统一验证一下版本能正常输出就说明装好了。git --version如果你在Windows的PowerShell或cmd里执行这条命令系统提示“无法将‘git’项识别为 cmdlet、函数、脚本文件或可运行程序的名称”那基本就是安装时PATH选项没选对或者是安装完成后没重新打开终端。重新打开终端窗口如果还不行就去“系统属性-环境变量-Path”里手动把git安装目录下的cmd路径加进去例如C:\Program Files\Git\cmd然后重开终端。这个报错在论坛里出现频率极高大多数人只要补上PATH就解决了不需要重装。1.2 用户信息配置提交记录的身份ID装好git后第一件事不是急着创建仓库而是配置用户名和邮箱。这个配置会跟着你的每一次commit走提交记录里显示的作者信息就来自于此。在公司场景下建议和你的企业邮箱、企业账号保持一致这样代码评审和追溯时才能准确找到人。git config --global user.name 你的名字 git config --global user.email 你的邮箱这里有三层作用域需要区分--global表示全局配置作用于当前用户下所有仓库不加参数则只作用于当前仓库可以覆盖全局配置--system是整台机器级别的一般用不到。判断当前仓库实际生效的配置可以用git config --list git config user.name如果不小心把用户名或邮箱配错了已经提交的记录可以通过修改最近一次提交的作者信息来修正前提是还没有推送到远程git commit --amend --author新名字 新邮箱 --no-edit如果已经推送了那修正起来就比较麻烦需要改写历史要慎重不建议新手直接操作。实际操作中我更建议先把配置写对别给自己埋雷。1.3 换行符策略与默认编辑器细节刚才提到换行符我再说细一点。团队里如果有人用Windows有人用macOS而且不统一处理换行符早晚会出幺蛾子。项目根目录建议放一个.gitattributes文件强制指定各类型文件的换行符策略比如* textauto *.sh text eollf *.bat text eolcrlf这样比单纯依赖每个人的core.autocrlf配置更可靠因为.gitattributes会随着仓库走团队所有人拉下来都一样。这是我在一个混合系统团队里踩了几次坑之后学到的加了它之后“文件整体被识别为改动”的问题几乎绝迹。默认编辑器这块我在安装时已经提醒过。如果你已经装完了git也可以用命令改git config --global core.editor code --wait这样设置后执行git commit时如果需要写提交信息会自动打开VS Code写完保存并关闭窗口后git就能继续执行。这个小细节可能看起来不重要但对新手来说很关键因为很多人第一次接触vim不知道按i进入编辑、按Esc退出、再输入:wq保存退出最后只能把终端整个关掉搞出一堆奇奇怪怪的后遗症。2. 日常开发最常用的Git命令一套流程吃透本地操作安装配置搞定后接下来就是每天早上到工位、打开项目、开始敲代码之前的日常操作。这套流程总结下来就是拉取最新代码、新建分支、写代码、查看差异、暂存、提交、推送。我把每一步的命令和背后逻辑拆开讲清楚。2.1 初始化仓库和首次提交的完整路径如果你是新项目需要先初始化仓库git init这个命令会在当前目录生成一个隐藏的.git文件夹所有版本历史都存在这里面。如果你用的是已有项目通常是git clone拉下来不需要自己init。clong仓库时要注意区分HTTPS和SSH地址后面免密配置部分我会细说。首次提交的标准步骤是git add . git status git commit -m feat: 初始化项目这里有一个新手容易走偏的地方很多人习惯一口气git add .把所有文件全部暂存。这在项目初期问题不大但项目大起来之后一次提交塞进几十个文件的改动既不方便评审也不方便后面回滚。更合理的做法是分模块提交比如git add src/模块A git commit -m feat: 完成模块A的功能开发 git add src/模块B git commit -m feat: 完成模块B的接口对接还有一个小技巧git add支持按块添加比如你修改了一个文件里的两处逻辑但只想提交其中一处可以用git add -p 文件名git会把这个文件的改动拆成多个hunk让你逐个选择是否暂存。这在实际开发中非常实用尤其是当你发现一个文件里混着两个不同功能的修改时不需要借助任何IDE插件就能拆得干净利落。2.2 查看提交历史和内容差异提交之后要观察历史记录最常用的是git log但默认输出太啰嗦我几乎每次都带参数git log --oneline --graph --all --decorate这个组合可以在一行内显示每个提交的简短哈希值和提交信息并且用图形方式展示分支分叉和合并关系。加--all可以显示所有分支而不是停留在当前分支加--decorate会标出分支指针和标签指向的位置。想查看某个提交具体改了哪些内容用git show 提交哈希不加哈希时默认显示当前分支最近一次提交的改动。查看工作区改动和暂存区内容的标准姿势git diff git diff --staged没有参数时git diff对比的是工作区还没暂存的改动--staged对比的是已经暂存但还没提交的内容。如果你发现改了半天的东西在git diff里看不到那多半是已经git add过了这时候要看的是--staged。2.3 撤销与回滚分清三种场景才不会翻车撤销可以说是git里最容易让人困惑的部分因为命令不止一条而且能力各不相同。我按场景拆开工作区改了但还没暂存想放弃这些修改用git restore 文件名或者老式一点的git checkout -- 文件名。文件已经git add过了想从暂存区撤销但保留工作区的改动用git restore --staged 文件名。提交已经生成了但发现提交信息写错了或少加了文件用git commit --amend它可以修改最近一次提交。如果是已经提交了好几次想回退到某个历史版本就要区分两种思路。git reset是“回退并抹除历史”。比如git reset --hard HEAD~2这个命令会把当前分支的指针硬回退到两个提交之前同时工作区和暂存区都被覆盖后面的提交记录直接消失。这个操作非常危险尤其是在已经把代码推送到远程的情况下因为本地历史和远程历史会分叉其他人再拉取时会很难受。所以--hard只建议在本地、且确定不需要保留这些提交时使用。git revert则是“生成一个反向提交来抵消目标提交”。它不动历史而是在当前基础上新增一个提交把指定提交的改动全部反着执行一遍。这样远程仓库的历史是线性向前的团队成员pull下来不会出现历史分叉的麻烦。git revert 提交哈希如果你不小心把代码推到远程了才发现问题第一选择应该永远是revert而不是reset。这是我在团队协作里总结的最重要一条经验尽量不去改写别人可能已经拉取过的历史用新增提交来修正错误是最稳的路。3. 分支管理与远程协作从单人玩到多人配合的关键跃迁本地命令熟练之后迟早要进入团队协作阶段。分支管理、远程仓库、合并冲突这一块是git使用方式里最能拉开人与人差距的部分。理解了分支的底层逻辑很多命令就不用背了因为你大概能猜到它会做什么。3.1 分支的创建、切换与合并机制git里的分支本质上是一个指向某个提交的指针。创建一个新分支就是创建一个新指针切换分支就是移动当前HEAD指针的指向。理解这句话后下面这些命令就很好记了。git branch feature/login git switch feature/login也可以一行完成创建并切换git switch -c feature/login老版本的git checkout -b feature/login效果一样新版本更推荐switch系列语义更清晰不容易和“撤销文件修改”这个checkout的用途混淆。日常开发中我建议把分支划分成两类长期稳定分支和短期功能分支。主干分支用于存放可发布版本功能分支从主干拉出开发完成后合并回去。合并有两种方式merge和rebase。git switch main git merge feature/loginmerge会产生一个“合并提交”历史会出现分叉再汇合的形态好处是保留了真实的开发轨迹坏处是历史图稍微复杂一些。rebase则是把当前分支的提交“摘下来”重新接到另一个分支的最新提交之后git switch feature/login git rebase main这样得到的历史是一条直线非常干净但代价是改了提交哈希如果这个分支已经被别人拉取过就别rebase了。我的习惯是本地还没推送过的功能分支用rebase来保持整洁已经推送到远程或者多人共用的分支用merge。3.2 远程仓库的添加、克隆和推送把本地仓库和远程仓库关联起来用git remote add origin 仓库地址。这里的origin只是一个约定俗成的名称不是强制要求但所有人都默认叫它origin团队沟通时听到“推到origin”就心领神会。首次推送并设置上游分支git push -u origin main-u参数会建立当前分支和远程分支的追踪关系之后就可以直接输入git push和git pull不用再带远程仓库名和分支名。克隆已有的远程仓库更简单git clone gitgithub.com:用户名/仓库名.git如果你是在公司内网用GitLab地址格式可能会是自定义域名加命名空间但逻辑是一样的。克隆时要注意默认只会拉取默认分支其他远程分支在本地不可见但你可以用git branch -r查看所有远程分支需要用哪个分支就通过git switch创建对应的本地追踪分支。3.3 冲突的产生和解决流程冲突是多人协作绕不开的环节。两个人都修改了同一个文件的同一段内容后合并的人就会遇到冲突。遇到冲突不用慌git会在冲突文件里插入类似这样的标记 HEAD 当前分支的修改 被合并分支的修改 feature/login你需要手动决定保留哪一边、或者两边都保留然后把标记行删掉。处理完后执行git add 冲突文件 git commit这里要注意很多人会忘记修改完冲突后需要先git add再直接commit。如果是在merge过程中git会默认生成一个合并提交信息你直接保存退出即可如果是在rebase过程中继续执行git rebase --continue直到所有冲突都处理完。我在实际项目中见过最多的冲突类型是重构类改动和新增功能类改动撞在一起或者格式化工具调整了全文件缩进导致整个文件冲突。后者更头疼因为冲突范围大且无脑。解决办法是团队统一格式化配置并且尽量避免把全文件格式化和大功能混在同一个提交里。4. 疑难杂症排查与效率提升把踩过的坑变成经验用git的时间久了总会遇到一些和命令本身没直接关系的疑难问题。很多人在群里问“这个报错什么意思”其实大部分问题都可以通过理解git的数据存储和远程协议逻辑来推导。这一节我整理几个高频问题以及我自己的排查思路。4.1 免密配置SSH Key与凭据存储关于“git免密”最常见的需求就是推送代码时不用反复输入用户名密码。有两套方案我分开说。第一套是配置SSH Key。用ssh-keygen -t ed25519 -C 你的邮箱生成密钥对一路回车可以生成在默认路径~/.ssh/id_ed25519下。然后把公钥内容添加到GitHub、GitLab或Gitee的SSH Keys设置里。添加完成后把仓库的远程地址改成SSH格式比如gitgithub.com:用户名/仓库名.git之后推送就不再需要输入密码了。第二套是HTTPS凭据存储适合不想折腾SSH Key、仓库地址已经是HTTPS格式的情况。Windows下可以启用git的凭据管理器git config --global credential.helper manager在macOS上则常用osxkeychaingit config --global credential.helper osxkeychain第一次输入用户名密码时系统会记住凭据后续推送自动使用。两种方案哪个更好如果是个人项目凭据管理器够了如果是长期频繁使用我更推荐SSH Key因为密钥比密码更安全而且在公司内网环境配合跳板机时也更灵活。提到SSH还有一个常见困惑明明配置了密钥但推送还是要求输入密码大概率是远程地址仍然用的HTTPS格式或者公钥没生效。用git remote -v看一下远程地址如果是https://开头说明SSH Key根本没参与进来改成git格式就好。4.2 常见报错速查从提示定位真正问题我在平时帮同事排查问题时发现很多报错其实是同一个根因换着说法出现。这里整理一张速查表遇到类似情况可以直接对照排查。报错关键字常见原因解决方向“无法将git项识别为cmdlet”git不在PATH环境变量里添加git执行路径或重开终端“Permission denied (publickey)”SSH公钥未配置或无效重新生成SSH Key并添加到平台“Authentication failed”密码错误或账号凭据过期更新凭据或改用SSH Key“refusing to merge unrelated histories”两个仓库没有共同历史确认场景后加--allow-unrelated-histories“Login failed. Check API token or GitLab version”API Token失效或版本不兼容检查Token权限和GitLab版本“fatal: Not a git repository”当前目录不是git仓库检查是否在项目根目录执行命令“Please commit or stash them”有未提交改动无法切换分支commit或stash后再切换重点说一下refusing to merge unrelated histories这个报错场景很典型比如你创建了一个远程空仓库本地已经初始化并提交过代码然后执行git pull origin main --rebasegit发现两边历史没有共同祖先就会拒绝合并。如果你确定这是一个全新的空仓库可以加参数强制合并git pull origin main --allow-unrelated-histories但要注意这个操作会把两边完全无关的代码强行合并到一起如果两边有同名文件会有很多冲突处理起来非常痛苦。更好的习惯是远程仓库创建时如果允许直接勾选“使用README或.gitignore初始化”然后用它克隆下来再拷贝代码或者先git pull再提交避免仓库历史完全不同步的情况。4.3 关于“git目录泄露”和“git小乌龟”的两点补充热词里提到了“git目录泄露如何下载”和“git小乌龟”我分别说一下。“git目录泄露”是一个安全话题通常是指网站部署时把.git目录暴露到了公网导致攻击者可以通过访问/.git/路径获取源码和提交历史。如果你在安全测试或合规检查中遇到这个问题首先要明白这不是用来“下载代码”的便捷通道而是必须修复的安全隐患。正确的处理方式是在Web服务器层禁止对.git目录的访问比如Nginx里加一条location ~ /\.git { deny all; }或者部署时直接把.git目录排除在外。如果发现自己的项目也存在这个泄露优先处理服务器配置而不是纠结怎么下载完整代码。“git小乌龟”指的是TortoiseGit一个Windows平台的git图形客户端最大的特点是集成在右键菜单里图标覆盖能直观显示文件状态很多不习惯命令行的用户觉得它很友好。它的安装需要注意先安装TortoiseGit再安装对应的语言包安装过程中会要求指定git程序路径指向git安装目录下的cmd/git.exe即可。虽然配置不复杂但我个人体会是图形客户端适合查看文件状态和做简单提交遇到合并冲突、rebase这类精细化操作还是命令行更高效。所以我建议新手可以从小乌龟入口但别完全依赖它把命令行的几个核心命令练熟回报率最高。4.4 其他有意思的实用小技巧除了解决报错还有几个能明显提升效率的命令我平时几乎天天用。git stash用于暂时保存工作区的改动然后切换到其他分支干活等回来再恢复。比如你正在功能分支上写代码突然线上有个bug需要在主干分支紧急修复这时候直接切分支会被git拒绝因为工作区有未提交改动。用git stash push -m 暂存信息保存切过去改bug、提交、切回来再用git stash pop恢复整个流程非常顺畅。git log -p可以按提交逐个查看补丁内容适合复盘一个功能的完整演变过程。git blame可以查看某一行代码最近是哪次提交改的、谁改的排查问题时非常有用它能快速定位为什么这行代码存在、当初改动的上下文是什么。git grep可以在仓库的已跟踪文件里搜索关键词比系统的文件搜索更快因为git有索引缓存。5. 提交规范与团队协作习惯从“能跑”到“好用”其实git命令用久了你会发现工具本身不是瓶颈团队的协作规范才是。同样的仓库有的人提交历史像山一样的整洁有的人则是一堆“update”“fix bug”“提交”这样的信息堆在一起三个月后根本没法追溯。提交规范这件事越早统一越好。5.1 提交信息格式angluar风格足够用业界最通用的提交信息格式是Angular团队提出的规范尤其适合在代码评审和自动生成变更日志时使用。核心格式是type(scope): subjecttype表示提交类型常用的有feat新功能fix修复bugdocs文档变更style格式调整不影响逻辑refactor重构不改变外部行为test新增或修改测试chore构建配置、依赖变更等杂项scope是影响范围比如模块名称、组件的名称可以省略。subject是简短描述用祈使句不超过50个字符不结尾带句号。实际例子feat(login): 增加手机号登录方式 fix(cart): 修复商品数量为负数时金额计算错误 docs(readme): 更新部署说明为什么这样推荐因为当你用git log --oneline浏览历史时一眼就能看出每次提交干了什么。配合上面的命令你能快速定位某个功能是哪个提交引入的再配合git revert精确回滚某个具体功能而不影响其他代码。我自己在维护开源项目时还会配合conventional commits的插件自动生成CHANGELOG提交信息不规范的话这一步根本做不了。如果团队对提交规范要求比较高还可以配合Commitlint和Husky做提交信息的自动校验。在项目里安装并配置完之后如果提交信息格式不对git会在git commit时直接拦截并给出提示。这个对老团队来说可能需要适应一下但新项目从第一天就接入后面几乎没有维护成本。5.2 分支命名与提交粒度好习惯都是“设计”出来的分支命名建议和提交规范呼应比如feature/登录模块、fix/购物车金额错误、hotfix/线上紧急修复。这样在git branch -r查看远程分支时一眼就能看出每个分支的目的。Pull Request和Merge Request的标题也可以用同样的前缀做到全链路统一。提交粒度上我建议遵循“原子提交”原则一个提交只做一件事。一个功能拆成多个提交完全没问题但一个提交里不要混入两个不相干的功能。这样可以大幅简化代码评审也能让后面的回滚更精准。为了实现这个目标你可能会经常用到前面提过的git add -p按hunk暂存这比一股脑git add .要专业得多。还有一个容易忽略的细节不要把生成物提交进仓库。比如node_modules、dist、.idea、.vscode这类目录都应该通过.gitignore排除。否则每次依赖安装或构建后文件内容变化都会被git跟踪提交历史里会出现大量无意义改动。项目初始化时就应该创建.gitignore并且在后续开发中不断完善。从工具使用的角度看这些规范看起来像是“额外约束”但我实际体会是它们恰恰是帮你省时间的。规范越清晰团队协作时无谓的沟通就越少。代码评审的焦点可以放在逻辑本身而不是纠结“这个提交为什么改了这个文件”。历史记录里少了那种“update”“111”之类的垃圾提交事后追溯出问题的速度会明显提升。最后再分享一个我在实际项目里总结的小技巧如果你在一个功能分支上开发了两三天提交了十几次在合并回主干前可以先用git rebase -i把这十几个琐碎的提交合并成几个有意义的提交把开发过程中的临时代码、调试输出、格式调整这类信息整理掉。这样合并到主干后历史会非常干净。这种做法对还没推送过远端的本地分支来说成本很低但对整个仓库的维护帮助巨大。我之前在项目里演示一次之后同事纷纷说“原来历史记录可以这么清爽”从此再也没人抱怨git历史乱了。
Git从入门到实战：核心命令、分支协作与团队规范全解析
说实话git这玩意儿我第一天用的时候真的是一头雾水。add、commit、push、pull命令倒是背了好几条但一碰到回滚代码、处理冲突、配置免密这些场景还是两眼一抹黑。后来在团队里陆续带了一些新人发现大家刚接触git时踩的坑基本都差不多要么是安装完不会配置导致提交记录一团乱要么是遇到一个报错就去搜索引擎翻半天再要么就是提交信息写得毫无规范三个月后自己都看不懂当初干了啥。所以我打算把这几年真正用下来觉得最核心、最实用的git使用方式整理成一篇完整的实操笔记。从下载安装、初始配置、日常命令到分支协作、疑难杂症排查再到提交规范和团队配合习惯一次性说清楚。文章不会大篇幅堆砌官方文档式的理论而是尽量围绕“你真正会在项目里用到的东西”来写让新手上手就能用也让有一定经验的开发者可以把细节补齐。先声明这篇主要面向的是日常开发场景不是git源码解析所以我会把每个关键操作背后“为什么这么做”讲明白再把可直接复制的命令给你。1. 安装与初始化配置这一环没弄好后面全是坑git安装本身不难但很多人的问题恰恰出在安装时的选项和装完之后的初始化配置上。这些配置看起来不起眼却决定了你后面的提交记录是不是规范、跨平台协作会不会出现莫名其妙的换行符问题甚至决定了你在公司电脑上能不能顺利推送代码。1.1 各平台安装方式和安装选项的取舍Windows用户我建议直接去git官网下载安装包选64-bit版本就行。下载慢的话可以找国内镜像这类镜像很多用起来没区别。安装过程中有几个选项需要注意虽然默认值也能用但理解了再选会稳妥很多。第一个是“Adjusting your PATH environment”建议选中间项“Git from the command line and also from 3rd-party software”这样可以在cmd、PowerShell以及各种IDE里直接识别git命令。如果选了“Use Git and optional Unix tools from the Command Prompt”在某些环境下反而会覆盖系统自带的find等命令引发诡异问题。第二个是“Checkout Windows-style, commit Unix-style line endings”这个对于跨平台团队协作很关键。Windows默认用CRLF换行Linux/macOS用LF如果你不做统一处理一个文件被来回修改后git会疯狂提示整个文件被改动实际上只是换行符变了。保持默认选项即可git会在提交时自动把CRLF转成LF存进仓库在检出时再转回CRLF。第三个是选择默认编辑器如果你平时不用vi/vim最好在安装时直接改成VS Code或Notepad不然以后commit时要是忘了加-m参数被丢进vim里不知道怎么退出来那真的是会卡到怀疑人生。macOS用户推荐用Homebrew安装一条命令搞定brew install git这样拿到的版本一般比系统自带的要新。Linux用户则根据发行版选择比如Debian/Ubuntu用sudo apt install gitCentOS/RHEL用sudo yum install git。装完统一验证一下版本能正常输出就说明装好了。git --version如果你在Windows的PowerShell或cmd里执行这条命令系统提示“无法将‘git’项识别为 cmdlet、函数、脚本文件或可运行程序的名称”那基本就是安装时PATH选项没选对或者是安装完成后没重新打开终端。重新打开终端窗口如果还不行就去“系统属性-环境变量-Path”里手动把git安装目录下的cmd路径加进去例如C:\Program Files\Git\cmd然后重开终端。这个报错在论坛里出现频率极高大多数人只要补上PATH就解决了不需要重装。1.2 用户信息配置提交记录的身份ID装好git后第一件事不是急着创建仓库而是配置用户名和邮箱。这个配置会跟着你的每一次commit走提交记录里显示的作者信息就来自于此。在公司场景下建议和你的企业邮箱、企业账号保持一致这样代码评审和追溯时才能准确找到人。git config --global user.name 你的名字 git config --global user.email 你的邮箱这里有三层作用域需要区分--global表示全局配置作用于当前用户下所有仓库不加参数则只作用于当前仓库可以覆盖全局配置--system是整台机器级别的一般用不到。判断当前仓库实际生效的配置可以用git config --list git config user.name如果不小心把用户名或邮箱配错了已经提交的记录可以通过修改最近一次提交的作者信息来修正前提是还没有推送到远程git commit --amend --author新名字 新邮箱 --no-edit如果已经推送了那修正起来就比较麻烦需要改写历史要慎重不建议新手直接操作。实际操作中我更建议先把配置写对别给自己埋雷。1.3 换行符策略与默认编辑器细节刚才提到换行符我再说细一点。团队里如果有人用Windows有人用macOS而且不统一处理换行符早晚会出幺蛾子。项目根目录建议放一个.gitattributes文件强制指定各类型文件的换行符策略比如* textauto *.sh text eollf *.bat text eolcrlf这样比单纯依赖每个人的core.autocrlf配置更可靠因为.gitattributes会随着仓库走团队所有人拉下来都一样。这是我在一个混合系统团队里踩了几次坑之后学到的加了它之后“文件整体被识别为改动”的问题几乎绝迹。默认编辑器这块我在安装时已经提醒过。如果你已经装完了git也可以用命令改git config --global core.editor code --wait这样设置后执行git commit时如果需要写提交信息会自动打开VS Code写完保存并关闭窗口后git就能继续执行。这个小细节可能看起来不重要但对新手来说很关键因为很多人第一次接触vim不知道按i进入编辑、按Esc退出、再输入:wq保存退出最后只能把终端整个关掉搞出一堆奇奇怪怪的后遗症。2. 日常开发最常用的Git命令一套流程吃透本地操作安装配置搞定后接下来就是每天早上到工位、打开项目、开始敲代码之前的日常操作。这套流程总结下来就是拉取最新代码、新建分支、写代码、查看差异、暂存、提交、推送。我把每一步的命令和背后逻辑拆开讲清楚。2.1 初始化仓库和首次提交的完整路径如果你是新项目需要先初始化仓库git init这个命令会在当前目录生成一个隐藏的.git文件夹所有版本历史都存在这里面。如果你用的是已有项目通常是git clone拉下来不需要自己init。clong仓库时要注意区分HTTPS和SSH地址后面免密配置部分我会细说。首次提交的标准步骤是git add . git status git commit -m feat: 初始化项目这里有一个新手容易走偏的地方很多人习惯一口气git add .把所有文件全部暂存。这在项目初期问题不大但项目大起来之后一次提交塞进几十个文件的改动既不方便评审也不方便后面回滚。更合理的做法是分模块提交比如git add src/模块A git commit -m feat: 完成模块A的功能开发 git add src/模块B git commit -m feat: 完成模块B的接口对接还有一个小技巧git add支持按块添加比如你修改了一个文件里的两处逻辑但只想提交其中一处可以用git add -p 文件名git会把这个文件的改动拆成多个hunk让你逐个选择是否暂存。这在实际开发中非常实用尤其是当你发现一个文件里混着两个不同功能的修改时不需要借助任何IDE插件就能拆得干净利落。2.2 查看提交历史和内容差异提交之后要观察历史记录最常用的是git log但默认输出太啰嗦我几乎每次都带参数git log --oneline --graph --all --decorate这个组合可以在一行内显示每个提交的简短哈希值和提交信息并且用图形方式展示分支分叉和合并关系。加--all可以显示所有分支而不是停留在当前分支加--decorate会标出分支指针和标签指向的位置。想查看某个提交具体改了哪些内容用git show 提交哈希不加哈希时默认显示当前分支最近一次提交的改动。查看工作区改动和暂存区内容的标准姿势git diff git diff --staged没有参数时git diff对比的是工作区还没暂存的改动--staged对比的是已经暂存但还没提交的内容。如果你发现改了半天的东西在git diff里看不到那多半是已经git add过了这时候要看的是--staged。2.3 撤销与回滚分清三种场景才不会翻车撤销可以说是git里最容易让人困惑的部分因为命令不止一条而且能力各不相同。我按场景拆开工作区改了但还没暂存想放弃这些修改用git restore 文件名或者老式一点的git checkout -- 文件名。文件已经git add过了想从暂存区撤销但保留工作区的改动用git restore --staged 文件名。提交已经生成了但发现提交信息写错了或少加了文件用git commit --amend它可以修改最近一次提交。如果是已经提交了好几次想回退到某个历史版本就要区分两种思路。git reset是“回退并抹除历史”。比如git reset --hard HEAD~2这个命令会把当前分支的指针硬回退到两个提交之前同时工作区和暂存区都被覆盖后面的提交记录直接消失。这个操作非常危险尤其是在已经把代码推送到远程的情况下因为本地历史和远程历史会分叉其他人再拉取时会很难受。所以--hard只建议在本地、且确定不需要保留这些提交时使用。git revert则是“生成一个反向提交来抵消目标提交”。它不动历史而是在当前基础上新增一个提交把指定提交的改动全部反着执行一遍。这样远程仓库的历史是线性向前的团队成员pull下来不会出现历史分叉的麻烦。git revert 提交哈希如果你不小心把代码推到远程了才发现问题第一选择应该永远是revert而不是reset。这是我在团队协作里总结的最重要一条经验尽量不去改写别人可能已经拉取过的历史用新增提交来修正错误是最稳的路。3. 分支管理与远程协作从单人玩到多人配合的关键跃迁本地命令熟练之后迟早要进入团队协作阶段。分支管理、远程仓库、合并冲突这一块是git使用方式里最能拉开人与人差距的部分。理解了分支的底层逻辑很多命令就不用背了因为你大概能猜到它会做什么。3.1 分支的创建、切换与合并机制git里的分支本质上是一个指向某个提交的指针。创建一个新分支就是创建一个新指针切换分支就是移动当前HEAD指针的指向。理解这句话后下面这些命令就很好记了。git branch feature/login git switch feature/login也可以一行完成创建并切换git switch -c feature/login老版本的git checkout -b feature/login效果一样新版本更推荐switch系列语义更清晰不容易和“撤销文件修改”这个checkout的用途混淆。日常开发中我建议把分支划分成两类长期稳定分支和短期功能分支。主干分支用于存放可发布版本功能分支从主干拉出开发完成后合并回去。合并有两种方式merge和rebase。git switch main git merge feature/loginmerge会产生一个“合并提交”历史会出现分叉再汇合的形态好处是保留了真实的开发轨迹坏处是历史图稍微复杂一些。rebase则是把当前分支的提交“摘下来”重新接到另一个分支的最新提交之后git switch feature/login git rebase main这样得到的历史是一条直线非常干净但代价是改了提交哈希如果这个分支已经被别人拉取过就别rebase了。我的习惯是本地还没推送过的功能分支用rebase来保持整洁已经推送到远程或者多人共用的分支用merge。3.2 远程仓库的添加、克隆和推送把本地仓库和远程仓库关联起来用git remote add origin 仓库地址。这里的origin只是一个约定俗成的名称不是强制要求但所有人都默认叫它origin团队沟通时听到“推到origin”就心领神会。首次推送并设置上游分支git push -u origin main-u参数会建立当前分支和远程分支的追踪关系之后就可以直接输入git push和git pull不用再带远程仓库名和分支名。克隆已有的远程仓库更简单git clone gitgithub.com:用户名/仓库名.git如果你是在公司内网用GitLab地址格式可能会是自定义域名加命名空间但逻辑是一样的。克隆时要注意默认只会拉取默认分支其他远程分支在本地不可见但你可以用git branch -r查看所有远程分支需要用哪个分支就通过git switch创建对应的本地追踪分支。3.3 冲突的产生和解决流程冲突是多人协作绕不开的环节。两个人都修改了同一个文件的同一段内容后合并的人就会遇到冲突。遇到冲突不用慌git会在冲突文件里插入类似这样的标记 HEAD 当前分支的修改 被合并分支的修改 feature/login你需要手动决定保留哪一边、或者两边都保留然后把标记行删掉。处理完后执行git add 冲突文件 git commit这里要注意很多人会忘记修改完冲突后需要先git add再直接commit。如果是在merge过程中git会默认生成一个合并提交信息你直接保存退出即可如果是在rebase过程中继续执行git rebase --continue直到所有冲突都处理完。我在实际项目中见过最多的冲突类型是重构类改动和新增功能类改动撞在一起或者格式化工具调整了全文件缩进导致整个文件冲突。后者更头疼因为冲突范围大且无脑。解决办法是团队统一格式化配置并且尽量避免把全文件格式化和大功能混在同一个提交里。4. 疑难杂症排查与效率提升把踩过的坑变成经验用git的时间久了总会遇到一些和命令本身没直接关系的疑难问题。很多人在群里问“这个报错什么意思”其实大部分问题都可以通过理解git的数据存储和远程协议逻辑来推导。这一节我整理几个高频问题以及我自己的排查思路。4.1 免密配置SSH Key与凭据存储关于“git免密”最常见的需求就是推送代码时不用反复输入用户名密码。有两套方案我分开说。第一套是配置SSH Key。用ssh-keygen -t ed25519 -C 你的邮箱生成密钥对一路回车可以生成在默认路径~/.ssh/id_ed25519下。然后把公钥内容添加到GitHub、GitLab或Gitee的SSH Keys设置里。添加完成后把仓库的远程地址改成SSH格式比如gitgithub.com:用户名/仓库名.git之后推送就不再需要输入密码了。第二套是HTTPS凭据存储适合不想折腾SSH Key、仓库地址已经是HTTPS格式的情况。Windows下可以启用git的凭据管理器git config --global credential.helper manager在macOS上则常用osxkeychaingit config --global credential.helper osxkeychain第一次输入用户名密码时系统会记住凭据后续推送自动使用。两种方案哪个更好如果是个人项目凭据管理器够了如果是长期频繁使用我更推荐SSH Key因为密钥比密码更安全而且在公司内网环境配合跳板机时也更灵活。提到SSH还有一个常见困惑明明配置了密钥但推送还是要求输入密码大概率是远程地址仍然用的HTTPS格式或者公钥没生效。用git remote -v看一下远程地址如果是https://开头说明SSH Key根本没参与进来改成git格式就好。4.2 常见报错速查从提示定位真正问题我在平时帮同事排查问题时发现很多报错其实是同一个根因换着说法出现。这里整理一张速查表遇到类似情况可以直接对照排查。报错关键字常见原因解决方向“无法将git项识别为cmdlet”git不在PATH环境变量里添加git执行路径或重开终端“Permission denied (publickey)”SSH公钥未配置或无效重新生成SSH Key并添加到平台“Authentication failed”密码错误或账号凭据过期更新凭据或改用SSH Key“refusing to merge unrelated histories”两个仓库没有共同历史确认场景后加--allow-unrelated-histories“Login failed. Check API token or GitLab version”API Token失效或版本不兼容检查Token权限和GitLab版本“fatal: Not a git repository”当前目录不是git仓库检查是否在项目根目录执行命令“Please commit or stash them”有未提交改动无法切换分支commit或stash后再切换重点说一下refusing to merge unrelated histories这个报错场景很典型比如你创建了一个远程空仓库本地已经初始化并提交过代码然后执行git pull origin main --rebasegit发现两边历史没有共同祖先就会拒绝合并。如果你确定这是一个全新的空仓库可以加参数强制合并git pull origin main --allow-unrelated-histories但要注意这个操作会把两边完全无关的代码强行合并到一起如果两边有同名文件会有很多冲突处理起来非常痛苦。更好的习惯是远程仓库创建时如果允许直接勾选“使用README或.gitignore初始化”然后用它克隆下来再拷贝代码或者先git pull再提交避免仓库历史完全不同步的情况。4.3 关于“git目录泄露”和“git小乌龟”的两点补充热词里提到了“git目录泄露如何下载”和“git小乌龟”我分别说一下。“git目录泄露”是一个安全话题通常是指网站部署时把.git目录暴露到了公网导致攻击者可以通过访问/.git/路径获取源码和提交历史。如果你在安全测试或合规检查中遇到这个问题首先要明白这不是用来“下载代码”的便捷通道而是必须修复的安全隐患。正确的处理方式是在Web服务器层禁止对.git目录的访问比如Nginx里加一条location ~ /\.git { deny all; }或者部署时直接把.git目录排除在外。如果发现自己的项目也存在这个泄露优先处理服务器配置而不是纠结怎么下载完整代码。“git小乌龟”指的是TortoiseGit一个Windows平台的git图形客户端最大的特点是集成在右键菜单里图标覆盖能直观显示文件状态很多不习惯命令行的用户觉得它很友好。它的安装需要注意先安装TortoiseGit再安装对应的语言包安装过程中会要求指定git程序路径指向git安装目录下的cmd/git.exe即可。虽然配置不复杂但我个人体会是图形客户端适合查看文件状态和做简单提交遇到合并冲突、rebase这类精细化操作还是命令行更高效。所以我建议新手可以从小乌龟入口但别完全依赖它把命令行的几个核心命令练熟回报率最高。4.4 其他有意思的实用小技巧除了解决报错还有几个能明显提升效率的命令我平时几乎天天用。git stash用于暂时保存工作区的改动然后切换到其他分支干活等回来再恢复。比如你正在功能分支上写代码突然线上有个bug需要在主干分支紧急修复这时候直接切分支会被git拒绝因为工作区有未提交改动。用git stash push -m 暂存信息保存切过去改bug、提交、切回来再用git stash pop恢复整个流程非常顺畅。git log -p可以按提交逐个查看补丁内容适合复盘一个功能的完整演变过程。git blame可以查看某一行代码最近是哪次提交改的、谁改的排查问题时非常有用它能快速定位为什么这行代码存在、当初改动的上下文是什么。git grep可以在仓库的已跟踪文件里搜索关键词比系统的文件搜索更快因为git有索引缓存。5. 提交规范与团队协作习惯从“能跑”到“好用”其实git命令用久了你会发现工具本身不是瓶颈团队的协作规范才是。同样的仓库有的人提交历史像山一样的整洁有的人则是一堆“update”“fix bug”“提交”这样的信息堆在一起三个月后根本没法追溯。提交规范这件事越早统一越好。5.1 提交信息格式angluar风格足够用业界最通用的提交信息格式是Angular团队提出的规范尤其适合在代码评审和自动生成变更日志时使用。核心格式是type(scope): subjecttype表示提交类型常用的有feat新功能fix修复bugdocs文档变更style格式调整不影响逻辑refactor重构不改变外部行为test新增或修改测试chore构建配置、依赖变更等杂项scope是影响范围比如模块名称、组件的名称可以省略。subject是简短描述用祈使句不超过50个字符不结尾带句号。实际例子feat(login): 增加手机号登录方式 fix(cart): 修复商品数量为负数时金额计算错误 docs(readme): 更新部署说明为什么这样推荐因为当你用git log --oneline浏览历史时一眼就能看出每次提交干了什么。配合上面的命令你能快速定位某个功能是哪个提交引入的再配合git revert精确回滚某个具体功能而不影响其他代码。我自己在维护开源项目时还会配合conventional commits的插件自动生成CHANGELOG提交信息不规范的话这一步根本做不了。如果团队对提交规范要求比较高还可以配合Commitlint和Husky做提交信息的自动校验。在项目里安装并配置完之后如果提交信息格式不对git会在git commit时直接拦截并给出提示。这个对老团队来说可能需要适应一下但新项目从第一天就接入后面几乎没有维护成本。5.2 分支命名与提交粒度好习惯都是“设计”出来的分支命名建议和提交规范呼应比如feature/登录模块、fix/购物车金额错误、hotfix/线上紧急修复。这样在git branch -r查看远程分支时一眼就能看出每个分支的目的。Pull Request和Merge Request的标题也可以用同样的前缀做到全链路统一。提交粒度上我建议遵循“原子提交”原则一个提交只做一件事。一个功能拆成多个提交完全没问题但一个提交里不要混入两个不相干的功能。这样可以大幅简化代码评审也能让后面的回滚更精准。为了实现这个目标你可能会经常用到前面提过的git add -p按hunk暂存这比一股脑git add .要专业得多。还有一个容易忽略的细节不要把生成物提交进仓库。比如node_modules、dist、.idea、.vscode这类目录都应该通过.gitignore排除。否则每次依赖安装或构建后文件内容变化都会被git跟踪提交历史里会出现大量无意义改动。项目初始化时就应该创建.gitignore并且在后续开发中不断完善。从工具使用的角度看这些规范看起来像是“额外约束”但我实际体会是它们恰恰是帮你省时间的。规范越清晰团队协作时无谓的沟通就越少。代码评审的焦点可以放在逻辑本身而不是纠结“这个提交为什么改了这个文件”。历史记录里少了那种“update”“111”之类的垃圾提交事后追溯出问题的速度会明显提升。最后再分享一个我在实际项目里总结的小技巧如果你在一个功能分支上开发了两三天提交了十几次在合并回主干前可以先用git rebase -i把这十几个琐碎的提交合并成几个有意义的提交把开发过程中的临时代码、调试输出、格式调整这类信息整理掉。这样合并到主干后历史会非常干净。这种做法对还没推送过远端的本地分支来说成本很低但对整个仓库的维护帮助巨大。我之前在项目里演示一次之后同事纷纷说“原来历史记录可以这么清爽”从此再也没人抱怨git历史乱了。
