Git核心命令与分支管理

---

一、Git 基础概念

1. 工作区（Working Directory）：本地代码的物理目录。
2. 暂存区（Staging Area）：通过 git add 提交到暂存区的文件。
3. 本地仓库（Local Repository）：通过 git commit 提交到本地仓库的代码。
4. 远程仓库（Remote Repository）：如 GitHub、GitLab 等托管平台。

---

二、核心命令与参数详解

1. 初始化与配置

# 初始化仓库
git init

# 全局配置用户信息
git config --global user.name "Your Name"
git config --global user.email "your@email.com"

# 查看配置
git config --list

2. 文件操作

# 添加文件到暂存区
git add <file>      # 添加单个文件
git add .           # 添加所有修改的文件
git add -A          # 添加所有修改和删除的文件

# 提交到本地仓库
git commit -m "commit message"    # 提交暂存区内容
git commit -a -m "message"        # 跳过 git add，直接提交已跟踪文件的修改

3. 查看状态与日志

git status          # 查看工作区和暂存区状态
git log             # 查看提交历史
git log --oneline   # 单行显示提交历史
git log --graph     # 显示分支合并图
git diff            # 查看工作区与暂存区的差异
git diff --staged   # 查看暂存区与最新提交的差异

4. 分支管理

git branch                  # 查看本地分支
git branch <branch-name>    # 创建新分支
git checkout <branch-name>  # 切换分支
git checkout -b <branch>    # 创建并切换到新分支
git merge <branch>          # 合并分支到当前分支
git branch -d <branch>      # 删除已合并的分支
git branch -D <branch>      # 强制删除未合并的分支

5. 远程操作

git remote add origin <url>     # 关联远程仓库
git push -u origin <branch>     # 首次推送并建立跟踪
git push                        # 推送代码到远程分支
git pull                        # 拉取远程分支并合并（相当于 git fetch + git merge）
git fetch                       # 仅拉取远程更新，不自动合并
git clone <url>                 # 克隆远程仓库

6. 撤销与回退

git reset --soft HEAD^     # 撤销 commit，保留修改到暂存区
git reset --mixed HEAD^    # 撤销 commit 和暂存区（默认行为）
git reset --hard HEAD^     # 彻底丢弃 commit 和修改
git revert <commit-id>     # 生成新提交来撤销某次提交
git checkout -- <file>     # 丢弃工作区的修改

---

三、多分支管理与 Git Flow

为什么需要多分支？

想象你在开发一个软件：

• 需要同时开发多个功能（比如“用户登录”和“支付功能”）
• 需要修复线上紧急 Bug（比如服务器崩溃）
• 需要测试新版本（比如即将发布的 V2.0）

如果所有人都在一个分支上修改代码，会频繁冲突且难以管理。
分支的作用：将不同任务隔离，确保开发、测试、发布互不干扰。

---

Git Flow 是什么？

一种标准化的分支管理模型，定义了 5种核心分支 和 操作流程，适合中大型项目。
它的核心思想是：不同分支负责不同阶段的任务，像工厂流水线一样分工明确。

---

1. Git Flow 的 5 种核心分支（图解）

主分支（永久存在）：
├── master        ：生产环境代码，只存放稳定版本（比如 v1.0, v2.0）
└── develop       ：开发主分支，整合所有新功能

辅助分支（临时使用）：
├── feature/xxx   ：开发新功能的分支（从 develop 创建）
├── release/xxx   ：预发布测试分支（从 develop 创建）
└── hotfix/xxx    ：紧急修复生产 Bug 的分支（从 master 创建）

分支职责详解表

分支类型	从哪个分支创建？	合并到哪个分支？	何时删除？
feature	develop	develop	功能合并到 develop 后删除
release	develop	master 和 develop	版本发布后删除
hotfix	master	master 和 develop	热修复合并后删除

---

2. 使用 Git Flow（含命令详解）

2.1 初始化 Git Flow

如果你的团队使用 git-flow 工具（需安装）：

# 安装 git-flow（以 macOS 为例）
brew install git-flow

# 在项目根目录初始化
git flow init

初始化时会交互式询问分支名称，一般直接回车使用默认值：

• master：生产分支
• develop：开发分支
• 其他分支前缀（如 feature/、release/）保持默认即可

---

2.2 开发新功能（feature 分支）

场景：需要开发“用户登录”功能。

# 1. 从 develop 创建并切换到 feature/user-login 分支
git flow feature start user-login

# 2. 开发代码...（修改文件、测试等）

