当前位置：首页 > news >正文

Git常用命令和分支管理

news 2025/9/20 9:52:17

在现代软件开发中，版本控制是保障代码安全、提升团队协作效率的核心工具，而 Git 作为当前最主流的分布式版本控制系统，更是开发者必须掌握的技能。本文将从 Git 初始化配置入手，逐步讲解本地仓库操作、常用命令优化，以及企业级分支管理策略，帮助新手快速上手并规范使用 Git。

一、Git 初始化配置

刚安装完 Git 后，需先完成基础配置，确保能正常标识开发者身份、简化常用操作，避免后续使用中出现问题。

1.1 设置用户签名

用户签名的核心作用是区分不同开发者的提交记录，每一次版本提交都会附带签名信息，方便团队追溯责任。注意：此处签名与 GitHub、GitLab 等代码托管平台的登录账号无任何关联，仅用于本地 Git 仓库标识。

全局配置（所有本地仓库生效，推荐优先配置）：

git config --global user.name "你的用户名"  # 示例：git config --global user.name "LiSi"
git config --global user.email "你的邮箱"   # 示例：git config --global user.email "lisi@example.com"

局部配置（仅当前仓库生效，优先级高于全局）：
需先进入目标仓库目录，再执行命令（去掉 --global 参数）：
```
git config user.name "项目专属用户名"
git config user.email "项目专属邮箱"
```

关键提醒：Git 首次安装后必须配置用户签名，否则无法提交代码，这是 Git 强制要求的身份验证环节。

1.2 配置命令别名

Git 中部分高频命令（如查看提交日志）需携带多个参数，每次输入繁琐。通过配置别名，可将复杂命令简化为自定义短句，大幅提升操作效率。

配置步骤：

创建配置文件：打开 Git Bash，执行以下命令在用户目录生成 .bashrc 配置文件（Windows 系统直接创建点号开头文件可能受限，需通过 Git Bash 操作）：
```
touch ~/.bashrc
```

添加别名配置：用文本编辑器打开 .bashrc，添加常用命令别名（可根据需求扩展）：

# 查看 Git 提交日志：显示所有分支、单行精简格式、图形化展示、缩短 commit ID
alias git-log='git log --pretty=oneline --all --graph --abbrev-commit'
# 查看当前目录所有文件（含隐藏文件）及详细信息（权限、大小、修改时间等）
alias ll='ls -al'

使配置生效：执行以下命令加载配置，无需重启 Git Bash：
```
source ~/.bashrc
```

配置完成后，输入 git-log 即可查看简洁的图形化日志，输入 ll 即可快速查看目录文件详情，无需重复输入长参数。

1.3 解决 Git Bash 乱码问题

Windows 系统中，Git Bash 可能出现中文显示乱码（如中文文件名、日志中文乱码），通过以下两步配置即可解决：

关闭路径中文转义：打开 Git Bash，执行全局配置命令：
```
git config --global core.quotepath false
```
设置编码格式：找到 Git 安装目录下的 bash.bashrc 文件（路径通常为 Git安装目录/etc/bash.bashrc），在文件末尾添加以下两行：
```
export LANG="zh_CN.UTF-8"
export LC_ALL="zh_CN.UTF-8"
```

保存文件后重启 Git Bash，中文即可正常显示。

二、本地仓库操作

本地仓库是 Git 版本管理的基础，所有代码的修改、提交、回退等操作均围绕本地仓库展开。以下是从仓库创建到版本管理的完整流程。

2.1 获取本地仓库

要使用 Git 管理代码，需先创建本地仓库（本质是包含 Git 核心配置文件的目录）。

操作步骤：

在电脑任意位置创建一个空目录（如 my-git-project），作为仓库根目录；
进入该目录，右键打开 Git Bash；
执行初始化命令，创建 Git 本地仓库：
```
git init
```
初始化成功后，目录下会生成隐藏的 .git 文件夹（包含仓库配置、版本记录等核心文件，切勿手动修改或删除）。

2.2 查看本地仓库状态

git status 是 Git 中使用频率最高的命令之一，可实时查看仓库中文件的状态（未跟踪、已修改、已暂存等），帮助开发者掌握代码变更情况。

