Git的基本使用

相关信息

🎯 核心原则

1. 主分支保护：main/develop 分支只接受 Pull Request
2. 功能隔离：每个功能/修复都在独立分支开发
3. 代码审查：所有变更必须经过 peer review
4. 持续集成：自动运行测试和检查
5. 清晰历史：保持提交历史的可读性和可追溯性

整体架构

分支结构

主分支 (长期存在):
main     - 生产代码，每个提交都是可发布的
develop  - 开发主线，集成了所有完成的功能

支持分支 (临时存在):
feature/*  - 功能开发分支
release/*  - 版本发布分支  
hotfix/*   - 紧急修复分支

完整流程：

main (生产)
    ↑
release/* (测试/预发布)
    ↑
develop (开发集成)  ← 你应该从这里开始！
    ↑
feature/* (功能分支) ← 你在这里开发

环境与分支的对应关系：

开发环境 (dev):
  分支: develop
  自动部署: 每次合并到develop自动部署
  用途: 日常开发测试

测试环境 (test/staging):
  分支: release/*
  自动部署: 创建release分支时部署
  用途: 集成测试、产品验收

预生产环境 (pre-prod):
  分支: main (latest tag)
  手动部署: 发布前验证
  用途: 生产前最后验证

生产环境 (prod):
  分支: main (特定tag)
  手动部署: 审批后部署
  用途: 线上用户使用

更详细的流程请看：敏捷开发流程

实际开发流程示例

背景：你是一名新入职的开发，你有一个开发聊天机器人功能的任务。

第1步：准备开发环境

# 默认克隆的是远程的默认分支（通常是 main）,但远程的 develop 分支信息也已经下载了
git clone https://github.com/company/project.git  
cd project

#切换到develop分支
git checkout develop 

#从远程仓库拉取最新的develop分支的代码
git pull origin develop  

#创建并并切换到你的功能分支    -b:创建并切换
git checkout -b feature/chatbot

此时分支情况如下:

​ [main] --- [develop] --- [feature/chatbot]

为什么要新建一个分支？

因为你要开发新功能，而代码还不稳定，所以不能直接在main或develop分支上写代码。

第2步：开始新功能开发

# ... 你写了很多代码 ...
git add .
git commit -m "feat:完成聊天机器人功能"
# ... 又写了一些 ...
git add .
git commit -m "feat:适配多种模型"

第3步：完成开发，发起合并请求

你的功能开发完了，现在需要把它合并到develop分支。

1、把你的分支推送到远程仓库：

git push origin feature:chatbot

2、在GIthub上发起一个Pull Request（PR）：

1. 访问仓库页面
2. 点击 "New Pull Request"
3. 选择：
   • base: develop
   • compare: feature/chatbot
4. 填写 PR 信息：

## 标题
“Feat:新增聊天机器人功能”

## 变更描述
实现机器人聊天功能

## 相关 Issue
Closes #123

## 变更类型
- [x] 新功能
- [ ] Bug修复
- [ ] 文档更新
- [ ] 代码重构

## 测试说明
1. 运行 `npm test` 通过
2. 手动测试登录流程
3. 集成测试覆盖率达到 85%

## 截图
![机器人聊天页面](https://example.com/screenshot.png)

## 检查清单
- [x] 代码遵循项目规范
- [x] 添加/更新了测试
- [x] 文档已更新
- [x] 没有引入新的警告

第4步：代码审查

第5步：合并到开发分支

审查通过后，在PR界面点击Merge Pull Request按钮。

你的代码就正式合并到了develop分支了!

此时分支结构：

[main] --- [develop]（现在包含了机器人聊天功能）--- [feature/xxx]（其他开发人员的分支）

后续流程：

• develop分支——>集成测试环境
• 运维人员会将develop分支的代码部署到测试服务器。
• 测试人员在测试环境测试你的机器人聊天功能。

常用命令

git branch -a

小疑问

1、敏捷开发流程

案例：电商网站迭代发布

## 迭代计划：双十一促销功能

### 开发阶段（2周）
- 功能A：预售定金支付（feature/advance-payment）
- 功能B：优惠券叠加计算（feature/coupon-stack）
- 功能C：库存预警系统（feature/stock-alert）

### 代码冻结日（周四）
✅ 已完成：
- 三个功能都已合并到develop
- 基础测试通过
- 产品初步验收

🚫 停止接收：
- 新的促销功能需求
- 页面样式优化
- 性能优化建议

### 冻结后工作（2天）
1. **集成测试**：三个功能一起测试
2. **压力测试**：模拟双十一流量
3. **安全测试**：支付安全审查
4. **Bug修复**：只修复关键问题

### 发布日（周六）
- 早上：最后一次全量测试
- 下午：合并release到main，打标签v2.5.0
- 晚上：灰度发布，监控指标

# 第1天：迭代开始
# 从上一个版本的tag创建新迭代分支
git checkout -b iteration/2024-sprint-1 v1.2.0

# 第1-9天：日常开发
git checkout develop
git checkout -b feature/xxx
# 开发、提交、推送、PR、合并到develop

# 第10天：代码冻结，创建release分支
git checkout develop
#新建并切换到release分支，release分支与develop内容相同
git checkout -b release/v1.3.0
git push -u origin release/v1.3.0

# 第11-12天：测试和修复
# 只在release分支修复bug，不添加新功能
git checkout release/v1.3.0
# 修复bug，提交
git commit -m "fix: 修复登录页面样式问题"

# 第13天：发布准备
git checkout main
git merge --no-ff release/v1.3.0
git tag -a v1.3.0 -m "Release version 1.3.0"
git push origin main --tags

# 同步回develop
git checkout develop
git merge --no-ff release/v1.3.0
git push origin develop

# 清理
git branch -d release/v1.3.0
git push origin --delete release/v1.3.0

main (生产)           ← 稳定版本，打标签 v1.0, v1.1, v1.2
├─ release/v1.3       ← 当前迭代发布分支（代码冻结后创建）
├─ develop            ← 日常开发集成
│  ├─ feature/login   ← 功能分支A
│  ├─ feature/payment ← 功能分支B
│  └─ feature/api     ← 功能分支C
└─ hotfix/urgent      ← 紧急修复（如果有）

版本冻结后的具体操作

周一至周五（第一周）：开发新功能
周六至周日：休息
周一至周三（第二周）：继续开发
周四：代码冻结日 ⭐
周四至周五：测试和修复
周五下午：发布

冻结当天的操作

# 1. 早上10点：宣布代码冻结
# 通知所有人：不再接受新功能PR

# 2. 从develop创建release分支
git checkout develop
git pull origin develop
git checkout -b release/v1.3.0
git push -u origin release/v1.3.0

# 3. 配置CI/CD：只允许release分支部署到测试环境

# 4. 更新项目状态：所有新功能PR标记为"下个迭代"

2、如果出问题了怎么办？

如果发布后发现问题

# 1. 立即回滚到上一个标签
git checkout main
git reset --hard v1.1.0
git push origin main --force

# 2. 通知团队
# 3. 创建 hotfix 分支修复问题
git checkout main
git checkout -b hotfix/critical-issue
# ... 修复 ...
git checkout main
git merge --no-ff hotfix/critical-issue
git tag v1.2.1
git push origin main --tags

# 4. 同步到 develop
git checkout develop
git merge --no-ff hotfix/critical-issue
git push origin develop

3、为什么要冻结？

# 假设一个2周迭代：
第1-9天：疯狂开发，添加各种功能
第10天：代码冻结 ← 从这里开始
第10-12天：只修复bug，让版本稳定
第13天：发布

没有冻结会怎样？

• 永远在加新功能，永远发布不了
• 新功能引入新bug，恶性循环
• 测试永远跟不上开发节奏

心理学原理：功能膨胀

• 开发："这个bug很容易修复"
• 产品："顺便加个小功能吧"
• 测试："这又是什么？没测试过"
• 结果：发布时间推迟，质量下降