1. 为什么每个开发者都得先把Git这一关过了先说个我面试时经常遇到的场景不少简历上写着“熟练使用Git”结果问到底会的就是git add、git commit、git push三板斧一遇到冲突就懵一不小心把代码搞没了只能干瞪眼。Git这东西你说它难吧日常用到的高频命令两只手数得过来你说它简单吧它背后那套“快照”“指针”“暂存区”的机制理解不透彻的话出问题的时候真的会把人逼疯。这篇东西我本来是想写给团队里新来的同学看的后来想想干脆整理成文章发出来。围绕Git的基础使用我把从安装配置、日常提交、分支管理、远程协作到问题排查这一整条链路掰开揉碎讲一遍。不管你是刚入行的新人还是用了一两年Git但全靠肌肉记忆的老选手这篇文章都能帮你把基础补扎实顺便把那些藏在细节里的坑提前给你指出来。Git是个分布式版本控制系统这是它和SVN这类集中式版本控制最本质的区别。每个开发者本地都有一份完整的代码仓库历史也就是说就算远端服务器炸了你本地照样能提交、能查看历史、能回滚网络只是用来同步的那座桥。这个设计带来的好处是显而易见的速度快大部分操作都在本地完成、分支成本极低就是挪个指针、容灾性强人人都是完整备份。2. 安装与初始配置磨刀不误砍柴工2.1 不同操作系统下的安装方式Windows用户最简单的方式是直接去Git官网下载安装包一路Next到底。这里有个小细节很多人会忽略安装过程中有个“Adjusting your PATH environment”的步骤一定要选“Git from the command line and also from 3rd-party software”这样Git才能在CMD、PowerShell以及后续的各种IDE终端里直接被识别到。另外行尾转换建议选“Checkout as-is commit as-is”或者“Checkout Windows-style commit Unix-style”前者更省心后者更符合跨平台协作的惯例这个后面细说。macOS用户我推荐用Homebrew安装一条命令解决brew install git比起去官网下dmg包Homebrew可以顺带解决后续git-lfs等扩展工具的依赖问题升级也方便。Linux用户更不用纠结各发行版的包管理器直接装就行Ubuntu系是sudo apt install gitCentOS系是sudo yum install git。装完先验证一下git --version能输出版本号就说明装成功了。如果你发现系统里已经预装了一个老版本别急着用很多老版本的坑早就在新版里修掉了升级到最新稳定版是最稳妥的选择。2.2 身份信息配置与用户级配置管理装好之后有两件事必须立刻做否则你的提交记录里会带着一串乱码一样的user.name和user.email后面想改会非常麻烦。git config --global user.name 你的名字 git config --global user.email 你的邮箱这里有个容易踩的坑邮箱最好和你公司代码仓库或者你的GitHub/Gitee账号绑定的邮箱保持一致这样提交记录才能和账号关联上你在平台上的贡献绿格子才会被点亮。有些人对隐私比较敏感可以用GitHub提供的私有邮箱但一定要保证是同一个。除了身份信息我建议顺手把默认分支名和常用别名也配好git config --global init.defaultBranch main git config --global alias.st status git config --global alias.co checkout git config --global alias.br branch git config --global alias.cm commit配置完可以查看一下最终效果git config --list这套用户级配置会写在用户主目录下的.gitconfig文件里新开的任何一个仓库都会自动继承。干这一行久了你会慢慢体会到把这些基础配置一次性做到位后面能省下大量重复劳动。2.3 配置项里的几个细节这么调才顺手第二套让我省心的配置是换行符处理和中文文件名转义。这两个问题属于那种“不遇则已一遇就是大事”的类型。换行符问题Windows下文件默认用CRLF回车换行结尾而Linux/Mac用LF。如果团队成员跨平台协作Git会把这当成文件变更。最省心的方案是让Git替你处理git config --global core.autocrlf true # Windows用户 git config --global core.autocrlf input # Mac/Linux用户加了这个配置后在Windows上checkout代码时会自动转成CRLF提交时自动转回LF在Mac/Linux上则只在提交时把CRLF转成LF。这样仓库里永远存的是LF大家都用LF矛盾自然就消失了。中文文件名转义问题也很经典。在Linux环境下一提交含中文名的文件状态栏里就会显示成\346\265\213\350\257\225.txt这种八进制转义序列看着头大。关掉这个特性就清爽了git config --global core.quotepath false设置完之后中文文件名正常显示不会再有那串奇怪的转义码。3. 核心工作流从init到commit的完整链路3.1 工作区、暂存区、版本库这三个区域的关系搞明白这三个区域的区别Git就算入门了一半。工作区就是你在文件管理器里看到的那些目录和文件暂存区是个概念化的中间地带存放你准备好要提交的改动版本库则是每次提交后生成的快照历史。这套设计初看觉得多此一举实际用起来才知道妙处。它让你可以分批次、分逻辑地提交改动这个文件属于功能A那个文件属于修复B分开提交历史记录就清晰可查。后面做代码回退或者找bug时这种清晰度能救命。我见过有人图省事不管改了什么一条git add .全扔进去然后git commit -m update。这种习惯在个人项目里问题不大在团队项目里会让git log的可读性变得极差。查个历史变更看到的全是“update”“fix”具体改了什么全靠猜。好的提交信息应该能让人不打开代码就能大致知道这次改动触及了什么范围。3.2 提交时该用的高频命令逐条解析日常开发中最常敲的几行命令逐条拆开讲一下。git init在当前目录初始化一个仓库生成一个隐藏的.git目录。所有版本信息都存在这个目录里所以如果你要备份源码只拷源码目录不拷.git目录等于只备份了内容没备份历史。git add 文件名 # 或者 git add .把工作区里的改动加到暂存区。这里推荐一种更精细的用法git add -p它会让你逐块确认是否添加。改了大堆文件但只想起草提交其中一部分时这个交互式命令特别好用。git commit -m 提交说明把暂存区里的内容固化成一次提交。好的提交信息本身就是文档我一般习惯用一句话说清楚“做了什么”和“为什么做”比如fix: 修复注册页面在Safari下的布局错乱就比fix bug强得多。git status随时查看当前仓库状态哪些文件改了没暂存哪些暂存了没提交。初学阶段多敲这个命令可以帮你快速建立对三个区域的心智模型。git log --oneline --graph --all以图的形式展示提交历史。--oneline让每条记录只显示一行--graph把分支拓扑画出来--all把各个分支的提交都显示出来。这套流程跑顺了之后你背后其实是被Git的“三个区域哈希链表”这个机制支持着理解了这个机制遇到问题时你才能推理出来问题出在哪一层而不是靠百度碰运气。3.3 用.gitignore管好哪些文件不该进仓库有种文件“人人讨厌”编译产物、IDE配置、依赖包、日志文件。它们体积大、变动频繁且不该被提交到仓库里污染历史。解决办法就是.gitignore文件。以Node项目为例典型的忽略规则长这样node_modules/ dist/ build/ *.log .env .DS_Store .idea/ .vscode/需要注意的是.gitignore只对未追踪的文件生效。如果你之前已经把某个文件提交上去了再往.gitignore里加它的忽略规则是没用的必须先把文件从追踪列表里移除git rm --cached 文件名--cached保留了本地文件只是让Git不再追踪它这个操作和rm删文件的直观效果有本质区别。4. 分支与合并并发开发的安全边界4.1 分支的本质和日常操作分支是Git的“杀手锏”也是它被吹得最多的特性。原理上分支就是一个指向某次提交的指针。创建一个新分支只需要新建一个指针成本几乎为零所以Git官方才敢鼓励“早建分支、多建分支、随便建分支”。git branch dev # 新建dev分支 git checkout dev # 切到dev分支 git switch dev # 切换分支的新写法更语义化 git checkout -b feature # 新建并切换提一个比较实用的小习惯每次开始新功能前先确认自己当前在哪个分支上。因为git branch不带参数时只列本地分支你可能会在不知不觉中把不同功能的代码提交到了同一条分支上等要发布的时候才发现切不干净。查看分支信息时还可以加上这些参数git branch -a # 查看所有本地远端分支 git branch -vv # 查看分支跟踪关系4.2 合并时遇到冲突怎么办分支开发完要合并回主干最常用的两个命令是git merge和git rebase。merge会保留两条分支的全部历史形成一个合并节点好处是完整还原了开发的时间线坏处是历史图会有点乱。rebase则是把当前分支的提交“搬”到目标分支的最新提交之后让历史呈线性看着很清爽但千万不要对已经推送到远端的提交做rebase因为这会重写公共同历史导致别人的本地仓库和你不同步属于多人协作时的“禁忌操作”。合并遇到冲突是必然会发生的事关键是不要慌。冲突标记长这样 HEAD 这里是当前分支的内容 这里是合并进来的分支的内容 feature你需要做的就是打开文件逐个解决这些标记选择保留哪边、删掉哪边或者两边都保留再做个整合。解决完记得删掉标记然后重新提交。手动解决冲突时有个原则只改该改的别顺手做无关重构。那种“反正都打开这个文件了这段代码也顺手优化一下”的操作是合并冲突风控里最后悔的一步。4.3 基于release分支与hotfix分支的团队协作模型团队协作时一套稳定的分支模型比任何工具都重要。我用得比较顺手的组合是main主干、release发布分支、feature功能分支、hotfix紧急修复分支。主干永远保持可发布状态开发时从主干拉出feature分支干活做完后先合到release分支上做集成测试测试通过再合回主干打tag。线上出紧急bug时从主干直接拉出hotfix分支修复修完同时合回主干和release分支。这套模型不是银弹但胜在规则简单、每个人都能理解。重点不在于选哪套模型而在于团队成员是否都遵守同一套规则。最怕的就是那种“没有规则谁想怎么弄就怎么弄”的仓库迟早要出事。5. 连接远程仓库同步、推送与协作5.1 配置Gitee/GitHub的SSH密钥远程仓库协作的第一步是让本地和服务器之间建立一个可信的连接。HTTP方式每次都输密码太烦SSH方式配置好之后一劳永逸。这里以Gitee为例GitHub同理。先生成密钥对ssh-keygen -t rsa -b 4096 -C 你的邮箱一路回车后会在~/.ssh/目录下生成id_rsa私钥和id_rsa.pub公钥两个文件。私钥留在本地千万别泄露公钥可以随便给。然后查看公钥内容cat ~/.ssh/id_rsa.pub复制输出的内容登录Gitee/GitHub进入“设置” → “SSH公钥” → 粘贴保存。验证一下是否配置成功ssh -T gitgitee.com看到类似“Hi xxx! Youve successfully authenticated”的提示就说明通了。5.2 clone、push、pull这些命令的真正含义配置好SSH之后克隆仓库git clone gitgitee.com:用户名/仓库名.git这里注意区分两个协议HTTPS地址和SSH地址的区别在于SSH要配密钥HTTPS要输账号密码现在也支持token。日常用SSH更顺畅。改完代码要推送时git add . git commit -m XXX git push origin mainorigin是远程仓库的默认别名main是本地分支名。如果要拉取最新代码git pull origin main这里有个很多人容易迷惑的点git fetch和git pull有什么区别。fetch只是把远端的新提交下载到本地不会动你正在工作的代码pull则是fetch merge一步到位把远端改动合并到当前分支。我个人的习惯是先fetch再手动merge这样能清楚看到远端发生了什么变化再决定怎么合并双向避免被动接受一个无变的冲突。真正推送时还有个大坑如果你本地落后于远端直接pushGit会拒绝提交提示你先pull。这个机制是防止你覆盖掉同事已经推送的代码。正确姿势是先pull解决冲突后重新pushgit pull origin main git push origin main5.3 多人协作中的推送冲突处理多人协作时“你改了我也改了”这种事防不胜防。解决冲突的完整流程通常是先pull最新代码这时Git会把冲突标记写进发生冲突的文件。然后逐个打开带冲突标记的文件手动修改成你想要的样子删掉、、这些标记行。再add、commit、pushgit add 冲突解决完的文件 git commit -m merge: 解决XX模块冲突 git push origin main处理推送冲突的心法其实就一条先理解别人的代码意图再动手改。盲删“另一边”的内容是最容易出事故的操作。两个人同时在改同一个逻辑说明需求沟通环节可能出了问题冲突只是表象解决完代码冲突之后最好补个口头沟通对齐一下之后是谁来维护这段逻辑。6. 实用进阶技巧把基础命令用出效率来6.1 git commit --amend修改上一次提交这个命令的热度一直很高因为它解决了一个特别真实的场景提交完发现漏了个文件或者提交信息打错字了。--amend这个参数可以把暂存区里的新改动“修补”到最近一次提交里也不会额外新增一个提交节点。git add . # 把漏掉的文件先暂存 git commit --amend -m 修正后的提交说明执行之后最近一次提交会被“替换”成一个新提交。注意这意味着提交哈希变了所以这个命令同样不要用在已经推送到远端的提交上。如果你已经把那次提交push上去了但实在想改那只能用强制推送git push --force-with-lease origin main--force-with-lease比裸--force聪明些它会在推送前检查远端有没有被别人更新过如果远端已经推了新代码就终止防止你把同事的提交覆盖掉。这条命令是把双刃剑不建议你经常用但必须知道怎么安全地用。6.2 stash暂存切分支工作区“一键保存”正在开发功能A突然线上报了个紧急bug需要马上切分支修。直接切分支会被Git拦住因为有未提交的改动容易丢失。这时用git stash把当前工作区临时“储藏”起来git stash # 暂存当前改动 git checkout hotfix # 切去修bug git checkout dev # 修完切回来 git stash pop # 恢复之前的改动这个命令的好处在于“现场保护”。你可以随时切换工作状态又不会丢失上一个任务的进度。偶尔会有stash pop后发生冲突的情况处理方式跟普通冲突一样解决后重新add就行。6.3 用git reflog找回丢失的分支或提交这是Git里“后悔药”的终极形态。reflog维护了HEAD引用的历史变化记录即使你删了分支、reset掉了提交这些提交对象短期内仍然存在于对象库里通过reflog可以找回来。git reflog输出里每行都有一个哈希值找到你想回去的那个位置git reset --hard 哈希这个命令比git log的优势在于log只展示当前可见的提交reflog展示的是你对仓库做过的所有引用变动。见过一次性把分支删了又后悔的人用reflog基本都能救回来。唯一注意的点是reset的--hard会把工作区的未提交改动也一并清掉执行之前先确认好。7. 常见问题与排查技巧实录7.1 刚入门最容易踩的坑整理几个新人期几乎人人都会碰到的问题。问题1提交信息打错字/漏提交文件。推荐用--amend修补上一次提交已经在上面讲过不赘述。问题2误把密码、密钥提交进仓库。这个问题比想象的更常见。如果只在本地提交还没推送可以用git reset --soft HEAD~1回退提交让改动回到暂存区。如果已经推送了光删除文件再提交是不够的因为提交历史里还留着那条记录。比较麻烦但有效的做法是用git filter-branch重写历史或者用BFG工具清理。不过更推荐的是一劳永逸的做法提前把这些隐私文件写进.gitignore比如.env、*.pem这类后缀。问题3git pull时提示本地有未提交的改动会被覆盖。这种情况一般是远端和本地改到了同一个文件你又还没commit。常用解法是先把本地改动stashpull完再pop回来。但如果远端对那个文件的改动幅度很大pop时大概率会冲突和合并冲突的处理思路一样逐个解决即可。问题4git add .把不该加的文件加进去了。可以用git reset HEAD 文件名取消暂存。注意这个命令只是把文件从暂存区“拿出来”不会动你工作区里的内容。问题5代码写着写着改烂了想回退到某个版本的提交。分两种情况还没commit的git checkout -- 文件名可以把工作区文件还原成最近一次提交的状态已经commit但没push的git reset --hard 哈希直接回退。已push的改动建议用git revert 哈希生成一次反向提交把改动抵消掉而不是用reset强推避免给同事造成麻烦。7.2 遇到Detached HEAD是怎么回事这个提示翻译过来就是“游离的HEAD状态”本质上是HEAD指针没有指向某个分支而是直接指向了一个具体提交。产生这个状态最典型的原因是执行了git checkout 哈希而不是git checkout 分支名。在这个状态下做提交不会更新任何分支而是会变成一条“游离的”提交如果之后切换回分支这条提交就不容易直接看到了。处理方法是马上开个新分支把你所在的位置保存下来git checkout -b rescue-branch这样你做的所有提交都会保留在rescue-branch下随时可以合并回主分支。7.3 误删分支或仓库信息能救吗大部分能救。误删分支的话git reflog从输出里找到那条分支最后一次指向的提交哈希然后重新创建分支git branch recovered-branch 哈希如果连.git目录都没了那就真没了。但按照前面的设计你已经push过的提交在远端仓库还有一份重新clone回来把历史补齐就行。真正需要做的是把“本地未推送的重要commit”这件事消灭在萌芽状态定个规矩每次收工前把当前分支推送到远端倒逼自己养成同步的习惯。8. 日常使用的小建议Git的命令体系非常庞大花在它身上的每一分钟都不会白费。真正值得投入时间的地方是理解它背后的对象模型和数据流而不是死记硬背几十个命令的用法。那些用着不顺手的操作多半可以在原理层面找到原因为什么暂存区要存在、为什么rebase不能碰公共分支、为什么push被拒绝想明白这些之后命令只是水到渠成的事情。我给团队新人定的最低要求是能在不查资料的情况下独立完成“新分支开发 → 提交 → 推送到远端 → 发起合并请求 → 解决冲突”这一整条链路的操作。能流畅完成这条链路日常工作里绝大多数场景你都能应付。最后再分享一个小技巧如果某个命令总是敲不对与其反复翻文档不如自己写一套常用命令速查。把分支操作、撤销操作、查找操作分别记成备忘贴在工位旁边。所有工具的核心都是为人服务的Git也不例外用着顺手、能解决问题比什么都强。
1. 为什么每个开发者都得先把Git这一关过了先说个我面试时经常遇到的场景不少简历上写着“熟练使用Git”结果问到底会的就是git add、git commit、git push三板斧一遇到冲突就懵一不小心把代码搞没了只能干瞪眼。Git这东西你说它难吧日常用到的高频命令两只手数得过来你说它简单吧它背后那套“快照”“指针”“暂存区”的机制理解不透彻的话出问题的时候真的会把人逼疯。这篇东西我本来是想写给团队里新来的同学看的后来想想干脆整理成文章发出来。围绕Git的基础使用我把从安装配置、日常提交、分支管理、远程协作到问题排查这一整条链路掰开揉碎讲一遍。不管你是刚入行的新人还是用了一两年Git但全靠肌肉记忆的老选手这篇文章都能帮你把基础补扎实顺便把那些藏在细节里的坑提前给你指出来。Git是个分布式版本控制系统这是它和SVN这类集中式版本控制最本质的区别。每个开发者本地都有一份完整的代码仓库历史也就是说就算远端服务器炸了你本地照样能提交、能查看历史、能回滚网络只是用来同步的那座桥。这个设计带来的好处是显而易见的速度快大部分操作都在本地完成、分支成本极低就是挪个指针、容灾性强人人都是完整备份。2. 安装与初始配置磨刀不误砍柴工2.1 不同操作系统下的安装方式Windows用户最简单的方式是直接去Git官网下载安装包一路Next到底。这里有个小细节很多人会忽略安装过程中有个“Adjusting your PATH environment”的步骤一定要选“Git from the command line and also from 3rd-party software”这样Git才能在CMD、PowerShell以及后续的各种IDE终端里直接被识别到。另外行尾转换建议选“Checkout as-is commit as-is”或者“Checkout Windows-style commit Unix-style”前者更省心后者更符合跨平台协作的惯例这个后面细说。macOS用户我推荐用Homebrew安装一条命令解决brew install git比起去官网下dmg包Homebrew可以顺带解决后续git-lfs等扩展工具的依赖问题升级也方便。Linux用户更不用纠结各发行版的包管理器直接装就行Ubuntu系是sudo apt install gitCentOS系是sudo yum install git。装完先验证一下git --version能输出版本号就说明装成功了。如果你发现系统里已经预装了一个老版本别急着用很多老版本的坑早就在新版里修掉了升级到最新稳定版是最稳妥的选择。2.2 身份信息配置与用户级配置管理装好之后有两件事必须立刻做否则你的提交记录里会带着一串乱码一样的user.name和user.email后面想改会非常麻烦。git config --global user.name 你的名字 git config --global user.email 你的邮箱这里有个容易踩的坑邮箱最好和你公司代码仓库或者你的GitHub/Gitee账号绑定的邮箱保持一致这样提交记录才能和账号关联上你在平台上的贡献绿格子才会被点亮。有些人对隐私比较敏感可以用GitHub提供的私有邮箱但一定要保证是同一个。除了身份信息我建议顺手把默认分支名和常用别名也配好git config --global init.defaultBranch main git config --global alias.st status git config --global alias.co checkout git config --global alias.br branch git config --global alias.cm commit配置完可以查看一下最终效果git config --list这套用户级配置会写在用户主目录下的.gitconfig文件里新开的任何一个仓库都会自动继承。干这一行久了你会慢慢体会到把这些基础配置一次性做到位后面能省下大量重复劳动。2.3 配置项里的几个细节这么调才顺手第二套让我省心的配置是换行符处理和中文文件名转义。这两个问题属于那种“不遇则已一遇就是大事”的类型。换行符问题Windows下文件默认用CRLF回车换行结尾而Linux/Mac用LF。如果团队成员跨平台协作Git会把这当成文件变更。最省心的方案是让Git替你处理git config --global core.autocrlf true # Windows用户 git config --global core.autocrlf input # Mac/Linux用户加了这个配置后在Windows上checkout代码时会自动转成CRLF提交时自动转回LF在Mac/Linux上则只在提交时把CRLF转成LF。这样仓库里永远存的是LF大家都用LF矛盾自然就消失了。中文文件名转义问题也很经典。在Linux环境下一提交含中文名的文件状态栏里就会显示成\346\265\213\350\257\225.txt这种八进制转义序列看着头大。关掉这个特性就清爽了git config --global core.quotepath false设置完之后中文文件名正常显示不会再有那串奇怪的转义码。3. 核心工作流从init到commit的完整链路3.1 工作区、暂存区、版本库这三个区域的关系搞明白这三个区域的区别Git就算入门了一半。工作区就是你在文件管理器里看到的那些目录和文件暂存区是个概念化的中间地带存放你准备好要提交的改动版本库则是每次提交后生成的快照历史。这套设计初看觉得多此一举实际用起来才知道妙处。它让你可以分批次、分逻辑地提交改动这个文件属于功能A那个文件属于修复B分开提交历史记录就清晰可查。后面做代码回退或者找bug时这种清晰度能救命。我见过有人图省事不管改了什么一条git add .全扔进去然后git commit -m update。这种习惯在个人项目里问题不大在团队项目里会让git log的可读性变得极差。查个历史变更看到的全是“update”“fix”具体改了什么全靠猜。好的提交信息应该能让人不打开代码就能大致知道这次改动触及了什么范围。3.2 提交时该用的高频命令逐条解析日常开发中最常敲的几行命令逐条拆开讲一下。git init在当前目录初始化一个仓库生成一个隐藏的.git目录。所有版本信息都存在这个目录里所以如果你要备份源码只拷源码目录不拷.git目录等于只备份了内容没备份历史。git add 文件名 # 或者 git add .把工作区里的改动加到暂存区。这里推荐一种更精细的用法git add -p它会让你逐块确认是否添加。改了大堆文件但只想起草提交其中一部分时这个交互式命令特别好用。git commit -m 提交说明把暂存区里的内容固化成一次提交。好的提交信息本身就是文档我一般习惯用一句话说清楚“做了什么”和“为什么做”比如fix: 修复注册页面在Safari下的布局错乱就比fix bug强得多。git status随时查看当前仓库状态哪些文件改了没暂存哪些暂存了没提交。初学阶段多敲这个命令可以帮你快速建立对三个区域的心智模型。git log --oneline --graph --all以图的形式展示提交历史。--oneline让每条记录只显示一行--graph把分支拓扑画出来--all把各个分支的提交都显示出来。这套流程跑顺了之后你背后其实是被Git的“三个区域哈希链表”这个机制支持着理解了这个机制遇到问题时你才能推理出来问题出在哪一层而不是靠百度碰运气。3.3 用.gitignore管好哪些文件不该进仓库有种文件“人人讨厌”编译产物、IDE配置、依赖包、日志文件。它们体积大、变动频繁且不该被提交到仓库里污染历史。解决办法就是.gitignore文件。以Node项目为例典型的忽略规则长这样node_modules/ dist/ build/ *.log .env .DS_Store .idea/ .vscode/需要注意的是.gitignore只对未追踪的文件生效。如果你之前已经把某个文件提交上去了再往.gitignore里加它的忽略规则是没用的必须先把文件从追踪列表里移除git rm --cached 文件名--cached保留了本地文件只是让Git不再追踪它这个操作和rm删文件的直观效果有本质区别。4. 分支与合并并发开发的安全边界4.1 分支的本质和日常操作分支是Git的“杀手锏”也是它被吹得最多的特性。原理上分支就是一个指向某次提交的指针。创建一个新分支只需要新建一个指针成本几乎为零所以Git官方才敢鼓励“早建分支、多建分支、随便建分支”。git branch dev # 新建dev分支 git checkout dev # 切到dev分支 git switch dev # 切换分支的新写法更语义化 git checkout -b feature # 新建并切换提一个比较实用的小习惯每次开始新功能前先确认自己当前在哪个分支上。因为git branch不带参数时只列本地分支你可能会在不知不觉中把不同功能的代码提交到了同一条分支上等要发布的时候才发现切不干净。查看分支信息时还可以加上这些参数git branch -a # 查看所有本地远端分支 git branch -vv # 查看分支跟踪关系4.2 合并时遇到冲突怎么办分支开发完要合并回主干最常用的两个命令是git merge和git rebase。merge会保留两条分支的全部历史形成一个合并节点好处是完整还原了开发的时间线坏处是历史图会有点乱。rebase则是把当前分支的提交“搬”到目标分支的最新提交之后让历史呈线性看着很清爽但千万不要对已经推送到远端的提交做rebase因为这会重写公共同历史导致别人的本地仓库和你不同步属于多人协作时的“禁忌操作”。合并遇到冲突是必然会发生的事关键是不要慌。冲突标记长这样 HEAD 这里是当前分支的内容 这里是合并进来的分支的内容 feature你需要做的就是打开文件逐个解决这些标记选择保留哪边、删掉哪边或者两边都保留再做个整合。解决完记得删掉标记然后重新提交。手动解决冲突时有个原则只改该改的别顺手做无关重构。那种“反正都打开这个文件了这段代码也顺手优化一下”的操作是合并冲突风控里最后悔的一步。4.3 基于release分支与hotfix分支的团队协作模型团队协作时一套稳定的分支模型比任何工具都重要。我用得比较顺手的组合是main主干、release发布分支、feature功能分支、hotfix紧急修复分支。主干永远保持可发布状态开发时从主干拉出feature分支干活做完后先合到release分支上做集成测试测试通过再合回主干打tag。线上出紧急bug时从主干直接拉出hotfix分支修复修完同时合回主干和release分支。这套模型不是银弹但胜在规则简单、每个人都能理解。重点不在于选哪套模型而在于团队成员是否都遵守同一套规则。最怕的就是那种“没有规则谁想怎么弄就怎么弄”的仓库迟早要出事。5. 连接远程仓库同步、推送与协作5.1 配置Gitee/GitHub的SSH密钥远程仓库协作的第一步是让本地和服务器之间建立一个可信的连接。HTTP方式每次都输密码太烦SSH方式配置好之后一劳永逸。这里以Gitee为例GitHub同理。先生成密钥对ssh-keygen -t rsa -b 4096 -C 你的邮箱一路回车后会在~/.ssh/目录下生成id_rsa私钥和id_rsa.pub公钥两个文件。私钥留在本地千万别泄露公钥可以随便给。然后查看公钥内容cat ~/.ssh/id_rsa.pub复制输出的内容登录Gitee/GitHub进入“设置” → “SSH公钥” → 粘贴保存。验证一下是否配置成功ssh -T gitgitee.com看到类似“Hi xxx! Youve successfully authenticated”的提示就说明通了。5.2 clone、push、pull这些命令的真正含义配置好SSH之后克隆仓库git clone gitgitee.com:用户名/仓库名.git这里注意区分两个协议HTTPS地址和SSH地址的区别在于SSH要配密钥HTTPS要输账号密码现在也支持token。日常用SSH更顺畅。改完代码要推送时git add . git commit -m XXX git push origin mainorigin是远程仓库的默认别名main是本地分支名。如果要拉取最新代码git pull origin main这里有个很多人容易迷惑的点git fetch和git pull有什么区别。fetch只是把远端的新提交下载到本地不会动你正在工作的代码pull则是fetch merge一步到位把远端改动合并到当前分支。我个人的习惯是先fetch再手动merge这样能清楚看到远端发生了什么变化再决定怎么合并双向避免被动接受一个无变的冲突。真正推送时还有个大坑如果你本地落后于远端直接pushGit会拒绝提交提示你先pull。这个机制是防止你覆盖掉同事已经推送的代码。正确姿势是先pull解决冲突后重新pushgit pull origin main git push origin main5.3 多人协作中的推送冲突处理多人协作时“你改了我也改了”这种事防不胜防。解决冲突的完整流程通常是先pull最新代码这时Git会把冲突标记写进发生冲突的文件。然后逐个打开带冲突标记的文件手动修改成你想要的样子删掉、、这些标记行。再add、commit、pushgit add 冲突解决完的文件 git commit -m merge: 解决XX模块冲突 git push origin main处理推送冲突的心法其实就一条先理解别人的代码意图再动手改。盲删“另一边”的内容是最容易出事故的操作。两个人同时在改同一个逻辑说明需求沟通环节可能出了问题冲突只是表象解决完代码冲突之后最好补个口头沟通对齐一下之后是谁来维护这段逻辑。6. 实用进阶技巧把基础命令用出效率来6.1 git commit --amend修改上一次提交这个命令的热度一直很高因为它解决了一个特别真实的场景提交完发现漏了个文件或者提交信息打错字了。--amend这个参数可以把暂存区里的新改动“修补”到最近一次提交里也不会额外新增一个提交节点。git add . # 把漏掉的文件先暂存 git commit --amend -m 修正后的提交说明执行之后最近一次提交会被“替换”成一个新提交。注意这意味着提交哈希变了所以这个命令同样不要用在已经推送到远端的提交上。如果你已经把那次提交push上去了但实在想改那只能用强制推送git push --force-with-lease origin main--force-with-lease比裸--force聪明些它会在推送前检查远端有没有被别人更新过如果远端已经推了新代码就终止防止你把同事的提交覆盖掉。这条命令是把双刃剑不建议你经常用但必须知道怎么安全地用。6.2 stash暂存切分支工作区“一键保存”正在开发功能A突然线上报了个紧急bug需要马上切分支修。直接切分支会被Git拦住因为有未提交的改动容易丢失。这时用git stash把当前工作区临时“储藏”起来git stash # 暂存当前改动 git checkout hotfix # 切去修bug git checkout dev # 修完切回来 git stash pop # 恢复之前的改动这个命令的好处在于“现场保护”。你可以随时切换工作状态又不会丢失上一个任务的进度。偶尔会有stash pop后发生冲突的情况处理方式跟普通冲突一样解决后重新add就行。6.3 用git reflog找回丢失的分支或提交这是Git里“后悔药”的终极形态。reflog维护了HEAD引用的历史变化记录即使你删了分支、reset掉了提交这些提交对象短期内仍然存在于对象库里通过reflog可以找回来。git reflog输出里每行都有一个哈希值找到你想回去的那个位置git reset --hard 哈希这个命令比git log的优势在于log只展示当前可见的提交reflog展示的是你对仓库做过的所有引用变动。见过一次性把分支删了又后悔的人用reflog基本都能救回来。唯一注意的点是reset的--hard会把工作区的未提交改动也一并清掉执行之前先确认好。7. 常见问题与排查技巧实录7.1 刚入门最容易踩的坑整理几个新人期几乎人人都会碰到的问题。问题1提交信息打错字/漏提交文件。推荐用--amend修补上一次提交已经在上面讲过不赘述。问题2误把密码、密钥提交进仓库。这个问题比想象的更常见。如果只在本地提交还没推送可以用git reset --soft HEAD~1回退提交让改动回到暂存区。如果已经推送了光删除文件再提交是不够的因为提交历史里还留着那条记录。比较麻烦但有效的做法是用git filter-branch重写历史或者用BFG工具清理。不过更推荐的是一劳永逸的做法提前把这些隐私文件写进.gitignore比如.env、*.pem这类后缀。问题3git pull时提示本地有未提交的改动会被覆盖。这种情况一般是远端和本地改到了同一个文件你又还没commit。常用解法是先把本地改动stashpull完再pop回来。但如果远端对那个文件的改动幅度很大pop时大概率会冲突和合并冲突的处理思路一样逐个解决即可。问题4git add .把不该加的文件加进去了。可以用git reset HEAD 文件名取消暂存。注意这个命令只是把文件从暂存区“拿出来”不会动你工作区里的内容。问题5代码写着写着改烂了想回退到某个版本的提交。分两种情况还没commit的git checkout -- 文件名可以把工作区文件还原成最近一次提交的状态已经commit但没push的git reset --hard 哈希直接回退。已push的改动建议用git revert 哈希生成一次反向提交把改动抵消掉而不是用reset强推避免给同事造成麻烦。7.2 遇到Detached HEAD是怎么回事这个提示翻译过来就是“游离的HEAD状态”本质上是HEAD指针没有指向某个分支而是直接指向了一个具体提交。产生这个状态最典型的原因是执行了git checkout 哈希而不是git checkout 分支名。在这个状态下做提交不会更新任何分支而是会变成一条“游离的”提交如果之后切换回分支这条提交就不容易直接看到了。处理方法是马上开个新分支把你所在的位置保存下来git checkout -b rescue-branch这样你做的所有提交都会保留在rescue-branch下随时可以合并回主分支。7.3 误删分支或仓库信息能救吗大部分能救。误删分支的话git reflog从输出里找到那条分支最后一次指向的提交哈希然后重新创建分支git branch recovered-branch 哈希如果连.git目录都没了那就真没了。但按照前面的设计你已经push过的提交在远端仓库还有一份重新clone回来把历史补齐就行。真正需要做的是把“本地未推送的重要commit”这件事消灭在萌芽状态定个规矩每次收工前把当前分支推送到远端倒逼自己养成同步的习惯。8. 日常使用的小建议Git的命令体系非常庞大花在它身上的每一分钟都不会白费。真正值得投入时间的地方是理解它背后的对象模型和数据流而不是死记硬背几十个命令的用法。那些用着不顺手的操作多半可以在原理层面找到原因为什么暂存区要存在、为什么rebase不能碰公共分支、为什么push被拒绝想明白这些之后命令只是水到渠成的事情。我给团队新人定的最低要求是能在不查资料的情况下独立完成“新分支开发 → 提交 → 推送到远端 → 发起合并请求 → 解决冲突”这一整条链路的操作。能流畅完成这条链路日常工作里绝大多数场景你都能应付。最后再分享一个小技巧如果某个命令总是敲不对与其反复翻文档不如自己写一套常用命令速查。把分支操作、撤销操作、查找操作分别记成备忘贴在工位旁边。所有工具的核心都是为人服务的Git也不例外用着顺手、能解决问题比什么都强。
