43_Git版本控制基础

Git版本控制基础

文章目录

Git版本控制基础
- 前言
- 一、Git概述与安装
- - [1.1 Git是什么](#1.1 Git是什么)
  - [1.2 Git工作流程](#1.2 Git工作流程)
  - [1.3 安装Git](#1.3 安装Git)
- 二、Git基础操作
- - [2.1 初始化仓库](#2.1 初始化仓库)
  - [2.2 查看状态和提交](#2.2 查看状态和提交)
  - [2.3 撤销与回滚](#2.3 撤销与回滚)
  - [2.4 差异对比](#2.4 差异对比)
- 三、分支管理
- - [3.1 分支基本操作](#3.1 分支基本操作)
  - [3.2 合并分支](#3.2 合并分支)
  - [3.3 rebase变基](#3.3 rebase变基)
  - [3.4 常用分支策略](#3.4 常用分支策略)
- 四、远程仓库
- - [4.1 关联远程仓库](#4.1 关联远程仓库)
  - [4.2 标签管理](#4.2 标签管理)
- 五、.gitignore文件
- 六、Git与IDEA集成
- - [6.1 克隆项目](#6.1 克隆项目)
  - [6.2 提交代码](#6.2 提交代码)
  - [6.3 分支操作](#6.3 分支操作)
  - [6.4 历史查看](#6.4 历史查看)
  - [6.5 冲突解决](#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 下载安装包，安装过程中保持默认选项即可。安装完成后验证：

bash 复制代码

git --version

配置用户信息（必做）：

bash 复制代码

git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"

配置user.name和user.email非常重要。每一个commit都会记录这些信息作为提交者身份。如果没有配置，Git会使用操作系统的用户名和主机名，导致commit记录中出现类似"Administrator@DESKTOP-XXX"这种无意义的身份标识。在团队协作中，这会给代码审查和问题追溯带来麻烦。建议使用真实姓名和公司邮箱。

二、Git基础操作

2.1 初始化仓库

bash 复制代码

# 在当前目录创建新仓库
git init

# 克隆远程仓库到本地
git clone https://github.com/user/repo.git

2.2 查看状态和提交

bash 复制代码

# 查看工作区状态
git status

# 添加文件到暂存区
git add filename.txt           # 添加指定文件
git add .                      # 添加所有变更

# 提交到版本库
git commit -m "提交信息"

# 查看提交历史
git log
git log --oneline              # 简洁模式
git log --graph --oneline     # 图形化分支

git commit -m 写什么 ：提交信息是给未来的自己和其他开发者看的。一个好的commit message格式建议：类型(范围): 简短描述，如feat(user): 添加短信验证码登录功能、fix(order): 修复金额精度丢失问题。常见的类型前缀：feat（新功能）、fix（修复bug）、refactor（重构）、docs（文档）、test（测试）。面试和实际项目中都推荐遵循这个规范。

2.3 撤销与回滚

bash 复制代码

# 撤销工作区修改（未add）
git checkout -- filename.txt

# 撤销暂存区（已add未commit）
git reset HEAD filename.txt

# 回退版本
git reset --hard HEAD^         # 回退一个版本
git reset --hard commit_id     # 回退到指定版本

# 查看所有操作记录（含被回退的commit）
git reflog

reset的三种模式：

--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 差异对比

bash 复制代码

# 查看工作区与暂存区的差异
git diff

# 查看暂存区与最新commit的差异
git diff --cached

# 查看工作区与最新commit的差异
git diff HEAD

三、分支管理

分支是Git的精髓所在。通过分支，你可以在不影响主线代码的情况下开发新功能、修复Bug。

为什么分支很重要？ 想象一下没有分支的情况：所有人在同一份代码上开发，一个人改了用户模块没测完，另一个人改了订单模块也要上线------代码揉在一起，谁也不敢动。分支的出现让"并行开发"成为可能：你从主分支拉出自己的feature分支，改完了测试通过再合并回去，期间主分支随时可以发布，互不影响。Git的分支创建和切换几乎是瞬时的（因为它只是一个指针），这也是Git相比SVN的巨大优势。

3.1 分支基本操作

bash 复制代码

# 查看所有分支
git branch

# 创建分支
git branch feature-login

# 切换分支
git checkout feature-login

# 创建并切换（二合一）
git checkout -b feature-register

# 删除分支
git branch -d feature-login

3.2 合并分支

bash 复制代码

# 切换到目标分支
git checkout main

# 合并指定分支到当前分支
git merge feature-login

合并时可能产生冲突，需要手动解决：

复制代码

<<<<<<< HEAD
当前分支的内容
=======
被合并分支的内容
>>>>>>> feature-login

手动修改后，执行 git add 和 git commit 完成合并。

3.3 rebase变基

bash 复制代码

# 将当前分支变基到指定分支
git rebase main

merge vs rebase：merge会产生合并提交记录，保留分支历史；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 关联远程仓库

bash 复制代码

# 添加远程仓库（origin是默认名称）
git remote add origin https://github.com/user/repo.git

# 查看远程仓库信息
git remote -v

# 推送代码
git push origin main

# 拉取并合并
git pull origin main

# 仅拉取不合并
git fetch origin

pull vs fetch的区别 ：git pull = git fetch + git merge。fetch只是把远程的更新拉到本地，不会自动合并到你的工作分支，适合先看看别人改了什么再决定是否合并。pull则直接合并，如果远程和本地有冲突，merge会让你先解决。建议养成先fetch再merge的习惯（或者pull时使用--rebase），减少不必要的自动合并。

4.2 标签管理

bash 复制代码

# 创建标签
git tag v1.0.0

# 创建带注释的标签
git tag -a v1.0.0 -m "版本1.0.0发布"

# 推送标签到远程
git push origin v1.0.0
git push 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 提交代码

快捷键 Ctrl+K 打开提交窗口：

勾选要提交的文件
填写提交信息
点击Commit（仅提交本地）或 Commit and Push（推送到远程）

6.3 分支操作

点击IDEA右下角的分支名称，弹出分支菜单，可以进行：

创建新分支
切换分支
合并分支
删除分支

6.4 历史查看

View → Tool Windows → Git 或快捷键 Alt+9，可以查看提交历史、分支图、文件变更等信息。

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，可以大幅提高开发效率。

面试高频考点总结：1）Git的三大工作区域和流程；2）merge和rebase的区别及使用场景；3）reset的三种模式（--soft/--mixed/--hard）；4）Git 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的核心基石