# 3. 提交代码到当前 feature 分支
git add .
git commit -m "完成用户登录界面"

# 4. 完成功能开发，合并回 develop 分支并删除 feature 分支
git flow feature finish user-login

发生了什么？

• feature start：基于 develop 创建 feature/user-login 分支
• feature finish：自动将 feature/user-login 合并到 develop，并删除该 feature 分支

---

2.3 预发布测试（release 分支）

场景：开发完成，准备发布 V1.0 版本前进行测试。

# 1. 从 develop 创建 release 分支
git flow release start 1.0.0

# 2. 在 release/1.0.0 分支上测试，修复 Bug...
git add .
git commit -m "修复测试发现的支付接口问题"

# 3. 完成测试，发布正式版本
git flow release finish 1.0.0

发生了什么？

• release finish 会做三件事：
  1. 合并 release/1.0.0 到 master（生成正式版本）
  2. 给 master 打上标签 v1.0.0
  3. 将 release/1.0.0 的修改合并回 develop（同步 Bug 修复）
  4. 删除 release/1.0.0 分支

---

2.4 紧急修复生产 Bug（hotfix 分支）

场景：用户反馈 V1.0 版本支付失败，需立即修复。

# 1. 从 master 创建 hotfix 分支
git flow hotfix start payment-fix

# 2. 修复代码并提交
git add .
git commit -m "修复支付接口超时问题"

# 3. 完成热修复
git flow hotfix finish payment-fix

发生了什么？

• hotfix finish 会做三件事：
  1. 合并 hotfix/payment-fix 到 master（生成新版本）
  2. 给 master 打上标签 v1.0.1
  3. 将热修复代码合并回 develop（避免后续版本遗漏此修复）
  4. 删除 hotfix/payment-fix 分支

---

3. 手动实现 Git Flow（不使用 git-flow 工具）

如果团队不使用 git-flow 工具，也可手动操作：

3.1开发新功能

# 1. 从 develop 创建 feature 分支
git checkout develop
git checkout -b feature/user-login

# 2. 开发完成后合并到 develop
git checkout develop
git merge feature/user-login

# 3. 删除 feature 分支
git branch -d feature/user-login

3.2发布版本

# 1. 从 develop 创建 release 分支
git checkout develop
git checkout -b release/1.0.0

# 2. 测试完成后合并到 master 和 develop
git checkout master
git merge release/1.0.0
git tag v1.0.0

git checkout develop
git merge release/1.0.0

# 3. 删除 release 分支
git branch -d release/1.0.0

---

4. 关键原则与常见问题

原则 1：分支隔离

• master 只用于发布，禁止直接提交代码
• develop 是集成分支，所有新功能通过 feature 分支合并进来

原则 2：分支命名规范

• feature/功能名称（如 feature/user-login）
• release/版本号（如 release/1.0.0）
• hotfix/问题描述（如 hotfix/payment-error）

常见问题

Q1：多个功能同时开发会冲突吗？

• 不会，每个功能在独立分支开发，最后合并到 develop 时解决冲突即可。

Q2：release 分支测试期间如何修复 Bug？

• 直接在 release/1.0.0 分支上修改并提交，完成后合并到 master 和 develop。

Q3：hotfix 和 release 分支的区别？

• hotfix 用于修复已发布的版本（如 master 上的代码）
• release 用于测试即将发布的新版本

---

5. 可视化流程图

[新功能开发]  
develop → feature/xxx → develop  

[版本发布]  
develop → release/1.0.0 → master (打标签)  
                ↓  
               develop  

[紧急修复]  
master → hotfix/xxx → master (打标签)  
                ↓  
               develop  

通过这套流程，代码始终在可控的分支中流动，既能支持多人协作，又能确保生产环境的稳定性。

---

四、常见场景与解决方案

1. 合并冲突

手动编辑冲突文件后执行：

git add <file>
git commit -m "resolve conflicts"

2. 暂存修改切换分支

git stash          # 暂存当前修改
git stash pop      # 恢复暂存内容

3. 找回误删的分支

git reflog                 # 查找提交记录
git checkout -b <branch> <commit-id>

---

五、总结

• 基础命令：add, commit, push, pull, branch, merge。
• 高效协作：遵循 Git Flow 规范，明确分支职责。
• 灵活处理：根据团队需求调整分支策略，例如简化版 Git Flow（如 GitHub Flow）。

通过掌握这些核心命令和策略，可以高效管理代码版本并适应复杂的协作场景。