基本语法：
```
git status
```
常见状态解读：
- Untracked files：未跟踪文件（新创建的文件，Git 尚未管理）；
- modified：已修改文件（已跟踪文件内容变更，但未暂存）；
- Changes to be committed：已暂存文件（修改后添加到暂存区，等待提交到本地库）；
- nothing to commit, working tree clean：工作区干净（无未跟踪、未暂存的文件）。

2.3 文件暂存与提交

Git 通过 “工作区→暂存区→本地库” 的流程管理版本，只有将文件提交到本地库，才算完成一次版本固化。

1. 工作区 → 暂存区：`git add`

将未跟踪文件或已修改文件添加到暂存区，让 Git 开始追踪这些变更。

基本语法：

# 添加单个文件
git add 文件名
# 添加当前目录所有文件（含子目录）
git add .
# 添加指定目录下所有文件
git add 目录名/

示例：

git add main.js          # 添加 main.js 文件到暂存区
git add src/styles/      # 添加 src/styles 目录下所有文件到暂存区
git add .                # 添加当前目录所有文件到暂存区

2. 暂存区 → 本地库：`git commit`

将暂存区的变更提交到本地库，生成永久版本记录，同时需填写 “提交日志”（描述本次修改内容，便于后续追溯）。

基本语法：

# 提交暂存区所有文件，-m 后接日志信息
git commit -m "日志信息"
# 提交暂存区指定文件
git commit -m "日志信息" 文件名

示例：

git commit -m "新增用户登录功能：完成账号密码验证逻辑"
git commit -m "修复首页加载缓慢问题：优化图片资源路径" index.html

日志规范：日志需简洁明了，准确描述修改目的（如 “修复 XXbug”“新增 XX 功能”“优化 XX 性能”），避免无意义表述（如 “修改文件”“更新代码”）。

2.4 查看提交日志

通过日志命令可查看仓库的版本演变过程，包括每个版本的 commit ID（版本唯一标识）、作者、提交时间、日志信息等。

1. 基础日志命令：`git log`

基本语法：

git log  # 查看当前分支所有提交日志（按时间倒序排列）

常用参数：
- --all：显示所有分支的日志（默认仅显示当前分支）；
- --pretty=oneline：每条日志压缩为一行（含 commit ID 和日志信息）；
- --abbrev-commit：缩短 commit ID（默认 40 位哈希值，缩短后 7 位左右，不影响唯一性）；
- --graph：图形化展示分支合并历史（直观呈现分支走向）。

2. 简化日志命令：`git-log`（别名）

在 1.2 节配置的 git-log 别名已集成上述所有参数，直接执行即可查看简洁的图形化日志：

git-log

2.5 版本回退：切换到历史版本

当代码引入 bug 或需要回滚到稳定版本时，可通过 git reset 命令，根据 commit ID 定位并切换到目标版本。

基本语法

git reset --hard commitID  # --hard 表示强制回退，工作区、暂存区、本地库同步到目标版本

示例：
若通过 git-log 查看到以下日志：

* 3456def (HEAD -> master) 修复登录验证码失效问题
* 123abc 新增首页轮播图功能
* 7890efg 初始化项目结构

要回退到 “新增首页轮播图功能” 的版本，执行：

git reset --hard 123abc

查看已删除日志：git reflog
若回退后想恢复到之前的新版本（如误回退），git log 可能无法看到新版本的 commit ID，此时可通过 git reflog 查看所有操作记录（包括已删除的提交）：
```
git reflog
```

2.6 忽略文件配置：`.gitignore`

开发中，部分文件（如编译生成的 dist 目录、日志文件 logs/、IDE 配置文件 .idea/）无需纳入 Git 管理，可通过 .gitignore 文件指定忽略规则，避免这些文件干扰版本控制。

配置步骤：

在仓库根目录创建 .gitignore 文件（文件名固定，大小写敏感）；

按以下格式添加忽略规则（支持通配符）：

# 注释：以 # 开头的行是注释
# 忽略所有 .log 后缀的文件
*.log
# 忽略 dist 目录（含目录下所有文件）
dist/
# 忽略 IDEA 配置目录
.idea/
# 忽略 node_modules 依赖目录
node_modules/
# 反向忽略：不忽略 src 目录下的 app.log 文件
!src/app.log

生效说明：
若已将需忽略的文件添加到暂存区，需先移除暂存区记录，规则才会生效：
```
git rm --cached 文件名  # 移除暂存区记录，不删除本地文件
```

