addyosmani/git-workflow-and-versioning

结构化地组织 git 工作流实践。在进行任何代码修改时使用。在提交、分支管理、解决冲突，或需要组织多条并行工作流时使用。在发布版本、选择语义化版本号升级、打标签或编写变更日志时使用。

编程协作开发 Agent Agent 技能代码生成自动化仓库问答 skill agent-skill git workflow and versioning addyosmani agent-skills

技术栈: cursor9万+许可证: MIT开发者: addyosmani

Skill 介绍Skill 文件

重要提示：本站仅作 Skill 资源导航与收录，正文以 GitHub 原仓库为准，版权归原项目所有。

在 GitHub 查看 ↗

原文译文

以下为摘要预览，完整内容请查看 GitHub 原文。

Git Workflow and Versioning

Overview

Git is your safety net. Treat commits as save points, branches as sandboxes, and history as documentation. With AI agents generating code at high speed, disciplined version control is the mechanism that keeps changes manageable, reviewable, and reversible.

When to Use

Always. Every code change flows through git.

Core Principles

Trunk-Based Development (Recommended)

Keep main always deployable. Work in short-lived feature branches that merge back within 1-3 days. Long-lived development branches are hidden costs — they diverge, create merge conflicts, and delay integration. DORA research consistently shows trunk-based development correlates with high-performing engineering teams.

main ──●──●──●──●──●──●──●──●──●──  (always deployable)
        ╲      ╱  ╲    ╱
         ●──●─╱    ●──╱    ← short-lived feature branches (1-3 days)

This is the recommended default. Teams using gitflow or long-lived branches can adapt the principles (atomic commits, small changes, descriptive messages) to their branching model — the commit discipline matters more than the specific branching strategy.

Dev branches are costs. Every …

以下为摘要预览，完整内容请查看 GitHub 原文。

Git 工作流与版本管理

概述

Git 是你的安全网。把提交当作存档点，把分支当作沙盒，把历史当作文档。在 AI 智能体高速生成代码的背景下，纪律严明的版本控制是保持变更可管理、可审查、可回滚的机制。

使用时机

始终使用。每一次代码变更都流经 git。

核心原则

基于主干的开发（推荐）

保持 main 始终可部署。在短生命周期的特性分支中工作，并在 1–3 天内合并回主干。长期存在的开发分支是隐性的成本——它们会分化、产生合并冲突并延迟集成。DORA 的研究反复表明，基于主干的开发与高绩效工程团队正相关。

main ──●──●──●──●──●──●──●──●──●──  (始终可部署)
        ╲      ╱  ╲    ╱
         ●──●─╱    ●──╱    ← 短生命周期特性分支（1–3 天）

这是推荐的默认方式。使用 gitflow 或长生命周期分支的团队可以将这些原则（原子提交、小颗粒改动、描述性消息）适配到自己的分支模型上——重要的不是具体的分支策略，而是提交的纪律。

开发分支就是成本。 分支每多存活一天，就多累积一分合并风险。
发布分支可以接受。 当你需要在 main 持续演进的同时稳定某个发布版本时可以使用。
特性开关优于长分支。 优先通过特性开关部署未完成的工作，而不是让它们在分支上停留数周。

1. 尽早提交，频繁提交

每一个成功的增量都应有自己独立的提交。不要累积大量未提交的更改。

工作模式：
  实现一个切片 → 测试 → 验证 → 提交 → 下一个切片

不要这样：
  实现所有内容 → 期望一切正常 → 巨型提交

提交就是存档点。如果下一次改动破坏了某些东西，你可以立刻回退到上一个已知良好的状态。

2. 原子提交

每个提交只做一件逻辑上的事：

# 好的：每个提交都是自洽的
git log --oneline
a1b2c3d Add task creation endpoint with validation
d4e5f6g Add task creation form component
h7i8j9k Connect form to API and add loading state
m1n2o3p Add task creation tests (unit + integration)

# 不好的：所有东西混杂在一起
git log --oneline
x1y2z3a Add task feature, fix sidebar, update deps, refactor utils