Skip to content

version-control.md

Latest commit

 

History

History
144 lines (109 loc) · 2.98 KB

version-control.md

File metadata and controls

144 lines (109 loc) · 2.98 KB
Raw

版本控制

为什么需要版本控制？

版本控制是现代软件开发的基础。它支持：

  • 跟踪代码随时间的变化
  • 团队间的协作
  • 代码审查和质量把控
  • 版本回退能力
  • 发布管理

Git 基础

Git 是业界标准的分布式版本控制系统，被开源社区和企业广泛使用。

关键概念

仓库：包含所有代码和历史的项目 提交：包含元数据的代码快照 分支：平行开发线 远程：中央化仓库（GitHub、GitLab） 合并：来自不同分支的更改组合

常见 Git 工作流

特性分支工作流

git checkout -b feature/new-auth-system
# 进行更改
git commit -m "实现 JWT 认证"
git push origin feature/new-auth-system
# 创建拉取请求

Git Flow

  • main（生产就绪）
  • develop（集成分支）
  • feature/*（新特性）
  • hotfix/*（生产补丁）
  • release/*（发布准备）

基于主干的开发

  • 单一主分支（main）
  • 短期特性分支（< 1 天）
  • 持续集成
  • 使用特性标志表示不完整工作

GitHub

世界领先的协作软件开发平台。

GitHub 工作流

拉取请求（PRs）

  • 代码审查机制
  • 自动化检查和测试
  • 讨论和批准工作流
  • 合并策略（压缩、变基、合并提交）

GitHub Actions

  • 原生 CI/CD 平台
  • 自动化测试和部署
  • 定时工作流
  • 社区维护的 Actions

GitHub Issues

  • 错误跟踪
  • 功能请求
  • 项目规划
  • 讨论线程

GitHub 最佳实践

  • 要求分支保护规则
  • 合并前强制代码审查
  • 对所有 PR 运行自动化测试
  • 使用语义化提交消息
  • 使用版本号标记发布

分支策略

特性分支

  • 每个特性一个分支
  • 短期（1-3 天）
  • 合并前进行自动化测试

环境分支

  • main → 生产
  • staging → 预生产
  • develop → 集成

发布分支

  • release/v1.2.0 用于发布准备
  • 使用版本标记修复
  • 自动版本号碰撞

提交消息指南

<类型>(<范围>): <主题>

<正文>

<页脚>

类型：feat、fix、docs、style、refactor、test、chore 示例：

feat(auth): 添加 JWT 令牌刷新端点

实现自动令牌刷新以改进用户体验
并减少会话超时。

修复 #123

代码审查最佳实践

  1. 及时审查：24 小时内审查
  2. 建设性反馈：专注于代码，而不是个人
  3. 清晰批准：区分批准和建议
  4. 自动化检查：让工具强制执行标准
  5. 记录决策：解释为什么，而不仅仅是什么

高级主题

Git 钩子

自动化检查提交/推送前

  • pre-commit：lint、格式检查
  • commit-msg：强制提交消息格式
  • pre-push：本地运行测试

语义化版本控制

  • 主.次.补（例如 1.2.3）
  • 主：不兼容的 API 更改
  • 次：向后兼容的特性
  • 补：错误修复

提交压缩

在合并前组合多个提交以保持历史整洁

git rebase -i HEAD~3  # 压缩最后 3 个提交