Git 代码管理流程

最新推荐文章于 2025-11-02 21:07:12 发布

原创最新推荐文章于 2025-11-02 21:07:12 发布 · 1.5k 阅读

29 ·

CC 4.0 BY-SA版权

文章标签：

#elasticsearch #大数据 #搜索引擎

该文章已生成可运行项目，

一、Git 核心概念

1. 三个工作区域详解

Git 工作目录下包含三个关键区域，所有操作本质上都是在这三个区域之间转移文件：

工作区（Working Directory）：

这是我们日常进行代码编辑的物理目录，所有文件变更都直接体现在这里
文件状态分为：
- "未跟踪（Untracked）"：新创建的且未被 git add 过的文件
- "已跟踪（Tracked）"：已经被 Git 纳入版本控制的文件
典型操作场景：
- 修改文件内容
- 创建新文件
- 删除文件

暂存区（Stage/Index）：

相当于一个"待提交变更的缓冲区"，是工作区和本地仓库之间的过渡区域
通过 git add 命令将工作区文件添加到暂存区
文件状态为 "已暂存（Staged）"
重要特性：
- 可以部分暂存（只提交某些修改）
- 允许修改提交内容（如修复拼写错误后再提交）
- 提供代码评审前的最后检查点

本地仓库（Local Repository）：

Git 的核心数据库，存储所有版本历史和元数据
通过 git commit 将暂存区文件提交到本地仓库
形成不可修改的版本记录（每个提交都有唯一的 SHA-1 哈希值）
包含：
- 提交历史
- 分支指针
- 标签
- 配置信息

2. 四个文件状态详解

Git 中文件的生命周期围绕四种状态流转，掌握状态变化是排查问题的关键：

未跟踪（Untracked）：

新创建的文件，Git 尚未纳入版本管理
git status 中显示为红色
典型场景：
- 新建的配置文件
- 自动生成的日志文件
需要显式执行 git add 才能转为已跟踪状态

已修改（Modified）：

已被 Git 跟踪的文件发生了修改
尚未提交到暂存区
git status 中显示为红色
修改包括：
- 内容变更
- 文件重命名
- 权限变更
- 删除操作

已暂存（Staged）：

通过 git add 添加到暂存区
git status 中显示为绿色
可以：
- 通过 git restore --staged 取消暂存
- 通过 git commit 提交到仓库

典型工作流：

git add file.txt   # 将修改添加到暂存区
git commit -m "update"  # 提交暂存区的修改

已提交（Committed）：

已通过 git commit 提交到本地仓库
形成稳定的版本记录
可以通过 git checkout 回退到该状态
特点：
- 不可修改（只能通过新提交覆盖）
- 包含完整的快照（而非差异）
- 带有提交者、时间戳等信息

3. 分支核心逻辑详解

Git 的分支本质是一个指向版本提交记录（Commit）的 "指针"，默认分支为 main（旧版本为 master）。分支的核心价值在于"隔离开发环境"。

分支特性：

创建成本极低（仅创建一个指针）
切换速度快（更改 HEAD 指针指向）
完全隔离的工作环境

典型分支操作：

git branch feature     # 创建分支
git checkout feature   # 切换分支
git branch -d feature  # 删除分支

分支使用场景：

功能开发：

git checkout -b feature/login  # 创建并切换至功能分支
# 开发登录功能...
git commit -m "完成登录界面"

Bug修复：

git checkout -b hotfix/404-page main  # 从main创建热修复分支
# 修复404页面问题...
git commit -m "修复404页面样式"

版本发布：

git checkout -b release/v1.0  # 创建发布分支
# 进行最终测试和调整...

分支同步方式：

合并（merge）：

保留完整历史记录
产生新的合并提交

操作：

git checkout main
git merge feature/login  # 将功能分支合并到主分支

变基（rebase）：

重写提交历史
形成线性历史

操作：

git checkout feature/login
git rebase main  # 将功能分支变基到主分支

分支管理策略：

功能分支工作流（Feature Branch Workflow）
Git Flow（含develop、release等分支）
GitHub Flow（简化版）
Trunk Based Development（主干开发）

二、Git 基础工作流程

1、初始化Git仓库

1. 本地新建项目初始化

# 1. 创建项目目录（建议使用有意义的名字）
mkdir my-project && cd my-project

