Git版本控制基础文章目录Git版本控制基础前言一、Git概述与安装1.1 Git是什么1.2 Git工作流程1.3 安装Git二、Git基础操作2.1 初始化仓库2.2 查看状态和提交2.3 撤销与回滚2.4 差异对比三、分支管理3.1 分支基本操作3.2 合并分支3.3 rebase变基3.4 常用分支策略四、远程仓库4.1 关联远程仓库4.2 标签管理五、.gitignore文件六、Git与IDEA集成6.1 克隆项目6.2 提交代码6.3 分支操作6.4 历史查看6.5 冲突解决七、Git最佳实践总结✅ 亮点总结适用场景扩展方向前言在软件开发中版本控制是团队协作的基石。无论是多人协作还是个人项目Git都能帮助你追踪代码变更、回滚错误修改、并行开发新功能。作为目前最流行的分布式版本控制系统Git是每个程序员的必修课。Git为什么重要没有版本控制的日子是怎样的代码改坏了没办法回退、多人同时编辑同一个文件互相覆盖、不知道某段代码是谁在什么时候写的。Git不仅解决了这些问题还通过分支管理实现了真正的并行开发——一个团队可以同时在5个不同的feature分支上工作互不干扰最终通过merge整合。在面试中Git的分支策略、merge和rebase的区别、冲突解决等是高频考点。本文将从零开始带你掌握Git的常用命令、分支管理以及与IDEA的完美集成。一、Git概述与安装1.1 Git是什么Git是由Linus Torvalds于2005年创建的分布式版本控制系统。与SVN等集中式版本控制工具不同Git每个开发者本地都有一个完整的仓库副本即使没有网络也能提交和查看历史记录。集中式 vs 分布式SVN这类集中式工具所有代码历史都保存在中央服务器上离了服务器你什么都做不了。Git的每个本地仓库都是完整的——你可以在飞机上commit、查看所有历史记录、创建分支等有网络了再push到远程。这种设计让Git在灵活性、速度、可靠性上都远超集中式工具。面试中问到Git和SVN的区别核心就是分布式 vs 集中式。1.2 Git工作流程Git将工作区域分为三部分工作区Working Directory你正在编辑的文件暂存区Staging Area通过git add暂存的文件版本库Repository通过git commit永久保存的历史版本工作区 --git add-- 暂存区 --git commit-- 版本库三区模型的意义为什么Git要有暂存区这其实是一个非常精妙的设计。暂存区让你可以精确控制每次commit包含哪些改动。比如你改了5个文件但只想提交其中2个——就可以只add那2个文件。如果没有暂存区每次提交要么全提交要么不提交灵活性大打折扣。这也是Git相比SVN的一个重要区别。1.3 安装Git从https://git-scm.com下载安装包安装过程中保持默认选项即可。安装完成后验证git--version配置用户信息必做gitconfig--globaluser.nameYour Namegitconfig--globaluser.emailyour.emailexample.com配置user.name和user.email非常重要。每一个commit都会记录这些信息作为提交者身份。如果没有配置Git会使用操作系统的用户名和主机名导致commit记录中出现类似AdministratorDESKTOP-XXX这种无意义的身份标识。在团队协作中这会给代码审查和问题追溯带来麻烦。建议使用真实姓名和公司邮箱。二、Git基础操作2.1 初始化仓库# 在当前目录创建新仓库gitinit# 克隆远程仓库到本地gitclone https://github.com/user/repo.git2.2 查看状态和提交# 查看工作区状态gitstatus# 添加文件到暂存区gitaddfilename.txt# 添加指定文件gitadd.# 添加所有变更# 提交到版本库gitcommit-m提交信息# 查看提交历史gitloggitlog--oneline# 简洁模式gitlog--graph--oneline# 图形化分支git commit -m 写什么提交信息是给未来的自己和其他开发者看的。一个好的commit message格式建议类型(范围): 简短描述如feat(user): 添加短信验证码登录功能、fix(order): 修复金额精度丢失问题。常见的类型前缀feat新功能、fix修复bug、refactor重构、docs文档、test测试。面试和实际项目中都推荐遵循这个规范。2.3 撤销与回滚# 撤销工作区修改未addgitcheckout -- filename.txt# 撤销暂存区已add未commitgitreset HEAD filename.txt# 回退版本gitreset--hardHEAD^# 回退一个版本gitreset--hardcommit_id# 回退到指定版本# 查看所有操作记录含被回退的commitgitreflogreset的三种模式--soft仅移动HEAD指针暂存区和工作区都不变。常用于合并多个commit。--mixed默认移动HEAD指针重置暂存区工作区不变。相当于撤销add和commit文件内容还在。--hard移动HEAD指针重置暂存区和工作区。你的改动会彻底丢失使用前一定要确认。如果reset --hard后用git log看不到被删除的commit了可以使用git reflog找到被删除commit的ID然后用git reset --hard commit_id恢复。这是Git的一个后悔药机制——只要没有被GC清理操作记录都能找回。2.4 差异对比# 查看工作区与暂存区的差异gitdiff# 查看暂存区与最新commit的差异gitdiff--cached# 查看工作区与最新commit的差异gitdiffHEAD三、分支管理分支是Git的精髓所在。通过分支你可以在不影响主线代码的情况下开发新功能、修复Bug。为什么分支很重要想象一下没有分支的情况所有人在同一份代码上开发一个人改了用户模块没测完另一个人改了订单模块也要上线——代码揉在一起谁也不敢动。分支的出现让并行开发成为可能你从主分支拉出自己的feature分支改完了测试通过再合并回去期间主分支随时可以发布互不影响。Git的分支创建和切换几乎是瞬时的因为它只是一个指针这也是Git相比SVN的巨大优势。3.1 分支基本操作# 查看所有分支gitbranch# 创建分支gitbranch feature-login# 切换分支gitcheckout feature-login# 创建并切换二合一gitcheckout-bfeature-register# 删除分支gitbranch-dfeature-login3.2 合并分支# 切换到目标分支gitcheckout main# 合并指定分支到当前分支gitmerge feature-login合并时可能产生冲突需要手动解决 HEAD 当前分支的内容 被合并分支的内容 feature-login手动修改后执行git add和git commit完成合并。3.3 rebase变基# 将当前分支变基到指定分支gitrebase mainmerge vs rebasemerge会产生合并提交记录保留分支历史rebase会将提交线变成一条直线历史更清晰但丢失了分支信息。团队协作中推荐使用merge个人分支可以使用rebase保持整洁。什么时候用merge什么时候用rebase这是一个面试中的经典问题。简单来说merge保留完整历史适合公共分支如main、develop让每个人都能看到分支的完整轨迹rebase让历史线性化适合个人分支整理提交记录。关键原则永远不要对已经push到远程的公共分支执行rebase因为rebase会改写提交历史导致其他团队成员基于旧历史的代码出现严重冲突。3.4 常用分支策略实际项目中推荐使用以下分支模型分支用途main/master生产环境代码只接收合并请求develop开发主线feature/xxx功能开发分支hotfix/xxx紧急修复分支release/xxx发布准备分支Git Flow工作流这是最经典的分支模型。日常开发在develop分支上进行每开发一个新功能就从develop拉出feature分支开发完成后合并回develop。当develop积累到可以发布时拉出release分支做最后的测试和bug修复release完成后合并到main和develop。线上出现紧急bug时从main拉出hotfix分支修复后合并回main和develop。这个模型虽然看起来有点复杂但确实能很好地应对企业级项目的版本管理需求。四、远程仓库4.1 关联远程仓库# 添加远程仓库origin是默认名称gitremoteaddorigin https://github.com/user/repo.git# 查看远程仓库信息gitremote-v# 推送代码gitpush origin main# 拉取并合并gitpull origin main# 仅拉取不合并gitfetch originpull vs fetch的区别git pullgit fetchgit merge。fetch只是把远程的更新拉到本地不会自动合并到你的工作分支适合先看看别人改了什么再决定是否合并。pull则直接合并如果远程和本地有冲突merge会让你先解决。建议养成先fetch再merge的习惯或者pull时使用–rebase减少不必要的自动合并。4.2 标签管理# 创建标签gittag v1.0.0# 创建带注释的标签gittag-av1.0.0-m版本1.0.0发布# 推送标签到远程gitpush origin v1.0.0gitpush origin--tags# 推送所有标签标签的使用场景每当一个版本正式发布时都应该打一个tag来标记。例如v1.0.0、v2.3.1等。配合CI/CD工具可以做到每当推送一个tag就自动触发部署流程。与分支不同tag是只读的、不能在上面提交代码。在排查问题时某个版本的tag能让你快速定位到对应版本的代码。注意push代码不会自动push tag需要显式git push origin --tags。五、.gitignore文件有些文件不应该提交到Git仓库编译产物、日志、本地配置等通过.gitignore文件指定# Maven target/ # IDE .idea/ *.iml # 日志 *.log # 系统文件 .DS_Store Thumbs.db.gitignore的最佳实践一个项目应该从一开始就配置好.gitignore。特别注意以下几点不要把敏感信息提交上去数据库密码、API密钥、私有证书等即使写在配置文件中也应该用.gitignore忽略使用模板文件代替不要把编译产物提交上去target/、build/、*.class等这些是环境相关的不同机器上应该重新编译不要把IDE的个性化配置提交上去.idea/、*.iml等每个人使用的IDE和配置不同提交这些容易引起冲突不要提交node_modules这个文件夹动辄几百MB提交和拉取都非常慢应该通过package.json npm install来恢复六、Git与IDEA集成IDEA内置了强大的Git集成功能几乎不需要命令行就能完成日常操作。6.1 克隆项目File → New → Project from Version Control输入仓库URL即可克隆。6.2 提交代码快捷键CtrlK打开提交窗口勾选要提交的文件填写提交信息点击Commit仅提交本地或 Commit and Push推送到远程6.3 分支操作点击IDEA右下角的分支名称弹出分支菜单可以进行创建新分支切换分支合并分支删除分支6.4 历史查看View → Tool Windows → Git或快捷键Alt9可以查看提交历史、分支图、文件变更等信息。6.5 冲突解决当合并产生冲突时IDEA会弹出冲突解决窗口提供三种合并方式Accept Yours使用当前分支的内容Accept Theirs使用合并分支的内容Merge手动合并三栏对比直观操作七、Git最佳实践提交信息规范遵循type(scope): description格式如feat(user): 添加登录功能、fix(order): 修复金额计算错误小步提交每个提交只做一件事便于回溯和代码审查拉取再推送push前先pull减少冲突不要提交敏感信息密码、密钥等应使用环境变量或配置文件忽略定期清理分支合并后的功能分支及时删除总结本文系统介绍了Git的基础操作、分支管理、远程协作以及与IDEA的集成使用。Git虽然命令众多但日常工作中80%的时间只需要用到add、commit、push、pull、branch、checkout这几个命令。建议在IDEA中配合使用Git可以大幅提高开发效率。面试高频考点总结1Git的三大工作区域和流程2merge和rebase的区别及使用场景3reset的三种模式–soft/–mixed/–hard4Git Flow分支策略5如何解决合并冲突掌握这些Git相关的面试问题基本都能应对。✅ 亮点总结三区模型工作区→暂存区→版本库清晰理解Git的数据流转分支管理实现并行开发feature/hotfix/release分支策略规范团队协作merge vs rebase团队协作推荐merge保留历史个人分支推荐rebase保持整洁.gitignore过滤编译产物、IDE配置、日志等非源码文件IDEA集成可视化提交、冲突解决、历史查看大幅降低Git使用门槛适用场景团队协作开发通过feature分支开发新功能merge到develop后进行集成测试线上Bug修复从main拉hotfix分支修复后合并到main和develop版本发布通过tag标记每个发布版本配合git reflog实现任意版本回退扩展方向学习Git Flow / GitHub Flow工作流规范建立团队的分支管理标准掌握git rebase -i交互式变基合并和整理提交记录推荐阅读下一篇文章Spring框架IOC容器理解Spring的核心基石
43_Git版本控制基础
发布时间：2026/6/19 12:03:36
Git版本控制基础文章目录Git版本控制基础前言一、Git概述与安装1.1 Git是什么1.2 Git工作流程1.3 安装Git二、Git基础操作2.1 初始化仓库2.2 查看状态和提交2.3 撤销与回滚2.4 差异对比三、分支管理3.1 分支基本操作3.2 合并分支3.3 rebase变基3.4 常用分支策略四、远程仓库4.1 关联远程仓库4.2 标签管理五、.gitignore文件六、Git与IDEA集成6.1 克隆项目6.2 提交代码6.3 分支操作6.4 历史查看6.5 冲突解决七、Git最佳实践总结✅ 亮点总结适用场景扩展方向前言在软件开发中版本控制是团队协作的基石。无论是多人协作还是个人项目Git都能帮助你追踪代码变更、回滚错误修改、并行开发新功能。作为目前最流行的分布式版本控制系统Git是每个程序员的必修课。Git为什么重要没有版本控制的日子是怎样的代码改坏了没办法回退、多人同时编辑同一个文件互相覆盖、不知道某段代码是谁在什么时候写的。Git不仅解决了这些问题还通过分支管理实现了真正的并行开发——一个团队可以同时在5个不同的feature分支上工作互不干扰最终通过merge整合。在面试中Git的分支策略、merge和rebase的区别、冲突解决等是高频考点。本文将从零开始带你掌握Git的常用命令、分支管理以及与IDEA的完美集成。一、Git概述与安装1.1 Git是什么Git是由Linus Torvalds于2005年创建的分布式版本控制系统。与SVN等集中式版本控制工具不同Git每个开发者本地都有一个完整的仓库副本即使没有网络也能提交和查看历史记录。集中式 vs 分布式SVN这类集中式工具所有代码历史都保存在中央服务器上离了服务器你什么都做不了。Git的每个本地仓库都是完整的——你可以在飞机上commit、查看所有历史记录、创建分支等有网络了再push到远程。这种设计让Git在灵活性、速度、可靠性上都远超集中式工具。面试中问到Git和SVN的区别核心就是分布式 vs 集中式。1.2 Git工作流程Git将工作区域分为三部分工作区Working Directory你正在编辑的文件暂存区Staging Area通过git add暂存的文件版本库Repository通过git commit永久保存的历史版本工作区 --git add-- 暂存区 --git commit-- 版本库三区模型的意义为什么Git要有暂存区这其实是一个非常精妙的设计。暂存区让你可以精确控制每次commit包含哪些改动。比如你改了5个文件但只想提交其中2个——就可以只add那2个文件。如果没有暂存区每次提交要么全提交要么不提交灵活性大打折扣。这也是Git相比SVN的一个重要区别。1.3 安装Git从https://git-scm.com下载安装包安装过程中保持默认选项即可。安装完成后验证git--version配置用户信息必做gitconfig--globaluser.nameYour Namegitconfig--globaluser.emailyour.emailexample.com配置user.name和user.email非常重要。每一个commit都会记录这些信息作为提交者身份。如果没有配置Git会使用操作系统的用户名和主机名导致commit记录中出现类似AdministratorDESKTOP-XXX这种无意义的身份标识。在团队协作中这会给代码审查和问题追溯带来麻烦。建议使用真实姓名和公司邮箱。二、Git基础操作2.1 初始化仓库# 在当前目录创建新仓库gitinit# 克隆远程仓库到本地gitclone https://github.com/user/repo.git2.2 查看状态和提交# 查看工作区状态gitstatus# 添加文件到暂存区gitaddfilename.txt# 添加指定文件gitadd.# 添加所有变更# 提交到版本库gitcommit-m提交信息# 查看提交历史gitloggitlog--oneline# 简洁模式gitlog--graph--oneline# 图形化分支git commit -m 写什么提交信息是给未来的自己和其他开发者看的。一个好的commit message格式建议类型(范围): 简短描述如feat(user): 添加短信验证码登录功能、fix(order): 修复金额精度丢失问题。常见的类型前缀feat新功能、fix修复bug、refactor重构、docs文档、test测试。面试和实际项目中都推荐遵循这个规范。2.3 撤销与回滚# 撤销工作区修改未addgitcheckout -- filename.txt# 撤销暂存区已add未commitgitreset HEAD filename.txt# 回退版本gitreset--hardHEAD^# 回退一个版本gitreset--hardcommit_id# 回退到指定版本# 查看所有操作记录含被回退的commitgitreflogreset的三种模式--soft仅移动HEAD指针暂存区和工作区都不变。常用于合并多个commit。--mixed默认移动HEAD指针重置暂存区工作区不变。相当于撤销add和commit文件内容还在。--hard移动HEAD指针重置暂存区和工作区。你的改动会彻底丢失使用前一定要确认。如果reset --hard后用git log看不到被删除的commit了可以使用git reflog找到被删除commit的ID然后用git reset --hard commit_id恢复。这是Git的一个后悔药机制——只要没有被GC清理操作记录都能找回。2.4 差异对比# 查看工作区与暂存区的差异gitdiff# 查看暂存区与最新commit的差异gitdiff--cached# 查看工作区与最新commit的差异gitdiffHEAD三、分支管理分支是Git的精髓所在。通过分支你可以在不影响主线代码的情况下开发新功能、修复Bug。为什么分支很重要想象一下没有分支的情况所有人在同一份代码上开发一个人改了用户模块没测完另一个人改了订单模块也要上线——代码揉在一起谁也不敢动。分支的出现让并行开发成为可能你从主分支拉出自己的feature分支改完了测试通过再合并回去期间主分支随时可以发布互不影响。Git的分支创建和切换几乎是瞬时的因为它只是一个指针这也是Git相比SVN的巨大优势。3.1 分支基本操作# 查看所有分支gitbranch# 创建分支gitbranch feature-login# 切换分支gitcheckout feature-login# 创建并切换二合一gitcheckout-bfeature-register# 删除分支gitbranch-dfeature-login3.2 合并分支# 切换到目标分支gitcheckout main# 合并指定分支到当前分支gitmerge feature-login合并时可能产生冲突需要手动解决 HEAD 当前分支的内容 被合并分支的内容 feature-login手动修改后执行git add和git commit完成合并。3.3 rebase变基# 将当前分支变基到指定分支gitrebase mainmerge vs rebasemerge会产生合并提交记录保留分支历史rebase会将提交线变成一条直线历史更清晰但丢失了分支信息。团队协作中推荐使用merge个人分支可以使用rebase保持整洁。什么时候用merge什么时候用rebase这是一个面试中的经典问题。简单来说merge保留完整历史适合公共分支如main、develop让每个人都能看到分支的完整轨迹rebase让历史线性化适合个人分支整理提交记录。关键原则永远不要对已经push到远程的公共分支执行rebase因为rebase会改写提交历史导致其他团队成员基于旧历史的代码出现严重冲突。3.4 常用分支策略实际项目中推荐使用以下分支模型分支用途main/master生产环境代码只接收合并请求develop开发主线feature/xxx功能开发分支hotfix/xxx紧急修复分支release/xxx发布准备分支Git Flow工作流这是最经典的分支模型。日常开发在develop分支上进行每开发一个新功能就从develop拉出feature分支开发完成后合并回develop。当develop积累到可以发布时拉出release分支做最后的测试和bug修复release完成后合并到main和develop。线上出现紧急bug时从main拉出hotfix分支修复后合并回main和develop。这个模型虽然看起来有点复杂但确实能很好地应对企业级项目的版本管理需求。四、远程仓库4.1 关联远程仓库# 添加远程仓库origin是默认名称gitremoteaddorigin https://github.com/user/repo.git# 查看远程仓库信息gitremote-v# 推送代码gitpush origin main# 拉取并合并gitpull origin main# 仅拉取不合并gitfetch originpull vs fetch的区别git pullgit fetchgit merge。fetch只是把远程的更新拉到本地不会自动合并到你的工作分支适合先看看别人改了什么再决定是否合并。pull则直接合并如果远程和本地有冲突merge会让你先解决。建议养成先fetch再merge的习惯或者pull时使用–rebase减少不必要的自动合并。4.2 标签管理# 创建标签gittag v1.0.0# 创建带注释的标签gittag-av1.0.0-m版本1.0.0发布# 推送标签到远程gitpush origin v1.0.0gitpush origin--tags# 推送所有标签标签的使用场景每当一个版本正式发布时都应该打一个tag来标记。例如v1.0.0、v2.3.1等。配合CI/CD工具可以做到每当推送一个tag就自动触发部署流程。与分支不同tag是只读的、不能在上面提交代码。在排查问题时某个版本的tag能让你快速定位到对应版本的代码。注意push代码不会自动push tag需要显式git push origin --tags。五、.gitignore文件有些文件不应该提交到Git仓库编译产物、日志、本地配置等通过.gitignore文件指定# Maven target/ # IDE .idea/ *.iml # 日志 *.log # 系统文件 .DS_Store Thumbs.db.gitignore的最佳实践一个项目应该从一开始就配置好.gitignore。特别注意以下几点不要把敏感信息提交上去数据库密码、API密钥、私有证书等即使写在配置文件中也应该用.gitignore忽略使用模板文件代替不要把编译产物提交上去target/、build/、*.class等这些是环境相关的不同机器上应该重新编译不要把IDE的个性化配置提交上去.idea/、*.iml等每个人使用的IDE和配置不同提交这些容易引起冲突不要提交node_modules这个文件夹动辄几百MB提交和拉取都非常慢应该通过package.json npm install来恢复六、Git与IDEA集成IDEA内置了强大的Git集成功能几乎不需要命令行就能完成日常操作。6.1 克隆项目File → New → Project from Version Control输入仓库URL即可克隆。6.2 提交代码快捷键CtrlK打开提交窗口勾选要提交的文件填写提交信息点击Commit仅提交本地或 Commit and Push推送到远程6.3 分支操作点击IDEA右下角的分支名称弹出分支菜单可以进行创建新分支切换分支合并分支删除分支6.4 历史查看View → Tool Windows → Git或快捷键Alt9可以查看提交历史、分支图、文件变更等信息。6.5 冲突解决当合并产生冲突时IDEA会弹出冲突解决窗口提供三种合并方式Accept Yours使用当前分支的内容Accept Theirs使用合并分支的内容Merge手动合并三栏对比直观操作七、Git最佳实践提交信息规范遵循type(scope): description格式如feat(user): 添加登录功能、fix(order): 修复金额计算错误小步提交每个提交只做一件事便于回溯和代码审查拉取再推送push前先pull减少冲突不要提交敏感信息密码、密钥等应使用环境变量或配置文件忽略定期清理分支合并后的功能分支及时删除总结本文系统介绍了Git的基础操作、分支管理、远程协作以及与IDEA的集成使用。Git虽然命令众多但日常工作中80%的时间只需要用到add、commit、push、pull、branch、checkout这几个命令。建议在IDEA中配合使用Git可以大幅提高开发效率。面试高频考点总结1Git的三大工作区域和流程2merge和rebase的区别及使用场景3reset的三种模式–soft/–mixed/–hard4Git Flow分支策略5如何解决合并冲突掌握这些Git相关的面试问题基本都能应对。✅ 亮点总结三区模型工作区→暂存区→版本库清晰理解Git的数据流转分支管理实现并行开发feature/hotfix/release分支策略规范团队协作merge vs rebase团队协作推荐merge保留历史个人分支推荐rebase保持整洁.gitignore过滤编译产物、IDE配置、日志等非源码文件IDEA集成可视化提交、冲突解决、历史查看大幅降低Git使用门槛适用场景团队协作开发通过feature分支开发新功能merge到develop后进行集成测试线上Bug修复从main拉hotfix分支修复后合并到main和develop版本发布通过tag标记每个发布版本配合git reflog实现任意版本回退扩展方向学习Git Flow / GitHub Flow工作流规范建立团队的分支管理标准掌握git rebase -i交互式变基合并和整理提交记录推荐阅读下一篇文章Spring框架IOC容器理解Spring的核心基石
