1. 装好Git只是起点从新手阶段的踩坑到环境配置的完整链路我这两年带过不少新人也帮人排查过无数Git报错发现一个挺有意思的现象大部分人说学Git其实是卡在第一步——装是装上了但装在哪、怎么配、配完怎么用完全是一笔糊涂账。微博热搜里的git安装git安装教程git bash安装常年挂在技术热搜上也从侧面说明问题。很多人下载Git的时候直接无脑Next装完发现右键菜单里多了一堆Git Bash HereGit GUI Here然后就开始懵。这里我先给你一个建议Windows用户优先用Git Bash而不是Git CMD或者系统自带的PowerShell/CMD。Git Bash基于Mintty终端很多快捷键和命令提示符风格更接近Linux网上绝大多数教程的命令示例在Git Bash里敲是体验最好的不容易遇到莫名其妙的编码问题。我用PowerShell敲git命令不是不行只是踩过中文乱码的坑之后就一直固定在Git Bash里做演示了。1.1 各平台安装方式与版本选择先看Windows。Git官网下载慢是很多国内用户的第一个痛点。我实测下来Linux用户直接sudo apt install gitUbuntu/Debian系或dnf install gitFedora系最省事macOS用户有Homebrew就用brew install git没有的话装Xcode Command Line Tools时也会把Git带出来。Windows用户如果官网下载慢可以用国内镜像站搜索Git国内镜像就能找到清华、阿里、腾讯的镜像源版本号和官网保持同步下载速度能差出去一个量级。这里多说一句版本真的不是越新越好。Git 2.23引入switch/restore2.34之后git pull默认行为有调整但这些新特性对日常工作影响不大。稳定版本、够用就好我目前用的2.3x版本完全满足日常工作。装完第一件事不是急着建仓库而是验证安装在Git Bash里输入git --version能输出版本号就说明核心程序没问题。经常有人在这个环节就挂了——在PowerShell里输入git然后提示无法将git项识别为cmdlet、函数、脚本文件或可运行程序的名称这个代码块我后面专门讲别慌是环境变量的问题不是你没装好。1.2 第一次配置身份信息与换行符策略装好Git之后任何操作之前必须先做两件事设置用户名和邮箱。这不是可选项是必选项否则你每次commit都会弹个提示甚至直接拒绝提交。命令是git config --global user.name 你的名字 git config --global user.email 你的邮箱这个配置写入用户级别的配置文件一般位于~/.gitconfig全局生效。我见过有人把邮箱乱填的后面看的commit历史全是unknownlocalhost在团队里特别尴尬因为代码评审的时候CR系统根本匹配不到这个人。别偷懒填真实的。Windows用户还需要注意一个特别容易踩的坑换行符策略。Windows的文本换行是CRLFLinux/macOS是LFGit默认会自动转换如果你的团队有跨平台成员建议统一设置git config --global core.autocrlf true # Windows 用户 git config --global core.autocrlf input # mac/Linux 用户这个设置的意思是检出代码时自动把LF转成CRLFWindows提交时自动把CRLF转回LF。团队里混用Windows和macOS时不设置这个配置你会整天被整个文件都被标成已修改这种莫名其妙的diff困扰因为你看到的diff其实是行尾符的diff不是内容的diff。顺便再说一个和IDE相关的核心配置让Git记住CRLF转换逻辑避免VS Code或IDEA打开文件时看到奇怪的换行符。这个其实不需要额外设置只要上面两个命令执行了IDE端通常会自动跟随Git的转换逻辑。VS Code在这方面做得比较好基本无感。1.3 Git Bash与IDE集成装好Git之后VS Code和IDEAIntelliJ系列都会自动识别并集成Git。在VS Code里左侧源代码管理图标可以直接看到变更文件IDEA里则是右上角的Git窗口。很多人喜欢用IDE的图形界面我尊重这个习惯但必须提醒一句图形界面让你快速看到发生了什么但命令行才能让你真正理解为什么这样。我的建议是双轨制日常提交用IDE的界面速度快、可视化强涉及分支操作、冲突解决、提交记录修改这些精细活切回Git Bash操作。原因很简单IDE的图形化Git在某些场景下有简化或隐藏信息的倾向比如merge冲突时给你几个按钮点完了你根本不知道自己接受了谁的版本、为什么合并出来的代码不对。命令行至少让你面对事实。2. 日常开发里的高频命令流从init到push的完整脉络学习任何工具最忌讳一上来背命令清单。Git命令有上百条但你工作中真正高频使用的一只手数得过来。这一节我按实际开发场景把最核心的命令串成一条流水线每条命令都讲清楚为什么需要它。2.1 三区模型工作区、暂存区、版本库理解Git最关键的是一张图工作区、暂存区、版本库。很多人栽在Git命令上本质是没搞懂这张图。工作区你电脑里能看到的项目文件夹是你改代码的地方。暂存区Staging Area/Index一个临时存放准备提交的文件清单的中间区域。你用git add把文件从工作区放进来。版本库.git目录存放所有提交历史。我常用一个生活类比工作区是你家的厨房你切菜、备菜暂存区是餐桌旁的传菜台你把准备好的菜放上去版本库是冰箱的冷冻层菜一进去就冻住了想改得先解冻。这个类比帮你理解为什么需要git add和git commit两步——因为不是所有改动你都想拿出来摆盘你可能只想提交一部分文件。2.2 提交的正确姿势add、commit与提交信息规范新建仓库的完整链路是git init # 初始化仓库 git add . # 把所有改动加入暂存区 git commit -m feat: 初始化项目结构 git branch -M main # 把默认分支重命名为 main git remote add origin 仓库地址 git push -u origin main # 第一次推送绑定上游说几个细节。git add .会把当前目录下所有改动加入暂存区但建议你先看一眼git status确认不会误把临时文件或敏感配置提交进去。有个冷知识你可以在项目根目录建一个.gitignore文件把node_modules/、target/、.env这类目录或文件排除在Git版本控制之外。很多人提交了之后才发现.env里的数据库密码进去了然后不得不花大力气清理历史记录这个坑第一时间就要避开。git commit不是随便打的。提交信息建议遵循团队约定我用的是比较简单的规范feat:新功能、fix:修复、docs:文档、refactor:重构。这条规范能让你三个月后回头看提交历史时一眼就知道每个提交在干嘛不用读代码。还有一个高频操作git commit --amend。这个命令用于修改最近一次提交的信息或者把还没推送的提交补充进去。它的原理是用一个新的提交对象替换掉当前HEAD的提交对象。注意一个前提只能修改尚未推送的本地提交。如果已经push到远端了再amend就会造成本地和远端历史不一致除非你是单人开发而且清楚后果否则不要这么干。用法git add . # 如果有遗漏的文件先补加 git commit --amend -m 新的提交信息如果你想修改的不是最近一条而是更早的提交信息那就得用交互式rebasegit rebase -i HEAD~3会打开一个编辑器把你想修改的那条前面的pick改成reword保存退出后逐个修改提交信息。这个操作有个前提被修改的提交必须是还没推送的否则会重写远端历史害人害己。2.3 远程仓库操作remote、push、pull、fetch有了本地仓库接下来是和远程仓库打交道。远程仓库可以是GitHub、Gitee码云、GitLab或者公司内网部署的Git服务器。核心命令git remote -v # 查看远程仓库地址 git pull origin main # 拉取远端更新并自动合并 git fetch origin # 只拉取远端更新不自动合并 git push origin main # 推送本地提交到远端pull和fetch的区别很多人搞不清楚。fetch是把远端的最新提交拉下来更新远程跟踪分支但不改动你的工作区pull是fetch merge拉下来之后直接合并到你当前分支。日常开发中我推荐先fetch再决定怎么合并因为pull的自动合并有时候会静默产生一个merge commit提交历史看起来就多了一个不必要的分叉点。推送时最常遇到的报错是non-fast-forward意思是远端有本地没有的提交你直接push会被拒绝。这时候先git pull解决冲突后再push。不要用git push --force除非你非常确定自己在干什么——强制推送会覆盖远端历史可能把同事的提交弄丢这是协作事故级别的操作。2.4 免密配置SSH Key生成与Gitee/GitHub配置天天输账号密码很烦尤其是用HTTPS方式拉取私有仓库时还要处理凭据缓存周期的问题。更靠谱的方案是用SSH方式连接远程仓库一次配置长期免密。生成SSH密钥ssh-keygen -t ed25519 -C 你的邮箱一路回车就行。公钥内容一般在~/.ssh/id_ed25519.pub文件里用cat打开复制然后GitHub打开Settings → SSH and GPG keys → New SSH key粘贴保存Gitee则是设置 → SSH公钥页面粘贴。把仓库地址从HTTPS换成SSH格式git remote set-url origin gitgitee.com:用户名/仓库名.git之后push/pull都不用输入账号密码了。这里有个细节很多人会忽略如果你在公司内网或机房环境SSH端口22可能被封这时可以用SSH的443端口连接GitHubssh.github.com:443或者优先用公司提供的GitLab内网地址。另外ssh-keygen我推荐用ed25519算法比老的RSA短且安全新版本Git都支持。2.5 SSH认证失败的排查known_hosts与权限问题SSH免密配置好后最常见的坑是ssh: connect to host github.com port 22: Connection timed out或Permission denied (publickey)。前者是网络问题端口被墙或公司防火墙限制后者是密钥没配对。排查优先级测试连通性ssh -T gitgitee.comGitHub会返回Hi 用户名! Youve successfully authenticatedGitee返回您已通过SSH公钥认证。确认当前用的密钥ssh-add -l列出已加载的密钥。macOS用户注意系统升级后Keychain里的密钥可能失效需要重新ssh-add ~/.ssh/id_ed25519。确认远程地址用的是SSH格式而不是HTTPSgit remote -v查看地址开头是git才对。检查known_hosts第一次连接时会询问是否信任指纹输入yes并回车后会写入~/.ssh/known_hosts。如果之前连接失败或指纹变更过会有Host key verification failed报错此时删除对应条目重连即可。3. 分支与合并实战团队协作里的主战场单机开发用Git体会不深一旦进入团队协作分支和合并就是你每天都要面对的事。微博热搜里的git分支合并将git两个分支合并git冲突怎么解决常年占据Git类话题前排说明这是很多人的痛点。3.1 分支的本质与推荐工作流先搞清楚一件事分支不是目录的副本而是指向提交的指针。Git创建分支的成本极低只是一个40字节的引用。所以Git的哲学是鼓励多开分支。团队协作我推荐一个比较成熟的策略main或master作为稳定主干develop作为集成分支功能分支从develop切出来命名用feature/xxx修复分支用fix/xxx。这个模型在中小团队非常顺手git checkout develop # 切到集成分支 git pull # 拉最新 git checkout -b feature/login # 切出功能分支 # ...开发... git push -u origin feature/login # 推送功能分支 git checkout develop # 切回集成分支 git pull git merge feature/login # 合入功能分支git checkout -b是git branchgit switch的组合命令创建并切换到新分支。Git 2.23之后推荐用git switch -c语义更清晰。但在老版本或习惯场景下checkout依然完全可用。3.2 merge与rebase两种合并方式的取舍合并分支有两种主流方式git merge和git rebase。它们的区别是协作中争议最大的话题之一我用最简单的话讲清楚。merge保留了真实的提交历史和分叉结构产生一个merge commit记录两条历史在这里合并了。优点是不改动已有提交对历史是追加缺点是历史会存在分叉复杂项目里commit图会变得很难看。rebase是把当前分支的提交重新铺设到目标分支的顶端历史变成一条直线看起来非常干净。但代价是重写了提交的哈希值被rebase的提交实际上被替换成了新提交。我的建议个人开发分支合回主干前先rebase让历史干净共享分支一律merge不要rebase。一句话rebase适合自己的地方随便折腾merge适合公共的地方保守稳重。如果团队里有人把共享分支rebase了你会看到同事的提交在你的git记录里以新哈希出现整个团队的本地仓库都会陷入混乱。这条规则我不会妥协。3.3 冲突解决全过程演练冲突是每个用Git的人迟早要面对的别慌它是可以被规范化的操作。先看一个典型场景你和同事各自在feature/login和feature/pay分支上改了同一个文件的不同行两个分支合入develop时Git可能无法自动合并提示CONFLICT (content): Merge conflict in src/UserController.java。解决流程查看冲突文件git status会列出所有冲突文件标为both modified。打开文件冲突区域用 HEAD到 分支名标记中间是分隔线。上半部分是当前分支内容下半部分是合并进来的分支内容。人工判断保留哪些代码删掉冲突标记。这个过程必须人来决策机器无法替你判断业务逻辑的正确性。逐个文件解决完后git add src/UserController.java # 标记为已解决 git commit # 完成合并提交技巧分享git mergetool可以打开外部的图形化合并工具如Beyond Compare、Kdiff3但我个人更喜欢直接手改文件因为图形化工具虽然直观但在处理重复冲突时效率反而不如直接编辑。另外冲突文件多的时候先解决小的、后解决大的这样有成就感心态不容易崩。3.4 团队协作中的分支操作细节还有一个高频操作把远端某个分支合并到当前分支。有时候你可能不在自己的主分支上收到提测需求把release分支合到我的功能分支。此时git fetch origin release git merge origin/release注意这里merge的是origin/release即远端跟踪分支而不是本地release分支——如果没有本地分支直接merge本地release会报错。另外提一个容易忽略的场景开发中途切分支切不干净。如果你在A分支改了文件但没提交切到B分支时这些未提交的改动会跟着 带过去Git会把未提交改动带到任意切换后的工作区。如果你不想带过去可以用git stash暂存之后git stash pop恢复。这个命令是临时搁置的经典操作我几乎每天都在用。4. 高频报错的完整排查链路从报错到修复的每一步Git报错大概是新手劝退率最高的一环。微博热搜里一大串都是报错关键词比如git : 无法将“git”项识别为 cmdletfatal: not a git repositoryssh认证失败 gitgit清除账号密码每一个我都遇到过也都帮人排查过。这一节我把每条报错的完整排查链路写出来你照着走就行。4.1 git不是内部或外部命令环境变量与安装路径这条报错有几种变体PowerShell下的无法将git项识别为cmdlet、函数、脚本文件或可运行程序的名称CMD下的git 不是内部或外部命令以及fatal: git 不是有效的命令。核心原因是系统找不到git可执行文件的路径。排查链路先确认Git到底装在哪。Windows默认装在C:\Program Files\Git安装目录下有个cmd\git.exe。注意不是bin\git.exe那个是给Git Bash内部用的不一定能直接在系统PATH里用。检查环境变量PATH是否包含C:\Program Files\Git\cmd。手动添加控制面板 → 系统 → 高级系统设置 → 环境变量在Path里追加这个路径。添加完成后必须重开一个终端窗口因为环境变量只在终端启动时加载一次。验证git --version能输出版本号即成功。这里有个细节如果你是通过非管理员权限安装的Git安装目录可能不是Program Files而是用户目录下的AppData配置Path时路径得跟着变。另外如果你用的工具集成方式安装了Git比如通过VS Code或某些国产软件它的路径可能藏在很深的位置建议还是用官方安装包最方便排查。4.2 fatal: not a git repository工作目录的黑洞效应报错信息是fatal: not a git repository (or any of the parent directories): .git。很多新手看到not a git repository第一反应是我电脑里的Git是不是没装好——不是这条报错的含义是Git在当前目录和所有父级目录里都没找到.git目录。排查链路pwd确认当前所在目录。你不是在项目目录里或者你用cd进错了一个子目录。ls -a看看当前目录有没有.git隐藏文件夹。Git仓库的标志就是这个目录。如果你刚git clone完但clone命令报错或中断.git目录可能不完整。这种情况删掉重clone即可。如果你把整个项目目录复制或移动了.git一般会跟着走没问题但如果只复制了部分文件.git丢了Git就会把新目录当普通文件夹。这个报错最常见的原因就是跑git status的时候目录不对。如果你在一个看似项目目录的地方执行命令但那个目录其实是src或node_modules这种子目录Git会沿着父目录找.git。好在Git的设计是向上查找父目录所以只要项目根目录下有.git你在任何嵌套子目录里都能执行Git命令。如果你在某个深嵌套目录里还能运行说明仓库的.git就在某个上级目录。4.3 SSH认证失败从公钥到known_hosts一步步查报错gitgitee.com: Permission denied (publickey)或Connection timed out按这个顺序排查先确认你连的是哪个域名GitHub还是Gitee还是公司内网。用ssh -T分域名测试避免拿GitHub的公钥去连Gitee两边密钥不通用虽然你用的是同一把私钥但公钥要分别加到两边后台。确认当前私钥是否被识别ssh-add -l如果输出The agent has no identities说明SSH agent没加载私钥。执行ssh-add ~/.ssh/id_ed25519。Windows用户注意OpenSSH默认的密钥目录是~/.ssh但如果你用的是Git Bash安装时自带的SSH可能读的是Git安装目录下的配置。在一些冲突场景下可以设置GIT_SSH_COMMANDssh -i ~/.ssh/id_ed25519来强制指定密钥。如果报错是Host key verification failed执行ssh-keyscan -t ed25519 github.com ~/.ssh/known_hosts或者手动删除known_hosts里对应的旧条目。最后的兜底方案如果SSH实在调不通临时改用HTTPS地址先干活再慢慢查SSH问题。HTTPS方式虽然每次可能要输账号密码但配合凭据管理器体验也没那么差。4.4 账号密码被缓存的清除方法另一波高频报错和账号密码有关。Git在HTTPS模式下会在不同平台以不同方式缓存凭据——Windows上默认用Windows Credential ManagermacOS上用KeychainGit Bash里有时会写进~/.git-credentials。清除账号密码的常用方法git config --global --unset credential.helper # 取消全局凭据助手 git config --global credential.helper manager # Windows下重置为凭据管理器如果提示could not read Username for https://gitee.com: terminal prompts disabled多半是网络代理或凭据丢失导致。此时重新设置凭据并push就会弹窗要求输入账号密码输一次后重新缓存。这里有个实际经验如果你换了账号或者改了密码旧凭据会一直躲在系统凭据管理器里导致你每次push都用错账号。Windows下在控制面板 → 凭据管理器 → Windows凭据里删除Git或gitee相关的条目下一次push时就会提示重新输入。4.5 几个容易忽略的疑难杂症Git报错千奇百怪整理几个容易被搜到但很少被讲透的文件大小写问题Windows文件系统不区分大小写Foo.java和foo.java会被Git误认为是同一个文件。如果你在mac/Linux上把文件名改了个大小写Windows仓库更新下来会出现文件被标记为删除又新增的奇异状态。解决方案git config core.ignorecase false然后手动更新索引。文件太大推不上去HTTP错误413或RPC failed; curl 56通常是因为单文件超过GitHub的100MB限制或HTTP POST缓冲太小。解决方案用Git LFS下文展开或者调大缓冲git config http.postBuffer 524288000。换行符导致的diff异常之前提到过的CRLF问题。如果你在Windows上看到大量文件被标记为 modified但git diff里发现只有^M符号那就是换行符问题设置core.autocrlf后重新检出一遍git config core.autocrlf true git checkout -- .目录泄露热搜里的git目录泄露如何下载其实和安全测试相关——如果某个网站不小心把.git目录暴露到公网攻击者可以通过工具下载整个源代码。这个问题对开发者的启示是确保.git目录不要被Web服务器暴露尤其是静态托管或Nginx配置里要禁止访问.git路径。5. 进阶利器Git LFS、Worktree与reflog的实战视角基础命令熟练之后有几个进阶但不冷门的工具值得花时间研究。它们不是每天必备但遇到对应场景时能救大命而且搜的人不少。5.1 Git LFS大文件跟踪从安装到参数详解Git LFSLarge File Storage用一句话概括就是让Git可以用指针代替真正的大文件内容把大文件存到别处。Git本身对文件大小没有硬性限制但存储大文件的效率极低仓库体积膨胀严重clone速度慢到崩溃。安装LFSgit lfs install # 全局启用LFS一条命令 git lfs track *.psd # 跟踪特定类型的大文件 git add .gitattributes # 把跟踪规则提交进去之后正常git add、git commit、git push即可LFS会自动替换文件内容为指针。团队其他人clone时只要也安装了git lfs或在Git版本够新、自动支持LFS的场景下就能在pull时拉取真实内容。热搜里git lfs clone卡住是高频问题。卡住的原因通常是仓库里的LFS文件非常大clone时默认会并行下载多个文件被网络或服务端限速拖住。解法用GIT_LFS_SKIP_SMUDGE1 git clone跳过LFS文件的下载只拉取仓库主体。之后有需要再执行git lfs pull按需下载。或者git config lfs.concurrenttransfers 1把LFS下载并发数降到1减少被限速的概率。公司内网建议把LFS存储服务如git-lfs-server部署在近端CDN方式也可以但国内团队一般直接走内网。另一个参数git lfs migrate可以把已有的历史大文件强制迁移到LFS。但这是一个重写历史的操作执行前务必通知全组且最好在仓库冻结期内进行。5.2 Git Worktree同仓库多分支并行开发我在多分支并行开发时的最爱工具git worktree。它解决的问题是一个仓库只对应一个工作区切换分支要先把当前分支的改动处理干净。有时候你正在A分支开发突然线上出bug需要立即在新分支修复又不想把A分支的未提交代码stash掉——worktree就是为这种场景设计的。git worktree add ../project-hotfix -b hotfix/urgent这条命令会在../project-hotfix目录创建一个新工作区并且同时检出hotfix/urgent分支。这样你可以在两个目录下同时打开两个独立工作区互不干扰A分支继续写hotfix分支当场修复上线。列出和管理git worktree list # 查看所有工作区 git worktree remove ../project-hotfix # 移除工作区个人经验worktree配合git switch用体验很好。它是真正的隔离环境比在同一工作区里反复git stash省心太多。唯一的注意点是同一分支不能同时在两个worktree里检出Git会报错。5.3 reflog撤销操作的后悔药最后说一个Git不常被宣传但极其核心的功能git reflog。它记录的是Git的引用日志也就是HEAD指针的变化历史。简单说就好比你给电脑装了后悔药无论你执行了什么危险操作reset、rebase、commit --amend、删除分支只要操作在这个仓库里发生过reflog里就有记录。典型场景你不小心执行了git reset --hard HEAD~5五个提交一夜消失。git reflog输出里你能看到之前HEAD的位置——找到那个HARD之前的提交哈希执行git reset --hard 哈希十个提交也救得回来。这个功能我每次讲Git都会强调它给了你出错不用怕的底气。但前提是reflog是本地仓库的日志clone下来的人不会有你本地的reflog。也就是说未推送到远端的提交丢了reflog能救如果别人操作了远端你需要的是git fetch加上git reset --hard origin/分支名来对齐远端状态。5.4 其他几个值得练手的小操作git cherry-pick 提交哈希把某个分支的一个提交单独摘到当前分支。适用于线上修复时只合并特定bug fix提交而不合并整条分支。git stash -u连未跟踪的新文件一起暂存。git log --graph --oneline --all用图的方式查看所有分支的提交历史清爽直观。git diff --word-diff查看单词级别的diff差异比默认的行级diff更适合核对文案类的改动。6. 写在最后的一点个人心法如果让我给新手一个学习Git的路线建议那就是先实战跑通主干流程init/add/commit/push/pull再补分支和冲突merge/rebase/conflict最后再碰高级功能LFS/worktree/reflog。不要一上来就研究各种花哨的配置和别名那都是工具熟练之后顺手加的东西。另外我的一个经验是别怕在本地仓库里瞎折腾。Git最优秀的设计就是本地仓库足够强大你可以在本地随意实验、犯错、通过reflog恢复所有操作在push之前都是安全的。我当年学rebase的时候就专门创建一个临时仓库反复rebase、反复用reflog找回练了大概几十次把原理彻底刻在脑子里了。最后分享一个我处理Git问题的习惯报错信息里的每一个单词都值得看一遍。很多人只盯着 fatal 或者 error 这两个红色大写词后面的说明反而不读。Git的报错信息其实写得颇为友好大部分时候已经把原因和解决方向说得八九不离十了。习惯读完整报错很多问题你根本不用搜自己就能推出来。 Git从环境配置到团队协作：安装、命令、分支与报错排查全攻略
1. 装好Git只是起点从新手阶段的踩坑到环境配置的完整链路我这两年带过不少新人也帮人排查过无数Git报错发现一个挺有意思的现象大部分人说学Git其实是卡在第一步——装是装上了但装在哪、怎么配、配完怎么用完全是一笔糊涂账。微博热搜里的git安装git安装教程git bash安装常年挂在技术热搜上也从侧面说明问题。很多人下载Git的时候直接无脑Next装完发现右键菜单里多了一堆Git Bash HereGit GUI Here然后就开始懵。这里我先给你一个建议Windows用户优先用Git Bash而不是Git CMD或者系统自带的PowerShell/CMD。Git Bash基于Mintty终端很多快捷键和命令提示符风格更接近Linux网上绝大多数教程的命令示例在Git Bash里敲是体验最好的不容易遇到莫名其妙的编码问题。我用PowerShell敲git命令不是不行只是踩过中文乱码的坑之后就一直固定在Git Bash里做演示了。1.1 各平台安装方式与版本选择先看Windows。Git官网下载慢是很多国内用户的第一个痛点。我实测下来Linux用户直接sudo apt install gitUbuntu/Debian系或dnf install gitFedora系最省事macOS用户有Homebrew就用brew install git没有的话装Xcode Command Line Tools时也会把Git带出来。Windows用户如果官网下载慢可以用国内镜像站搜索Git国内镜像就能找到清华、阿里、腾讯的镜像源版本号和官网保持同步下载速度能差出去一个量级。这里多说一句版本真的不是越新越好。Git 2.23引入switch/restore2.34之后git pull默认行为有调整但这些新特性对日常工作影响不大。稳定版本、够用就好我目前用的2.3x版本完全满足日常工作。装完第一件事不是急着建仓库而是验证安装在Git Bash里输入git --version能输出版本号就说明核心程序没问题。经常有人在这个环节就挂了——在PowerShell里输入git然后提示无法将git项识别为cmdlet、函数、脚本文件或可运行程序的名称这个代码块我后面专门讲别慌是环境变量的问题不是你没装好。1.2 第一次配置身份信息与换行符策略装好Git之后任何操作之前必须先做两件事设置用户名和邮箱。这不是可选项是必选项否则你每次commit都会弹个提示甚至直接拒绝提交。命令是git config --global user.name 你的名字 git config --global user.email 你的邮箱这个配置写入用户级别的配置文件一般位于~/.gitconfig全局生效。我见过有人把邮箱乱填的后面看的commit历史全是unknownlocalhost在团队里特别尴尬因为代码评审的时候CR系统根本匹配不到这个人。别偷懒填真实的。Windows用户还需要注意一个特别容易踩的坑换行符策略。Windows的文本换行是CRLFLinux/macOS是LFGit默认会自动转换如果你的团队有跨平台成员建议统一设置git config --global core.autocrlf true # Windows 用户 git config --global core.autocrlf input # mac/Linux 用户这个设置的意思是检出代码时自动把LF转成CRLFWindows提交时自动把CRLF转回LF。团队里混用Windows和macOS时不设置这个配置你会整天被整个文件都被标成已修改这种莫名其妙的diff困扰因为你看到的diff其实是行尾符的diff不是内容的diff。顺便再说一个和IDE相关的核心配置让Git记住CRLF转换逻辑避免VS Code或IDEA打开文件时看到奇怪的换行符。这个其实不需要额外设置只要上面两个命令执行了IDE端通常会自动跟随Git的转换逻辑。VS Code在这方面做得比较好基本无感。1.3 Git Bash与IDE集成装好Git之后VS Code和IDEAIntelliJ系列都会自动识别并集成Git。在VS Code里左侧源代码管理图标可以直接看到变更文件IDEA里则是右上角的Git窗口。很多人喜欢用IDE的图形界面我尊重这个习惯但必须提醒一句图形界面让你快速看到发生了什么但命令行才能让你真正理解为什么这样。我的建议是双轨制日常提交用IDE的界面速度快、可视化强涉及分支操作、冲突解决、提交记录修改这些精细活切回Git Bash操作。原因很简单IDE的图形化Git在某些场景下有简化或隐藏信息的倾向比如merge冲突时给你几个按钮点完了你根本不知道自己接受了谁的版本、为什么合并出来的代码不对。命令行至少让你面对事实。2. 日常开发里的高频命令流从init到push的完整脉络学习任何工具最忌讳一上来背命令清单。Git命令有上百条但你工作中真正高频使用的一只手数得过来。这一节我按实际开发场景把最核心的命令串成一条流水线每条命令都讲清楚为什么需要它。2.1 三区模型工作区、暂存区、版本库理解Git最关键的是一张图工作区、暂存区、版本库。很多人栽在Git命令上本质是没搞懂这张图。工作区你电脑里能看到的项目文件夹是你改代码的地方。暂存区Staging Area/Index一个临时存放准备提交的文件清单的中间区域。你用git add把文件从工作区放进来。版本库.git目录存放所有提交历史。我常用一个生活类比工作区是你家的厨房你切菜、备菜暂存区是餐桌旁的传菜台你把准备好的菜放上去版本库是冰箱的冷冻层菜一进去就冻住了想改得先解冻。这个类比帮你理解为什么需要git add和git commit两步——因为不是所有改动你都想拿出来摆盘你可能只想提交一部分文件。2.2 提交的正确姿势add、commit与提交信息规范新建仓库的完整链路是git init # 初始化仓库 git add . # 把所有改动加入暂存区 git commit -m feat: 初始化项目结构 git branch -M main # 把默认分支重命名为 main git remote add origin 仓库地址 git push -u origin main # 第一次推送绑定上游说几个细节。git add .会把当前目录下所有改动加入暂存区但建议你先看一眼git status确认不会误把临时文件或敏感配置提交进去。有个冷知识你可以在项目根目录建一个.gitignore文件把node_modules/、target/、.env这类目录或文件排除在Git版本控制之外。很多人提交了之后才发现.env里的数据库密码进去了然后不得不花大力气清理历史记录这个坑第一时间就要避开。git commit不是随便打的。提交信息建议遵循团队约定我用的是比较简单的规范feat:新功能、fix:修复、docs:文档、refactor:重构。这条规范能让你三个月后回头看提交历史时一眼就知道每个提交在干嘛不用读代码。还有一个高频操作git commit --amend。这个命令用于修改最近一次提交的信息或者把还没推送的提交补充进去。它的原理是用一个新的提交对象替换掉当前HEAD的提交对象。注意一个前提只能修改尚未推送的本地提交。如果已经push到远端了再amend就会造成本地和远端历史不一致除非你是单人开发而且清楚后果否则不要这么干。用法git add . # 如果有遗漏的文件先补加 git commit --amend -m 新的提交信息如果你想修改的不是最近一条而是更早的提交信息那就得用交互式rebasegit rebase -i HEAD~3会打开一个编辑器把你想修改的那条前面的pick改成reword保存退出后逐个修改提交信息。这个操作有个前提被修改的提交必须是还没推送的否则会重写远端历史害人害己。2.3 远程仓库操作remote、push、pull、fetch有了本地仓库接下来是和远程仓库打交道。远程仓库可以是GitHub、Gitee码云、GitLab或者公司内网部署的Git服务器。核心命令git remote -v # 查看远程仓库地址 git pull origin main # 拉取远端更新并自动合并 git fetch origin # 只拉取远端更新不自动合并 git push origin main # 推送本地提交到远端pull和fetch的区别很多人搞不清楚。fetch是把远端的最新提交拉下来更新远程跟踪分支但不改动你的工作区pull是fetch merge拉下来之后直接合并到你当前分支。日常开发中我推荐先fetch再决定怎么合并因为pull的自动合并有时候会静默产生一个merge commit提交历史看起来就多了一个不必要的分叉点。推送时最常遇到的报错是non-fast-forward意思是远端有本地没有的提交你直接push会被拒绝。这时候先git pull解决冲突后再push。不要用git push --force除非你非常确定自己在干什么——强制推送会覆盖远端历史可能把同事的提交弄丢这是协作事故级别的操作。2.4 免密配置SSH Key生成与Gitee/GitHub配置天天输账号密码很烦尤其是用HTTPS方式拉取私有仓库时还要处理凭据缓存周期的问题。更靠谱的方案是用SSH方式连接远程仓库一次配置长期免密。生成SSH密钥ssh-keygen -t ed25519 -C 你的邮箱一路回车就行。公钥内容一般在~/.ssh/id_ed25519.pub文件里用cat打开复制然后GitHub打开Settings → SSH and GPG keys → New SSH key粘贴保存Gitee则是设置 → SSH公钥页面粘贴。把仓库地址从HTTPS换成SSH格式git remote set-url origin gitgitee.com:用户名/仓库名.git之后push/pull都不用输入账号密码了。这里有个细节很多人会忽略如果你在公司内网或机房环境SSH端口22可能被封这时可以用SSH的443端口连接GitHubssh.github.com:443或者优先用公司提供的GitLab内网地址。另外ssh-keygen我推荐用ed25519算法比老的RSA短且安全新版本Git都支持。2.5 SSH认证失败的排查known_hosts与权限问题SSH免密配置好后最常见的坑是ssh: connect to host github.com port 22: Connection timed out或Permission denied (publickey)。前者是网络问题端口被墙或公司防火墙限制后者是密钥没配对。排查优先级测试连通性ssh -T gitgitee.comGitHub会返回Hi 用户名! Youve successfully authenticatedGitee返回您已通过SSH公钥认证。确认当前用的密钥ssh-add -l列出已加载的密钥。macOS用户注意系统升级后Keychain里的密钥可能失效需要重新ssh-add ~/.ssh/id_ed25519。确认远程地址用的是SSH格式而不是HTTPSgit remote -v查看地址开头是git才对。检查known_hosts第一次连接时会询问是否信任指纹输入yes并回车后会写入~/.ssh/known_hosts。如果之前连接失败或指纹变更过会有Host key verification failed报错此时删除对应条目重连即可。3. 分支与合并实战团队协作里的主战场单机开发用Git体会不深一旦进入团队协作分支和合并就是你每天都要面对的事。微博热搜里的git分支合并将git两个分支合并git冲突怎么解决常年占据Git类话题前排说明这是很多人的痛点。3.1 分支的本质与推荐工作流先搞清楚一件事分支不是目录的副本而是指向提交的指针。Git创建分支的成本极低只是一个40字节的引用。所以Git的哲学是鼓励多开分支。团队协作我推荐一个比较成熟的策略main或master作为稳定主干develop作为集成分支功能分支从develop切出来命名用feature/xxx修复分支用fix/xxx。这个模型在中小团队非常顺手git checkout develop # 切到集成分支 git pull # 拉最新 git checkout -b feature/login # 切出功能分支 # ...开发... git push -u origin feature/login # 推送功能分支 git checkout develop # 切回集成分支 git pull git merge feature/login # 合入功能分支git checkout -b是git branchgit switch的组合命令创建并切换到新分支。Git 2.23之后推荐用git switch -c语义更清晰。但在老版本或习惯场景下checkout依然完全可用。3.2 merge与rebase两种合并方式的取舍合并分支有两种主流方式git merge和git rebase。它们的区别是协作中争议最大的话题之一我用最简单的话讲清楚。merge保留了真实的提交历史和分叉结构产生一个merge commit记录两条历史在这里合并了。优点是不改动已有提交对历史是追加缺点是历史会存在分叉复杂项目里commit图会变得很难看。rebase是把当前分支的提交重新铺设到目标分支的顶端历史变成一条直线看起来非常干净。但代价是重写了提交的哈希值被rebase的提交实际上被替换成了新提交。我的建议个人开发分支合回主干前先rebase让历史干净共享分支一律merge不要rebase。一句话rebase适合自己的地方随便折腾merge适合公共的地方保守稳重。如果团队里有人把共享分支rebase了你会看到同事的提交在你的git记录里以新哈希出现整个团队的本地仓库都会陷入混乱。这条规则我不会妥协。3.3 冲突解决全过程演练冲突是每个用Git的人迟早要面对的别慌它是可以被规范化的操作。先看一个典型场景你和同事各自在feature/login和feature/pay分支上改了同一个文件的不同行两个分支合入develop时Git可能无法自动合并提示CONFLICT (content): Merge conflict in src/UserController.java。解决流程查看冲突文件git status会列出所有冲突文件标为both modified。打开文件冲突区域用 HEAD到 分支名标记中间是分隔线。上半部分是当前分支内容下半部分是合并进来的分支内容。人工判断保留哪些代码删掉冲突标记。这个过程必须人来决策机器无法替你判断业务逻辑的正确性。逐个文件解决完后git add src/UserController.java # 标记为已解决 git commit # 完成合并提交技巧分享git mergetool可以打开外部的图形化合并工具如Beyond Compare、Kdiff3但我个人更喜欢直接手改文件因为图形化工具虽然直观但在处理重复冲突时效率反而不如直接编辑。另外冲突文件多的时候先解决小的、后解决大的这样有成就感心态不容易崩。3.4 团队协作中的分支操作细节还有一个高频操作把远端某个分支合并到当前分支。有时候你可能不在自己的主分支上收到提测需求把release分支合到我的功能分支。此时git fetch origin release git merge origin/release注意这里merge的是origin/release即远端跟踪分支而不是本地release分支——如果没有本地分支直接merge本地release会报错。另外提一个容易忽略的场景开发中途切分支切不干净。如果你在A分支改了文件但没提交切到B分支时这些未提交的改动会跟着 带过去Git会把未提交改动带到任意切换后的工作区。如果你不想带过去可以用git stash暂存之后git stash pop恢复。这个命令是临时搁置的经典操作我几乎每天都在用。4. 高频报错的完整排查链路从报错到修复的每一步Git报错大概是新手劝退率最高的一环。微博热搜里一大串都是报错关键词比如git : 无法将“git”项识别为 cmdletfatal: not a git repositoryssh认证失败 gitgit清除账号密码每一个我都遇到过也都帮人排查过。这一节我把每条报错的完整排查链路写出来你照着走就行。4.1 git不是内部或外部命令环境变量与安装路径这条报错有几种变体PowerShell下的无法将git项识别为cmdlet、函数、脚本文件或可运行程序的名称CMD下的git 不是内部或外部命令以及fatal: git 不是有效的命令。核心原因是系统找不到git可执行文件的路径。排查链路先确认Git到底装在哪。Windows默认装在C:\Program Files\Git安装目录下有个cmd\git.exe。注意不是bin\git.exe那个是给Git Bash内部用的不一定能直接在系统PATH里用。检查环境变量PATH是否包含C:\Program Files\Git\cmd。手动添加控制面板 → 系统 → 高级系统设置 → 环境变量在Path里追加这个路径。添加完成后必须重开一个终端窗口因为环境变量只在终端启动时加载一次。验证git --version能输出版本号即成功。这里有个细节如果你是通过非管理员权限安装的Git安装目录可能不是Program Files而是用户目录下的AppData配置Path时路径得跟着变。另外如果你用的工具集成方式安装了Git比如通过VS Code或某些国产软件它的路径可能藏在很深的位置建议还是用官方安装包最方便排查。4.2 fatal: not a git repository工作目录的黑洞效应报错信息是fatal: not a git repository (or any of the parent directories): .git。很多新手看到not a git repository第一反应是我电脑里的Git是不是没装好——不是这条报错的含义是Git在当前目录和所有父级目录里都没找到.git目录。排查链路pwd确认当前所在目录。你不是在项目目录里或者你用cd进错了一个子目录。ls -a看看当前目录有没有.git隐藏文件夹。Git仓库的标志就是这个目录。如果你刚git clone完但clone命令报错或中断.git目录可能不完整。这种情况删掉重clone即可。如果你把整个项目目录复制或移动了.git一般会跟着走没问题但如果只复制了部分文件.git丢了Git就会把新目录当普通文件夹。这个报错最常见的原因就是跑git status的时候目录不对。如果你在一个看似项目目录的地方执行命令但那个目录其实是src或node_modules这种子目录Git会沿着父目录找.git。好在Git的设计是向上查找父目录所以只要项目根目录下有.git你在任何嵌套子目录里都能执行Git命令。如果你在某个深嵌套目录里还能运行说明仓库的.git就在某个上级目录。4.3 SSH认证失败从公钥到known_hosts一步步查报错gitgitee.com: Permission denied (publickey)或Connection timed out按这个顺序排查先确认你连的是哪个域名GitHub还是Gitee还是公司内网。用ssh -T分域名测试避免拿GitHub的公钥去连Gitee两边密钥不通用虽然你用的是同一把私钥但公钥要分别加到两边后台。确认当前私钥是否被识别ssh-add -l如果输出The agent has no identities说明SSH agent没加载私钥。执行ssh-add ~/.ssh/id_ed25519。Windows用户注意OpenSSH默认的密钥目录是~/.ssh但如果你用的是Git Bash安装时自带的SSH可能读的是Git安装目录下的配置。在一些冲突场景下可以设置GIT_SSH_COMMANDssh -i ~/.ssh/id_ed25519来强制指定密钥。如果报错是Host key verification failed执行ssh-keyscan -t ed25519 github.com ~/.ssh/known_hosts或者手动删除known_hosts里对应的旧条目。最后的兜底方案如果SSH实在调不通临时改用HTTPS地址先干活再慢慢查SSH问题。HTTPS方式虽然每次可能要输账号密码但配合凭据管理器体验也没那么差。4.4 账号密码被缓存的清除方法另一波高频报错和账号密码有关。Git在HTTPS模式下会在不同平台以不同方式缓存凭据——Windows上默认用Windows Credential ManagermacOS上用KeychainGit Bash里有时会写进~/.git-credentials。清除账号密码的常用方法git config --global --unset credential.helper # 取消全局凭据助手 git config --global credential.helper manager # Windows下重置为凭据管理器如果提示could not read Username for https://gitee.com: terminal prompts disabled多半是网络代理或凭据丢失导致。此时重新设置凭据并push就会弹窗要求输入账号密码输一次后重新缓存。这里有个实际经验如果你换了账号或者改了密码旧凭据会一直躲在系统凭据管理器里导致你每次push都用错账号。Windows下在控制面板 → 凭据管理器 → Windows凭据里删除Git或gitee相关的条目下一次push时就会提示重新输入。4.5 几个容易忽略的疑难杂症Git报错千奇百怪整理几个容易被搜到但很少被讲透的文件大小写问题Windows文件系统不区分大小写Foo.java和foo.java会被Git误认为是同一个文件。如果你在mac/Linux上把文件名改了个大小写Windows仓库更新下来会出现文件被标记为删除又新增的奇异状态。解决方案git config core.ignorecase false然后手动更新索引。文件太大推不上去HTTP错误413或RPC failed; curl 56通常是因为单文件超过GitHub的100MB限制或HTTP POST缓冲太小。解决方案用Git LFS下文展开或者调大缓冲git config http.postBuffer 524288000。换行符导致的diff异常之前提到过的CRLF问题。如果你在Windows上看到大量文件被标记为 modified但git diff里发现只有^M符号那就是换行符问题设置core.autocrlf后重新检出一遍git config core.autocrlf true git checkout -- .目录泄露热搜里的git目录泄露如何下载其实和安全测试相关——如果某个网站不小心把.git目录暴露到公网攻击者可以通过工具下载整个源代码。这个问题对开发者的启示是确保.git目录不要被Web服务器暴露尤其是静态托管或Nginx配置里要禁止访问.git路径。5. 进阶利器Git LFS、Worktree与reflog的实战视角基础命令熟练之后有几个进阶但不冷门的工具值得花时间研究。它们不是每天必备但遇到对应场景时能救大命而且搜的人不少。5.1 Git LFS大文件跟踪从安装到参数详解Git LFSLarge File Storage用一句话概括就是让Git可以用指针代替真正的大文件内容把大文件存到别处。Git本身对文件大小没有硬性限制但存储大文件的效率极低仓库体积膨胀严重clone速度慢到崩溃。安装LFSgit lfs install # 全局启用LFS一条命令 git lfs track *.psd # 跟踪特定类型的大文件 git add .gitattributes # 把跟踪规则提交进去之后正常git add、git commit、git push即可LFS会自动替换文件内容为指针。团队其他人clone时只要也安装了git lfs或在Git版本够新、自动支持LFS的场景下就能在pull时拉取真实内容。热搜里git lfs clone卡住是高频问题。卡住的原因通常是仓库里的LFS文件非常大clone时默认会并行下载多个文件被网络或服务端限速拖住。解法用GIT_LFS_SKIP_SMUDGE1 git clone跳过LFS文件的下载只拉取仓库主体。之后有需要再执行git lfs pull按需下载。或者git config lfs.concurrenttransfers 1把LFS下载并发数降到1减少被限速的概率。公司内网建议把LFS存储服务如git-lfs-server部署在近端CDN方式也可以但国内团队一般直接走内网。另一个参数git lfs migrate可以把已有的历史大文件强制迁移到LFS。但这是一个重写历史的操作执行前务必通知全组且最好在仓库冻结期内进行。5.2 Git Worktree同仓库多分支并行开发我在多分支并行开发时的最爱工具git worktree。它解决的问题是一个仓库只对应一个工作区切换分支要先把当前分支的改动处理干净。有时候你正在A分支开发突然线上出bug需要立即在新分支修复又不想把A分支的未提交代码stash掉——worktree就是为这种场景设计的。git worktree add ../project-hotfix -b hotfix/urgent这条命令会在../project-hotfix目录创建一个新工作区并且同时检出hotfix/urgent分支。这样你可以在两个目录下同时打开两个独立工作区互不干扰A分支继续写hotfix分支当场修复上线。列出和管理git worktree list # 查看所有工作区 git worktree remove ../project-hotfix # 移除工作区个人经验worktree配合git switch用体验很好。它是真正的隔离环境比在同一工作区里反复git stash省心太多。唯一的注意点是同一分支不能同时在两个worktree里检出Git会报错。5.3 reflog撤销操作的后悔药最后说一个Git不常被宣传但极其核心的功能git reflog。它记录的是Git的引用日志也就是HEAD指针的变化历史。简单说就好比你给电脑装了后悔药无论你执行了什么危险操作reset、rebase、commit --amend、删除分支只要操作在这个仓库里发生过reflog里就有记录。典型场景你不小心执行了git reset --hard HEAD~5五个提交一夜消失。git reflog输出里你能看到之前HEAD的位置——找到那个HARD之前的提交哈希执行git reset --hard 哈希十个提交也救得回来。这个功能我每次讲Git都会强调它给了你出错不用怕的底气。但前提是reflog是本地仓库的日志clone下来的人不会有你本地的reflog。也就是说未推送到远端的提交丢了reflog能救如果别人操作了远端你需要的是git fetch加上git reset --hard origin/分支名来对齐远端状态。5.4 其他几个值得练手的小操作git cherry-pick 提交哈希把某个分支的一个提交单独摘到当前分支。适用于线上修复时只合并特定bug fix提交而不合并整条分支。git stash -u连未跟踪的新文件一起暂存。git log --graph --oneline --all用图的方式查看所有分支的提交历史清爽直观。git diff --word-diff查看单词级别的diff差异比默认的行级diff更适合核对文案类的改动。6. 写在最后的一点个人心法如果让我给新手一个学习Git的路线建议那就是先实战跑通主干流程init/add/commit/push/pull再补分支和冲突merge/rebase/conflict最后再碰高级功能LFS/worktree/reflog。不要一上来就研究各种花哨的配置和别名那都是工具熟练之后顺手加的东西。另外我的一个经验是别怕在本地仓库里瞎折腾。Git最优秀的设计就是本地仓库足够强大你可以在本地随意实验、犯错、通过reflog恢复所有操作在push之前都是安全的。我当年学rebase的时候就专门创建一个临时仓库反复rebase、反复用reflog找回练了大概几十次把原理彻底刻在脑子里了。最后分享一个我处理Git问题的习惯报错信息里的每一个单词都值得看一遍。很多人只盯着 fatal 或者 error 这两个红色大写词后面的说明反而不读。Git的报错信息其实写得颇为友好大部分时候已经把原因和解决方向说得八九不离十了。习惯读完整报错很多问题你根本不用搜自己就能推出来。