# 2. 初始化Git仓库（会生成.git目录）
git init

# 3. 配置用户信息（仅在当前项目生效）
git config user.name "John Doe"
git config user.email "john.doe@example.com"

# 4. 验证配置（确认信息正确）
git config --list | grep user

典型应用场景：当你在本地开始一个新项目，需要版本控制时使用此方法。例如开发个人博客系统、小型工具应用等。

2. 克隆现有远程仓库

# 基本克隆（默认克隆master/main分支）
git clone https://github.com/user/repo.git

# 克隆到指定目录
git clone https://github.com/user/repo.git my-project

# 克隆特定分支（如develop分支）
git clone -b develop https://github.com/user/repo.git

# 克隆仓库但不下载文件（只获取.git元数据）
git clone --nocheckout https://github.com/user/repo.git

应用场景：接手已有项目开发时使用，例如从GitHub上克隆一个开源项目进行二次开发。

2、日常开发流程

1. 文件状态管理

# 查看详细状态（包括未跟踪、已修改、已暂存文件）
git status -vv

# 精简状态显示
git status -s

# 忽略文件模式变更（适用于Windows/Linux混合开发）
git config core.filemode false

示例：修改了index.html和style.css文件后，运行git status -s可能显示：

 M index.html
A  style.css
?? new-image.png

2. 暂存区操作

# 交互式添加（逐个选择要暂存的修改）
git add -p

# 添加所有修改（不包括未跟踪文件）
git add -u

# 撤销某个文件的暂存
git reset HEAD filename

# 撤销所有暂存（保留工作区修改）
git reset

高级技巧：使用git add -p可以精细控制提交内容，例如只提交某个文件中的部分修改。

3. 提交变更

# 标准提交
git commit -m "fix: 修复登录页面样式问题"

# 修改最后一次提交（不产生新提交记录）
git commit --amend

# 添加提交签名（需配置GPG密钥）
git commit -S -m "feat: 添加用户认证功能"

# 空提交（常用于CI/CD触发）
git commit --allow-empty -m "Trigger build"

提交信息规范建议：

使用约定式提交（Conventional Commits）
首行不超过50个字符
详细说明在第二行空一行后开始

3、远程仓库交互

1. 远程仓库管理

# 查看远程仓库详情
git remote show origin

# 修改远程仓库URL
git remote set-url origin new_url

# 添加多个远程仓库（如同时推送到GitHub和GitLab）
git remote add github git@github.com:user/repo.git
git remote add gitlab git@gitlab.com:user/repo.git

2. 推送代码

# 强制推送（谨慎使用，会覆盖远程历史）
git push -f

# 推送所有标签
git push --tags

# 删除远程分支
git push origin --delete branch-name

注意事项：强制推送会重写历史，在团队协作中应避免使用。

3. 拉取更新

# 拉取并自动合并（相当于fetch+merge）
git pull

# 拉取并变基（保持线性历史）
git pull --rebase

# 只获取不合并
git fetch

冲突解决步骤：

git pull 发现冲突
编辑冲突文件（查找<<<<<<<标记）
git add 标记冲突已解决
git commit 完成合并

4、实用技巧

1. 分支管理

# 创建新分支
git branch feature/login

# 切换分支
git checkout feature/login

# 创建并切换分支
git checkout -b hotfix/issue-123

# 删除本地分支
git branch -d branch-name

2. 暂存修改

# 暂存当前工作目录
git stash

# 查看暂存列表
git stash list

# 恢复最近的暂存
git stash pop

# 创建带描述的暂存
git stash save "WIP: 正在开发用户模块"

3. 日志查看

# 图形化显示提交历史
git log --graph --oneline --all

# 按作者筛选提交
git log --author="John"

# 搜索提交信息
git log --grep="bugfix"

# 显示某个文件的修改历史
git log -p filename

三、Git 分支管理流程

团队协作中，高效的分支管理是避免代码混乱的关键。目前主流的分支模型有Git Flow和GitHub Flow两种：

Git Flow：适合周期长、版本迭代规范的项目（如企业级应用、SaaS产品）
GitHub Flow：适合敏捷开发、快速迭代的项目（如互联网小团队、初创公司）

1. Git Flow 分支模型详解

1.1 核心分支类型与规范