三、Git 分支管理

分支是 Git 最核心的功能之一，它允许开发者在不影响主线开发的前提下，并行推进多个任务（如开发新功能、修复 bug）。分支本质是指向版本记录的 “指针”，切换分支即移动指针，操作轻量高效。

3.1 分支的核心价值

并行开发：多个开发者可在不同分支同步开发不同功能，互不干扰；
风险隔离：某分支开发失败（如功能无法实现、引入严重 bug），仅需删除该分支，不影响主线或其他分支；
版本可控：针对不同需求（新功能、bug 修复）创建专用分支，便于管理和追溯。

3.2 常用分支操作命令

1. 查看本地分支：`git branch`

查看当前仓库所有本地分支，当前所在分支前会标注 *。

语法：git branch

示例输出：

* master          # 当前分支feature/user    # 新功能分支hotfix/order    # bug 修复分支

2. 创建本地分支：`git branch 分支名`

从当前分支复制代码，创建新分支（新分支与当前分支代码完全一致）。

语法：git branch 分支名
示例：git branch feature/payment（创建 “支付功能” 分支）

3. 切换分支：`git checkout 分支名`

切换到已存在的分支，工作区代码会同步为目标分支的内容。

语法：git checkout 分支名
示例：git checkout feature/payment（切换到支付功能分支）

4. 创建并切换分支：`git checkout -b 分支名`

一步完成 “创建分支 + 切换分支”，是开发中最常用的命令之一。

语法：git checkout -b 分支名
示例：git checkout -b hotfix/login-bug（创建并切换到 “登录 bug 修复” 分支）

5. 合并分支：`git merge 分支名`

将指定分支的代码合并到当前所在分支（如将功能分支合并到主线分支）。

操作流程：
1. 切换到目标分支（要合并到的分支）；
2. 执行合并命令，指定来源分支（要合并的分支）。

示例（将支付功能分支合并到 master）：

git checkout master          # 切换到目标分支 master
git merge feature/payment    # 合并来源分支 feature/payment

6. 删除分支：`git branch -d` / `git branch -D`

分支功能完成并合并后，可删除分支以保持仓库整洁。

安全删除（需确认分支已合并，否则报错）：git branch -d 分支名
强制删除（不检查合并状态，慎用）：git branch -D 分支名

示例：

bash

git branch -d feature/payment  # 安全删除已合并的支付功能分支
git branch -D feature/old-func # 强制删除未合并的旧功能分支

注意：不能删除当前所在分支，需先切换到其他分支再删除。

3.3 分支冲突：原因与解决方法

合并分支时，若两个分支在同一文件的同一位置有不同修改（如分支 A 修改了 index.js 第 20 行，分支 B 也修改了该行），Git 无法自动判断使用哪部分代码，会产生 “冲突”。

1. 冲突表现：

执行 git merge 后，终端提示 Automatic merge failed; fix conflicts and then commit the result.；
执行 git status 显示 You have unmerged paths.，冲突文件状态为 both modified；
冲突文件中出现 Git 自动添加的标记，格式如下：

2. 冲突解决步骤：

编辑冲突文件：打开冲突文件，删除 <<<<<<< HEAD、=======、>>>>>>> 分支名 标记，根据业务需求保留正确代码；
添加到暂存区：执行 git add 冲突文件名，将解决后的文件添加到暂存区；
提交合并结果：执行 git commit -m "解决分支冲突：保留用户信息校验逻辑"（此时不能带文件名）。

3.4 企业级分支使用原则与流程

在实际开发中，分支管理需遵循规范流程，确保版本稳定和协作高效。常见的分支策略如下：

分支类型	来源分支	用途说明	合并目标
`master`（生产）	-	线上运行版本，稳定不可直接修改	-
`develop`（开发）	`master`	开发主线，集成已完成的功能，用于测试	测试通过后合并到 `master`
`feature/xxx`	`develop`	新功能开发（如 `feature/payment`）	功能完成后合并到 `develop`
`hotfix/xxx`	`master`	线上 bug 紧急修复（如 `hotfix/login-bug`）	修复后合并到 `master` 和 `develop`
`test`（测试）	`develop`	专门用于测试的分支，避免测试影响开发主线	测试通过后合并到 `master`
`pre`（预上线）	`develop`	上线前最终验证，模拟生产环境	验证通过后合并到 `master`