你是不是也有过这样的经历一个项目文件夹里躺着“需求文档_v1_最终版.doc”“需求文档_v2_真最终版.doc”“需求文档_v3_打死不改版.doc”等到第N次改完连你自己都分不清到底哪份是最新的。代码项目比文档更严重。稍微大一点的工程几十个文件互相依赖你根本不可能靠“复制一份文件夹”来管理版本。Git就是解决这个问题的工具而且它几乎成了程序员入行绕不开的第一道门槛。这篇文章不打算按官方文档的目录给你念一遍我想从一个真实使用者的角度把Git到底解决了什么问题、最核心的概念怎么理解、日常怎么用、踩过哪些坑一次性说清楚。不管你是刚接触Git的新手还是已经用了一两年但一直是“命令背下来了原理没搞懂”的状态这篇文章都值得你花二十分钟看完。理解背后的逻辑比死记命令有用得多。1. 为什么必须用Git——先想清楚它到底解决了什么很多人第一次接触Git是被面试题和公司规范逼着学的。但如果不知道它究竟解决了什么问题你学的时候会特别别扭总觉得命令又多又绕。先别急着敲命令我们回到最原始的场景。1.1 在没有版本管理的日子里到底有多痛我见过一些没系统用过版本管理的人他们的真实工作方式是在项目文件夹里手动复制备份比如“project_20240101”“project_backup”“project_new”偶尔还会用U盘拷贝一份带到另一台电脑上接着改。这套做法短期看没什么问题但一旦项目超过一周、改动超过几十次麻烦就来了。第一你不知道某个文件是什么时候改的、为什么改想对比新旧版本只能靠肉眼。第二如果你在“project_backup”上改了半天回头发现改错了想回到“project_20240101”的状态只能手动把文件拷回去中间所有零散的调整全都丢失。第三两个人同时改同一个项目的时候要么互相等要么邮件传来传去一个不小心就把对方的改动覆盖了。Git本质上就是把你“手动复制文件夹、改坏了再手动回退”这套工作流程做得更规范、更自动化、更不容易出错。它记录项目在每一个时间点的完整快照你随时可以回到任意一个历史状态也可以从任意一个历史状态拉出新分支做尝试。1.2 Git与网盘/U盘备份的本质区别有人可能会说我用网盘同步不也能备份吗能但思路完全不一样。网盘备份解决的是“数据不丢失”它保存的是文件的“最新状态”你最多能恢复到之前某个时间点的版本但通常做不到“只恢复某几个文件而不影响其他文件”更做不到“同时维护两条互不干扰的改动线”。Git解决的是“变化可追溯、路径可选择”。每次提交相当于给整个项目拍了一张照片并且记录了这次拍照和上次拍照之间的差异是谁、为什么、在哪、改了什么。你不仅知道自己现在在哪还知道自己怎么走到这里的。而分支这个东西则相当于让你可以在不同的平行世界之间来回穿梭每个世界里的代码状态互不干扰。1.3 一套流程解决四个核心痛点用Git管项目日常收益其实是四个很实在的点。一是回溯。你改崩了、删错了、合并出了问题一条命令回到之前的稳定版本不用拍着大腿后悔。二是并行。不同功能可以在不同分支上开发互不踩踏做完一个合并一个项目始终保持可用状态。三是审计。每一行代码都能追溯到是谁、在哪个提交、为什么加进来的这对代码评审和问题排查帮助巨大。四是容灾。配合远程仓库你的代码不仅存在本地还能推送到服务器或同事的机器上本机硬盘坏了也不至于一切归零。理解了这些问题再看后面的命令你就知道每一步是在干什么了。2. Git核心概念一次讲透仓库、提交、分支Git的命令确实多但真正核心的概念没有几个。把这几个理解透了你会发现在命令行里操作Git基本不需要“背命令”而是“根据你要完成的目标自然知道该用什么命令”。2.1 三个区工作区、暂存区、本地仓库很多新手最困惑的是我已经git add了为什么还要git commit用生活里的事打比方。工作区是你的“桌面”你在这里写代码、改文件直接操作的都是真实内容。暂存区相当于“待发货区”你把想纳入本次打包的东西挑出来放进去可以选择只挑一部分也可以全部放进去。本地仓库则是“仓库货架”只有放上货架的东西才算形成一个正式的历史节点。所以操作顺序是在工作区里改文件然后用git add把改动放进暂存区最后用git commit把暂存区里的内容打包存档到本地仓库。为什么要多一个暂存区因为现实中你不可能每次都把所有改动一并提交有时候这个文件改了一半还没有完成那个文件已经可以提交了。分开放的灵活性可以让你保持提交的历史干净清晰。2.2 提交commit的本质快照而非差异很多人第一次看git log会以为提交保存的是“和上一版的差异”。这个理解不算全错但会阻碍你更深的理解。更准确的模型是每次commitGit把你项目里所有文件的状态完整照了一张相并存成一次快照。它内部为了省空间会复用相同的文件你看上去可能只有几十KB的差异但逻辑上每次提交都代表“此时此刻整个项目长什么样”。理解这一点你就能明白几个现象。为什么Git切换分支那么快因为它不是去把文件“改成另一个样子”而是直接把工作区恢复到那个快照的状态。为什么误删文件还能恢复因为最近一次提交里还存着那个文件的完整版本。为什么说“Git回退”实际上是“创建新的提交”而不是“删除历史”因为历史快照一直在你只是把当前工作区的指针移到了另一个位置。2.3 分支一条几乎零成本的时间线如果只挑一个Git最值得学的特性我会选分支。因为它的设计在实用层面给人带来的自由度其他版本管理工具很难比。你可以把分支理解成“新开了一条平行时间线”。主分支通常叫main或master上放着稳定的代码你在feature分支上做新功能时随便改、随便提交都不会影响主线上其他人的工作。等新功能稳定了再把feature分支合并回去。Git的分支之所以好用是因为它的实现成本极低。真正在底层分支只是指向某个提交的一个“指针”新建分支只是多写一个名字不是把代码复制一份。所以你想开多少个分支就能开多少个想去掉一个分支也只是一条命令的事。相比之下其他一些版本管理系统新建分支往往意味着目录拷贝最终大家都不爱开分支。2.4 几个常被误解的名词HEAD、origin、main说到这儿我顺便把几个高频词解释一下因为很多人虽然天天看到却不一定知道它们在说什么。HEAD是“当前所在位置”的指针它指向你当前正在操作的提交。切换分支本质上是把HEAD换到另一个分支指向的提交上去。origin是远程仓库的默认名字它不指代码托管平台而是指“你本地项目所关联的那个远程地址”的一个代称。main是主分支的默认名字现在新的仓库一般默认叫main老项目叫master本质没什么区别只是改名了。理清这几个词你以后看到git status里出现“Your branch is ahead of origin/main by 2 commits”就不会懵了它说的是你本地现在比远程多两个提交可以准备推上去了。3. 从零到一一套能直接落地的日常流程理论说完了接下来走一遍真实的操作流程。下面每一条命令都是我在日常项目里会用到的不是教学演示那种一长串花哨参数。你跟着做一遍就会形成肌肉记忆。3.1 初始化与第一次提交拿到一个新项目第一步是进入项目目录然后执行git init。这会生成一个.git目录里面保存着你这个仓库的所有历史信息。不要手动去改这个目录里的东西让它自己管自己就行。接着你需要让Git知道你是谁因为每次提交都要记录作者。设置一次全局生效git config --global user.name 你的名字 git config --global user.email 你的邮箱然后做第一次提交git add . git commit -m 初始化项目这里有个细节想提醒你git add .是把所有改动加进暂存区但前提是你的项目里没有不该提交的文件。很多新手第一次就这么干结果把几百MB的依赖包、数据库备份、IDE配置文件全都提交进去了后面要清理非常麻烦。所以第一次提交之前建议先建好.gitignore文件把不需要纳入版本管理的路径排除掉。后面我会专门讲这个文件的坑。3.2 日常开发三连add、commit、push日常开发的核心操作其实就三个命令的组合。改完代码之后你先用git status看一眼当前有哪些改动确认一下是不是符合预期的那些文件。然后git add把这些改动加入暂存区接着git commit -m 描述这次改了什么把改动固化成一条历史记录。如果项目关联了远程仓库比如代码托管平台上的项目最后还需要git push把本地的新提交推上去这样别人才看得到你的改动。这套流程看似简单但我见过不少人在这上面吃亏具体表现为commit太频繁、commit信息随意、push前不看状态。我自己的习惯是每次commit对应一个逻辑完整的小改动比如“修复登录页在手机上不居中的问题”而不是“改了一些东西”。这样以后看git log每一行都像目录一样清楚。3.3 分支开发做新功能别再直接改主线很多人团队的规范是主线分支上的代码永远要保持可运行状态。那么开发一个新功能你就不要直接在main上改了。正确的做法是新建一个分支出来git checkout -b feature/login这条命令的意思是新建一个名为feature/login的分支并立即切换过去。你在这个分支上正常开发随便提交完全不影响main上的稳定代码。等这个功能做完了、自测过了再合并回去。这里有个使用习惯上的建议分支名要能看出目的。feature/login表示“登录功能”bugfix/payment表示“修复支付相关的Bug”不要用 “test”“new” “aaa” 这种名字。因为分支多了之后你自己都不记得当初为什么开这个分支。3.4 合并与冲突处理功能开发完要合并回主分支操作是git checkout main git pull git merge feature/login先把本地main更新到最新再把feature分支合并进来。如果两个分支都改了同一个文件同一段代码就可能出现冲突。冲突出现时Git会在文件里用类似这样的标记把两边内容标出来 HEAD 你当前所在分支的代码 要合并过来分支的代码 feature/login你需要手动决定保留哪一边或者两边都保留然后把标记行删掉保存文件再git add最后git commit。这个过程第一次遇到会觉得有点慌但碰过几次就会发现其实冲突不是坏事它是在强制你“认真核对两边到底改了什么”总比静默覆盖导致以后莫名其妙丢代码强得多。3.5 写提交信息的小习惯提交信息这件事我想单独拿出来说一下因为它的重要性被很多人严重低估了。三个月后你需要找出“当时是谁改了某个接口的参数、为什么要改”唯一能看的就是git log和提交信息。如果提交信息是“update”“modify”这种基本等于没有记录。我常用的提交信息格式是这样fix: 修复登录接口在空密码时返回500的问题 feat: 新增用户注册后的欢迎邮件通知 refactor: 重构文件上传模块抽离公共校验逻辑前面的fix、feat、refactor表示这次提交的类型后面的内容是简洁描述。不要写“fix bug”要说清楚修了什么Bug。写完提交信息后我通常会自觉检查一遍如果发现描述不够具体宁可再amend一次改掉也不要留下垃圾记录。4. 真实项目里踩过的坑问题解决方案实录命令用熟了之后真正的门槛其实在于各种意外情况。这一节我把这些年自己踩过、以及身边同事踩过的比较典型的问题整理出来每个都附带解决方案。4.1 误提交了大文件或敏感信息怎么办这是非常常见的情况。比如你不小心把几十MB的数据库备份文件提交进去了或者把包含密钥的配置文件提交了。这时候如果只是删除文件再提交一次历史记录里仍然留着那个大文件仓库体积还是很大密钥也可能已经泄露。分两类处理。如果是还想保留文件但不让它进版本库执行git rm --cached 文件名这会把它从Git的跟踪列表中移除但本地文件还在。然后把文件名写进.gitignore再提交一次。如果是想彻底从历史里抹掉某个文件就需要用到git filter-repo这类工具重写历史操作复杂度高且如果这个仓库有其他人共用会导致所有人的历史都冲突建议由经验丰富的人操作。如果你发现自己把密钥提交了我可以给你一个很诚实的建议最快的“修复”是立即吊销那组密钥、重新生成新的而不是费很大力气去清理历史。因为只要它已经推到了远程就不能排除已经被别人拉走了。清理历史是为了以后不再把它当成有效凭证而不是为了“当它没发生过”。4.2 提交信息写错了怎么办提交之后发现信息写错了或者想补充一些改动到上一次提交里用git commit --amend这个命令会把最后一次提交替换成一条新的提交可以用来修改提交信息也可以先把遗漏的改动git add了再一起amend进去。但要注意amend会改变提交的哈希值所以只适合改“还没推送”的最后一次提交。如果已经push给团队其他人了就不要再amend了否则会引发同步混乱。4.3 合并冲突处理的正确顺序很多人合并遇到冲突就懵了一通乱改。我建议你养成一个固定的处理流程。第一步先git status看看有哪些文件冲突。第二步逐个打开冲突文件看清和标记之间的内容。第三步确认两边的代码分别是什么意图保留需要的内容。第四步删掉所有标记行保存文件。第五步git add这个文件表示冲突已解决。第六步其他文件也都处理完之后git commit生成一个合并提交。一个很实用的建议是处理冲突时优先用IDE或编辑器自带的合并工具。比如VS Code里会把两边代码和最终结果并列展示点几下按钮就能选择保留哪边比直接在命令行里看标记行舒服多了。如果你用的是专业IDE它们的Git面板基本都有图形化解决冲突的入口效率高很多。4.4 .gitignore的常见误用.gitignore是每个项目都应该有的文件但我发现很多人对它有一个误解以为只要把文件加进.gitignore它就会被Git忽略。事实是.gitignore只对“还没被Git跟踪”的文件生效。如果你已经把某个文件提交过了之后再把它加进.gitignore是完全无效的它依然会被追踪。要先执行git rm --cached解除跟踪再配合.gitignore才能真正忽略它。另一个常见的坑是写得太宽泛。比如写了一个“*.log”结果把启动时需要保留的关键日志文件也忽略了。我的习惯是尽量写具体路径比如“logs/”表示只忽略logs目录而不是把所有后缀匹配的全忽略避免误伤。4.5 常见问题速查表问题具体表现解决方案文件改动找不回来了git checkout后修改被覆盖如果只是覆盖工作区可用git reflog找回提交记录更稳妥的是养成频繁commit习惯想放弃当前工作区改动改了但不想要了未add时用git checkout -- 文件已add可用git restore --staged但要小心确认pull时提示无法合并本地有未提交的改动先git stash暂存改动pull后再git stash pop恢复分支名/提交标题写错已提交但未推送用git commit --amend修改或git branch -m改名push被拒远程有新提交你本地没有先git pull --rebase再重新push注意rebase会改写本地提交哈希误删了分支分支没了但提交还在用git reflog找到分支指向的提交哈希git checkout -b 分支名 提交哈希 找回恢复某个历史文件想拿旧提交里的某个文件git checkout 提交哈希 -- 文件路径会把这个文件恢复到工作区5. 让Git更好用的几个细节习惯前面讲的是“正确用法”这一节我想分享一些让我日常效率提升明显的小习惯算是我个人经验里最愿意推荐的部分。5.1 配置别名少敲一半字Git允许你给命令设置别名。我最常用的是这几个git config --global alias.st status git config --global alias.co checkout git config --global alias.cm commit git config --global alias.br branch git config --global alias.lg log --oneline --graph --all --decorate配完之后git st就是git statusgit lg能直接看到完整的提交图谱哪个分支分叉了、合并了一目了然。我刚配好的时候同事还以为我在用什么高级工具。5.2 提交粒度小步快跑别攒大招我见过很多新手习惯干了一天活才commit一次理由是“还没做完不想提交半成品”。但这样做风险很大而且历史记录等于没有。更好的方式是“小步提交”每完成一个可描述的小阶段就commit一次。比如“调整数据库表结构”一次“完成新增接口的参数校验”一次“修复前端页面的样式错乱”一次。这样每次提交都能独立存在随时可以单独回退或查看不会把一堆改动搅在一起。有人担心半成品提交会不会污染仓库其实只要你只在特性分支上工作半成品提交完全不丢人。合并回主分支之前你完全可以用git rebase -i把零散提交整理成几个逻辑清晰的提交这部分属于进阶操作等你想让历史更优雅的时候再去了解。5.3 用reflog找回“丢失的提交”Git有一个神级功能叫reflog简单说它记录了你在本地仓库上的每一次操作轨迹。哪怕你不小心用git reset把分支回退到了一个旧的提交看起来“新提交丢了”reflog里仍然能查到那个提交的哈希并恢复到它。有一次我做重构reset之后后悔了以为半天的工作白干了。后来查了reflog发现那个提交还在一条git cherry-pick就捞回来了。从那以后我踏实了很多因为只要提交过Git一般不轻易让它消失。注意reflog只在本地有效所以还是那句话经常push到远程才是最保险的双保险。5.4 团队协作的几条约定如果你不是一个人用Git那光是命令熟练还不够几个人之间的协作规范更重要。我这里提几条经过验证比较有效的约定。第一main分支不要直接push通过合并请求或团队里习惯的代码评审机制让其他人review过再合入。第二每个人的提交信息里要说清楚“为什么”而不仅仅是“做了什么”。第三合并主干之前先做rebase或同步远程尽量减少冲突。第四不把编译产物、IDE配置、本地环境相关的文件提交进仓库。第五遇到不确定能不能删的分支不要在本地清理先问一下因为别人可能还在使用。这些约定不复杂但能省掉非常多无谓的沟通成本和返工时间。以上这些内容是我在真实项目里一遍遍使用Git后沉淀下来的经验。工具本身不难真正难的是理解它的设计思路然后把它变成自己习惯的一部分。如果你现在正处在“命令会用但心里没底”的阶段我的建议是找个真实的项目哪怕是自己写的小工具强制自己用Git管理两三个星期。过了那个别扭期你就会发现已经回不去没有Git的写代码方式了。 
长河君 · 2026/10/20 23:28:03 · 阅读 1.2k Git版本控制实战指南：从核心原理到日常操作与避坑
你是不是也有过这样的经历一个项目文件夹里躺着“需求文档_v1_最终版.doc”“需求文档_v2_真最终版.doc”“需求文档_v3_打死不改版.doc”等到第N次改完连你自己都分不清到底哪份是最新的。代码项目比文档更严重。稍微大一点的工程几十个文件互相依赖你根本不可能靠“复制一份文件夹”来管理版本。Git就是解决这个问题的工具而且它几乎成了程序员入行绕不开的第一道门槛。这篇文章不打算按官方文档的目录给你念一遍我想从一个真实使用者的角度把Git到底解决了什么问题、最核心的概念怎么理解、日常怎么用、踩过哪些坑一次性说清楚。不管你是刚接触Git的新手还是已经用了一两年但一直是“命令背下来了原理没搞懂”的状态这篇文章都值得你花二十分钟看完。理解背后的逻辑比死记命令有用得多。1. 为什么必须用Git——先想清楚它到底解决了什么很多人第一次接触Git是被面试题和公司规范逼着学的。但如果不知道它究竟解决了什么问题你学的时候会特别别扭总觉得命令又多又绕。先别急着敲命令我们回到最原始的场景。1.1 在没有版本管理的日子里到底有多痛我见过一些没系统用过版本管理的人他们的真实工作方式是在项目文件夹里手动复制备份比如“project_20240101”“project_backup”“project_new”偶尔还会用U盘拷贝一份带到另一台电脑上接着改。这套做法短期看没什么问题但一旦项目超过一周、改动超过几十次麻烦就来了。第一你不知道某个文件是什么时候改的、为什么改想对比新旧版本只能靠肉眼。第二如果你在“project_backup”上改了半天回头发现改错了想回到“project_20240101”的状态只能手动把文件拷回去中间所有零散的调整全都丢失。第三两个人同时改同一个项目的时候要么互相等要么邮件传来传去一个不小心就把对方的改动覆盖了。Git本质上就是把你“手动复制文件夹、改坏了再手动回退”这套工作流程做得更规范、更自动化、更不容易出错。它记录项目在每一个时间点的完整快照你随时可以回到任意一个历史状态也可以从任意一个历史状态拉出新分支做尝试。1.2 Git与网盘/U盘备份的本质区别有人可能会说我用网盘同步不也能备份吗能但思路完全不一样。网盘备份解决的是“数据不丢失”它保存的是文件的“最新状态”你最多能恢复到之前某个时间点的版本但通常做不到“只恢复某几个文件而不影响其他文件”更做不到“同时维护两条互不干扰的改动线”。Git解决的是“变化可追溯、路径可选择”。每次提交相当于给整个项目拍了一张照片并且记录了这次拍照和上次拍照之间的差异是谁、为什么、在哪、改了什么。你不仅知道自己现在在哪还知道自己怎么走到这里的。而分支这个东西则相当于让你可以在不同的平行世界之间来回穿梭每个世界里的代码状态互不干扰。1.3 一套流程解决四个核心痛点用Git管项目日常收益其实是四个很实在的点。一是回溯。你改崩了、删错了、合并出了问题一条命令回到之前的稳定版本不用拍着大腿后悔。二是并行。不同功能可以在不同分支上开发互不踩踏做完一个合并一个项目始终保持可用状态。三是审计。每一行代码都能追溯到是谁、在哪个提交、为什么加进来的这对代码评审和问题排查帮助巨大。四是容灾。配合远程仓库你的代码不仅存在本地还能推送到服务器或同事的机器上本机硬盘坏了也不至于一切归零。理解了这些问题再看后面的命令你就知道每一步是在干什么了。2. Git核心概念一次讲透仓库、提交、分支Git的命令确实多但真正核心的概念没有几个。把这几个理解透了你会发现在命令行里操作Git基本不需要“背命令”而是“根据你要完成的目标自然知道该用什么命令”。2.1 三个区工作区、暂存区、本地仓库很多新手最困惑的是我已经git add了为什么还要git commit用生活里的事打比方。工作区是你的“桌面”你在这里写代码、改文件直接操作的都是真实内容。暂存区相当于“待发货区”你把想纳入本次打包的东西挑出来放进去可以选择只挑一部分也可以全部放进去。本地仓库则是“仓库货架”只有放上货架的东西才算形成一个正式的历史节点。所以操作顺序是在工作区里改文件然后用git add把改动放进暂存区最后用git commit把暂存区里的内容打包存档到本地仓库。为什么要多一个暂存区因为现实中你不可能每次都把所有改动一并提交有时候这个文件改了一半还没有完成那个文件已经可以提交了。分开放的灵活性可以让你保持提交的历史干净清晰。2.2 提交commit的本质快照而非差异很多人第一次看git log会以为提交保存的是“和上一版的差异”。这个理解不算全错但会阻碍你更深的理解。更准确的模型是每次commitGit把你项目里所有文件的状态完整照了一张相并存成一次快照。它内部为了省空间会复用相同的文件你看上去可能只有几十KB的差异但逻辑上每次提交都代表“此时此刻整个项目长什么样”。理解这一点你就能明白几个现象。为什么Git切换分支那么快因为它不是去把文件“改成另一个样子”而是直接把工作区恢复到那个快照的状态。为什么误删文件还能恢复因为最近一次提交里还存着那个文件的完整版本。为什么说“Git回退”实际上是“创建新的提交”而不是“删除历史”因为历史快照一直在你只是把当前工作区的指针移到了另一个位置。2.3 分支一条几乎零成本的时间线如果只挑一个Git最值得学的特性我会选分支。因为它的设计在实用层面给人带来的自由度其他版本管理工具很难比。你可以把分支理解成“新开了一条平行时间线”。主分支通常叫main或master上放着稳定的代码你在feature分支上做新功能时随便改、随便提交都不会影响主线上其他人的工作。等新功能稳定了再把feature分支合并回去。Git的分支之所以好用是因为它的实现成本极低。真正在底层分支只是指向某个提交的一个“指针”新建分支只是多写一个名字不是把代码复制一份。所以你想开多少个分支就能开多少个想去掉一个分支也只是一条命令的事。相比之下其他一些版本管理系统新建分支往往意味着目录拷贝最终大家都不爱开分支。2.4 几个常被误解的名词HEAD、origin、main说到这儿我顺便把几个高频词解释一下因为很多人虽然天天看到却不一定知道它们在说什么。HEAD是“当前所在位置”的指针它指向你当前正在操作的提交。切换分支本质上是把HEAD换到另一个分支指向的提交上去。origin是远程仓库的默认名字它不指代码托管平台而是指“你本地项目所关联的那个远程地址”的一个代称。main是主分支的默认名字现在新的仓库一般默认叫main老项目叫master本质没什么区别只是改名了。理清这几个词你以后看到git status里出现“Your branch is ahead of origin/main by 2 commits”就不会懵了它说的是你本地现在比远程多两个提交可以准备推上去了。3. 从零到一一套能直接落地的日常流程理论说完了接下来走一遍真实的操作流程。下面每一条命令都是我在日常项目里会用到的不是教学演示那种一长串花哨参数。你跟着做一遍就会形成肌肉记忆。3.1 初始化与第一次提交拿到一个新项目第一步是进入项目目录然后执行git init。这会生成一个.git目录里面保存着你这个仓库的所有历史信息。不要手动去改这个目录里的东西让它自己管自己就行。接着你需要让Git知道你是谁因为每次提交都要记录作者。设置一次全局生效git config --global user.name 你的名字 git config --global user.email 你的邮箱然后做第一次提交git add . git commit -m 初始化项目这里有个细节想提醒你git add .是把所有改动加进暂存区但前提是你的项目里没有不该提交的文件。很多新手第一次就这么干结果把几百MB的依赖包、数据库备份、IDE配置文件全都提交进去了后面要清理非常麻烦。所以第一次提交之前建议先建好.gitignore文件把不需要纳入版本管理的路径排除掉。后面我会专门讲这个文件的坑。3.2 日常开发三连add、commit、push日常开发的核心操作其实就三个命令的组合。改完代码之后你先用git status看一眼当前有哪些改动确认一下是不是符合预期的那些文件。然后git add把这些改动加入暂存区接着git commit -m 描述这次改了什么把改动固化成一条历史记录。如果项目关联了远程仓库比如代码托管平台上的项目最后还需要git push把本地的新提交推上去这样别人才看得到你的改动。这套流程看似简单但我见过不少人在这上面吃亏具体表现为commit太频繁、commit信息随意、push前不看状态。我自己的习惯是每次commit对应一个逻辑完整的小改动比如“修复登录页在手机上不居中的问题”而不是“改了一些东西”。这样以后看git log每一行都像目录一样清楚。3.3 分支开发做新功能别再直接改主线很多人团队的规范是主线分支上的代码永远要保持可运行状态。那么开发一个新功能你就不要直接在main上改了。正确的做法是新建一个分支出来git checkout -b feature/login这条命令的意思是新建一个名为feature/login的分支并立即切换过去。你在这个分支上正常开发随便提交完全不影响main上的稳定代码。等这个功能做完了、自测过了再合并回去。这里有个使用习惯上的建议分支名要能看出目的。feature/login表示“登录功能”bugfix/payment表示“修复支付相关的Bug”不要用 “test”“new” “aaa” 这种名字。因为分支多了之后你自己都不记得当初为什么开这个分支。3.4 合并与冲突处理功能开发完要合并回主分支操作是git checkout main git pull git merge feature/login先把本地main更新到最新再把feature分支合并进来。如果两个分支都改了同一个文件同一段代码就可能出现冲突。冲突出现时Git会在文件里用类似这样的标记把两边内容标出来 HEAD 你当前所在分支的代码 要合并过来分支的代码 feature/login你需要手动决定保留哪一边或者两边都保留然后把标记行删掉保存文件再git add最后git commit。这个过程第一次遇到会觉得有点慌但碰过几次就会发现其实冲突不是坏事它是在强制你“认真核对两边到底改了什么”总比静默覆盖导致以后莫名其妙丢代码强得多。3.5 写提交信息的小习惯提交信息这件事我想单独拿出来说一下因为它的重要性被很多人严重低估了。三个月后你需要找出“当时是谁改了某个接口的参数、为什么要改”唯一能看的就是git log和提交信息。如果提交信息是“update”“modify”这种基本等于没有记录。我常用的提交信息格式是这样fix: 修复登录接口在空密码时返回500的问题 feat: 新增用户注册后的欢迎邮件通知 refactor: 重构文件上传模块抽离公共校验逻辑前面的fix、feat、refactor表示这次提交的类型后面的内容是简洁描述。不要写“fix bug”要说清楚修了什么Bug。写完提交信息后我通常会自觉检查一遍如果发现描述不够具体宁可再amend一次改掉也不要留下垃圾记录。4. 真实项目里踩过的坑问题解决方案实录命令用熟了之后真正的门槛其实在于各种意外情况。这一节我把这些年自己踩过、以及身边同事踩过的比较典型的问题整理出来每个都附带解决方案。4.1 误提交了大文件或敏感信息怎么办这是非常常见的情况。比如你不小心把几十MB的数据库备份文件提交进去了或者把包含密钥的配置文件提交了。这时候如果只是删除文件再提交一次历史记录里仍然留着那个大文件仓库体积还是很大密钥也可能已经泄露。分两类处理。如果是还想保留文件但不让它进版本库执行git rm --cached 文件名这会把它从Git的跟踪列表中移除但本地文件还在。然后把文件名写进.gitignore再提交一次。如果是想彻底从历史里抹掉某个文件就需要用到git filter-repo这类工具重写历史操作复杂度高且如果这个仓库有其他人共用会导致所有人的历史都冲突建议由经验丰富的人操作。如果你发现自己把密钥提交了我可以给你一个很诚实的建议最快的“修复”是立即吊销那组密钥、重新生成新的而不是费很大力气去清理历史。因为只要它已经推到了远程就不能排除已经被别人拉走了。清理历史是为了以后不再把它当成有效凭证而不是为了“当它没发生过”。4.2 提交信息写错了怎么办提交之后发现信息写错了或者想补充一些改动到上一次提交里用git commit --amend这个命令会把最后一次提交替换成一条新的提交可以用来修改提交信息也可以先把遗漏的改动git add了再一起amend进去。但要注意amend会改变提交的哈希值所以只适合改“还没推送”的最后一次提交。如果已经push给团队其他人了就不要再amend了否则会引发同步混乱。4.3 合并冲突处理的正确顺序很多人合并遇到冲突就懵了一通乱改。我建议你养成一个固定的处理流程。第一步先git status看看有哪些文件冲突。第二步逐个打开冲突文件看清和标记之间的内容。第三步确认两边的代码分别是什么意图保留需要的内容。第四步删掉所有标记行保存文件。第五步git add这个文件表示冲突已解决。第六步其他文件也都处理完之后git commit生成一个合并提交。一个很实用的建议是处理冲突时优先用IDE或编辑器自带的合并工具。比如VS Code里会把两边代码和最终结果并列展示点几下按钮就能选择保留哪边比直接在命令行里看标记行舒服多了。如果你用的是专业IDE它们的Git面板基本都有图形化解决冲突的入口效率高很多。4.4 .gitignore的常见误用.gitignore是每个项目都应该有的文件但我发现很多人对它有一个误解以为只要把文件加进.gitignore它就会被Git忽略。事实是.gitignore只对“还没被Git跟踪”的文件生效。如果你已经把某个文件提交过了之后再把它加进.gitignore是完全无效的它依然会被追踪。要先执行git rm --cached解除跟踪再配合.gitignore才能真正忽略它。另一个常见的坑是写得太宽泛。比如写了一个“*.log”结果把启动时需要保留的关键日志文件也忽略了。我的习惯是尽量写具体路径比如“logs/”表示只忽略logs目录而不是把所有后缀匹配的全忽略避免误伤。4.5 常见问题速查表问题具体表现解决方案文件改动找不回来了git checkout后修改被覆盖如果只是覆盖工作区可用git reflog找回提交记录更稳妥的是养成频繁commit习惯想放弃当前工作区改动改了但不想要了未add时用git checkout -- 文件已add可用git restore --staged但要小心确认pull时提示无法合并本地有未提交的改动先git stash暂存改动pull后再git stash pop恢复分支名/提交标题写错已提交但未推送用git commit --amend修改或git branch -m改名push被拒远程有新提交你本地没有先git pull --rebase再重新push注意rebase会改写本地提交哈希误删了分支分支没了但提交还在用git reflog找到分支指向的提交哈希git checkout -b 分支名 提交哈希 找回恢复某个历史文件想拿旧提交里的某个文件git checkout 提交哈希 -- 文件路径会把这个文件恢复到工作区5. 让Git更好用的几个细节习惯前面讲的是“正确用法”这一节我想分享一些让我日常效率提升明显的小习惯算是我个人经验里最愿意推荐的部分。5.1 配置别名少敲一半字Git允许你给命令设置别名。我最常用的是这几个git config --global alias.st status git config --global alias.co checkout git config --global alias.cm commit git config --global alias.br branch git config --global alias.lg log --oneline --graph --all --decorate配完之后git st就是git statusgit lg能直接看到完整的提交图谱哪个分支分叉了、合并了一目了然。我刚配好的时候同事还以为我在用什么高级工具。5.2 提交粒度小步快跑别攒大招我见过很多新手习惯干了一天活才commit一次理由是“还没做完不想提交半成品”。但这样做风险很大而且历史记录等于没有。更好的方式是“小步提交”每完成一个可描述的小阶段就commit一次。比如“调整数据库表结构”一次“完成新增接口的参数校验”一次“修复前端页面的样式错乱”一次。这样每次提交都能独立存在随时可以单独回退或查看不会把一堆改动搅在一起。有人担心半成品提交会不会污染仓库其实只要你只在特性分支上工作半成品提交完全不丢人。合并回主分支之前你完全可以用git rebase -i把零散提交整理成几个逻辑清晰的提交这部分属于进阶操作等你想让历史更优雅的时候再去了解。5.3 用reflog找回“丢失的提交”Git有一个神级功能叫reflog简单说它记录了你在本地仓库上的每一次操作轨迹。哪怕你不小心用git reset把分支回退到了一个旧的提交看起来“新提交丢了”reflog里仍然能查到那个提交的哈希并恢复到它。有一次我做重构reset之后后悔了以为半天的工作白干了。后来查了reflog发现那个提交还在一条git cherry-pick就捞回来了。从那以后我踏实了很多因为只要提交过Git一般不轻易让它消失。注意reflog只在本地有效所以还是那句话经常push到远程才是最保险的双保险。5.4 团队协作的几条约定如果你不是一个人用Git那光是命令熟练还不够几个人之间的协作规范更重要。我这里提几条经过验证比较有效的约定。第一main分支不要直接push通过合并请求或团队里习惯的代码评审机制让其他人review过再合入。第二每个人的提交信息里要说清楚“为什么”而不仅仅是“做了什么”。第三合并主干之前先做rebase或同步远程尽量减少冲突。第四不把编译产物、IDE配置、本地环境相关的文件提交进仓库。第五遇到不确定能不能删的分支不要在本地清理先问一下因为别人可能还在使用。这些约定不复杂但能省掉非常多无谓的沟通成本和返工时间。以上这些内容是我在真实项目里一遍遍使用Git后沉淀下来的经验。工具本身不难真正难的是理解它的设计思路然后把它变成自己习惯的一部分。如果你现在正处在“命令会用但心里没底”的阶段我的建议是找个真实的项目哪怕是自己写的小工具强制自己用Git管理两三个星期。过了那个别扭期你就会发现已经回不去没有Git的写代码方式了。