分支类型	命名规范	用途说明	生命周期
主分支	`main`/`master`	存储正式发布的版本，始终保持可部署状态	永久存在
开发分支	`develop`	团队开发的主分支，整合各功能分支的代码	永久存在
功能分支	`feature/xxx`	开发新功能的分支（如`feature/login`）	功能开发完成即删除
发布分支	`release/vX.Y.Z`	准备发布版本的分支（如`release/v1.2.0`）	版本发布后删除
热修复分支	`hotfix/vX.Y.Z`	修复线上`main`分支bug的分支	修复完成后删除

1.2 分支关系图

main (production ready)
↑
hotfix/vX.Y.Z ←──┐
|               │
release/vX.Y.Z   │
↑               │
develop         │
↑               │
feature/xxx ────┘

2. Git Flow 完整操作流程

2.1 初始化Git Flow（首次搭建）

# 1. 确保本地仓库已关联远程，且main分支为初始状态
git init
git remote add origin <repository-url>

# 2. 创建并切换到develop分支（开发主分支）
git checkout -b develop

# 3. 将develop分支推送到远程（供团队成员使用）
git push -u origin develop

# 可选：安装git-flow扩展工具（简化操作）
brew install git-flow  # macOS
apt-get install git-flow  # Linux

2.2 开发新功能（feature分支）

# 1. 准备工作
git checkout develop
git pull origin develop  # 确保基于最新代码开发

# 2. 创建功能分支（示例：用户登录功能）
git checkout -b feature/login

# 3. 开发过程示例
# 3.1 开发登录页面
git add src/components/Login.vue
git commit -m "feat(login): 实现用户登录页面UI"

# 3.2 对接API
git add src/api/auth.js
git commit -m "feat(login): 完成登录接口对接"

# 4. 推送分支到远程
git push -u origin feature/login

# 5. 创建Pull Request（代码审查流程）
# 在GitHub/GitLab界面操作：
# - 选择base分支：develop
# - 选择compare分支：feature/login
# - 添加Reviewers进行代码审查

# 6. 合并流程（通过后）
git checkout develop
git merge --no-ff feature/login  # 保留完整分支历史
git push origin develop

# 7. 清理分支
git branch -d feature/login
git push origin --delete feature/login

2.3 准备发布版本（release分支）

# 1. 创建发布分支（版本号遵循语义化版本控制）
git checkout develop
git pull origin develop
git checkout -b release/v1.0.0

# 2. 版本准备阶段
# - 更新CHANGELOG.md
# - 修改版本号（package.json等）
# - 只允许bug修复提交
git commit -m "chore: 更新版本号为v1.0.0"
git commit -m "fix: 修复登录页面样式错位问题"

# 3. 测试通过后发布
# 3.1 合并到main分支
git checkout main
git merge --no-ff release/v1.0.0
git tag -a v1.0.0 -m "Release version 1.0.0"  # 创建带注释的标签
git push origin main --tags

# 3.2 同步到develop分支
git checkout develop
git merge --no-ff release/v1.0.0
git push origin develop

# 4. 清理分支
git branch -d release/v1.0.0
git push origin --delete release/v1.0.0

2.4 修复线上bug（hotfix分支）

# 1. 创建热修复分支（基于生产环境代码）
git checkout main
git pull origin main
git checkout -b hotfix/v1.0.1

# 2. 修复过程示例
# 2.1 紧急修复登录失效问题
git add src/api/auth.js
git commit -m "fix(auth): 修复token验证逻辑错误"

# 2.2 更新版本号
git add package.json
git commit -m "chore: 更新版本号为v1.0.1"

# 3. 发布修复
# 3.1 合并到main分支
git checkout main
git merge --no-ff hotfix/v1.0.1
git tag -a v1.0.1 -m "Hotfix version 1.0.1"
git push origin main --tags

# 3.2 同步到develop分支
git checkout develop
git pull origin develop  # 确保获取最新代码
git merge --no-ff hotfix/v1.0.1
git push origin develop

# 4. 清理分支
git branch -d hotfix/v1.0.1
git push origin --delete hotfix/v1.0.1

3. 最佳实践建议

分支命名规范
- 功能分支：feature/<功能简写>（如feature/user-profile）
- 发布分支：release/v<主版本>.<次版本>.<修订号>（如release/v1.2.0）
- 热修复分支：hotfix/v<主版本>.<次版本>.<修订号>

提交信息规范

使用约定式提交：

feat: 添加新功能
fix: 修复bug
docs: 文档变更
style: 代码格式调整
refactor: 代码重构
test: 测试相关
chore: 构建过程或辅助工具变更

代码审查
- 所有合并到develop或main的代码必须通过Pull Request
- 设置至少1-2名代码审查者
- 使用CI/CD工具自动运行测试
版本管理
- 遵循语义化版本控制：
  - 主版本号：不兼容的API修改
  - 次版本号：向下兼容的功能新增
  - 修订号：向下兼容的问题修正
冲突解决
- 定期将develop分支合并到长期存在的feature分支
- 合并前先执行git pull --rebase保持提交历史整洁

四、Git 操作注意事项

1. 提交相关注意事项

提交信息规范

提交信息应遵循 Conventional Commits 规范，详细说明变更内容：

类型：表明提交的性质
- feat: 新功能
- fix: bug修复
- docs: 文档变更
- style: 不影响代码逻辑的格式调整
- refactor: 代码重构
- test: 测试相关
- chore: 构建过程或辅助工具的变更

示例：

feat(user): 添加用户注册功能
fix(auth): 修复JWT过期时间计算错误
docs: 更新API接口文档
style: 统一代码缩进为4个空格

提交粒度控制

每次提交应聚焦单一功能或修复
避免"大爆炸式"提交（包含多个不相关变更）
推荐工作流程：
1. 实现登录页面UI → 单独提交
2. 对接登录API → 单独提交
3. 添加表单验证 → 单独提交

提交前检查

必做事项：

运行 git status 确认暂存区文件
运行 git diff --cached 查看待提交变更
确保不包含敏感信息（密码、密钥等）

.gitignore 示例：

# 依赖目录
node_modules/
vendor/

# 环境文件
.env
.env.local

# 日志文件
*.log
logs/

# IDE配置
.idea/
.vscode/

# 系统文件
.DS_Store
Thumbs.db

2. 分支操作注意事项

分支切换规范

推荐操作流程：

提交当前变更（推荐）：

git add .
git commit -m "wip: 保存当前工作进度"
git checkout target-branch

或使用 stash 暂存：

git stash save "描述当前修改内容"
git checkout target-branch
# 返回原分支后恢复
git stash pop

分支合并策略

标准流程：

更新目标分支：

git checkout develop
git pull origin develop

合并功能分支：

git checkout feature/login
git merge develop  # 先合并develop到feature
# 解决可能的冲突
git push origin feature/login

创建 Pull Request 进行代码审查

Rebase 使用场景

适用情况：

个人开发的功能分支
需要保持提交历史线性

操作示例：

git checkout feature/search
git fetch origin
git rebase origin/develop
# 处理冲突后
git rebase --continue
git push -f origin feature/search  # 需要强制推送

注意事项：

绝对不要在公共分支上使用 rebase
强制推送前确保没有其他协作者基于该分支工作

3. 远程协作注意事项

日常协作流程

每日工作前：

git checkout develop
git pull --rebase origin develop

功能开发：

git checkout -b feature/your-feature
# 进行开发...

定期同步：

git fetch origin
git rebase origin/develop

冲突解决指南

标准步骤：

识别冲突文件（git会标注冲突位置）
分析变更：
- <<<<<<< HEAD 到 ======= 之间是本地变更
- ======= 到 >>>>>>> branch-name 之间是远程变更
保留正确代码，删除冲突标记

验证功能：

git add resolved-file.js
git rebase --continue

最佳实践：

使用专业对比工具（Beyond Compare, VS Code等）
解决冲突后必须运行测试
复杂冲突应与相关开发人员协商

4. 版本回滚操作

本地回滚

场景：提交尚未推送到远程仓库

查看提交历史：
```
git log --oneline --graph
```
回滚选项：
- 软回滚（保留修改）：
```
git reset --soft abc123
```
- 混合回滚（保留工作区）：
```
git reset abc123
```
- 硬回滚（完全删除）：
```
git reset --hard abc123  # 慎用！
```

远程回滚

场景：错误提交已推送到远程

创建反向提交：
```
git revert abc123
```
推送修正：
```
git push origin branch-name
```
复杂情况处理：
- 多个提交需要回滚：
```
git revert abc123..def456
```
- 合并提交回滚：
```
git revert -m 1 merge-commit-id
```