affaan-m/git-workflow

Git 工作流模式，包括分支策略、提交规范、合并与变基的选择、冲突解决以及适用于各种规模团队的协作开发最佳实践。在选择分支策略、编写提交规范、决定合并还是变基、或解决冲突时使用。

编程协作开发 Agent Agent 技能调研自动化仓库问答 Git 分支策略提交规范撰写合并冲突解决协作开发流程代码评审辅助

技术栈: cursor25万+许可证: MIT开发者: affaan-m

Skill 介绍Skill 文件

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

在 GitHub 查看 ↗

原文译文

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

Git Workflow Patterns

Best practices for Git version control, branching strategies, and collaborative development.

When to Activate

Setting up Git workflow for a new project
Deciding on branching strategy (GitFlow, trunk-based, GitHub flow)
Writing commit messages and PR descriptions
Resolving merge conflicts
Managing releases and version tags
Onboarding new team members to Git practices

Branching Strategies

GitHub Flow (Simple, Recommended for Most)

Best for continuous deployment and small-to-medium teams.

main (protected, always deployable)
  │
  ├── feature/user-auth      → PR → merge to main
  ├── feature/payment-flow   → PR → merge to main
  └── fix/login-bug          → PR → merge to main

Rules:

main is always deployable
Create feature branches from main
Open Pull Request when ready for review
After approval and CI passes, merge to main
Deploy immediately after merge

Trunk-Based Development (High-Velocity Teams)

Best for teams with strong CI/CD and feature flags.

main (trunk)
  │
  ├── short-lived feature (1-2 days max)
  ├── short-lived feature
  └── short-lived feature

Rules:

Everyone commits t…

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

Git 工作流模式

Git 版本控制、分支策略与协作开发的最佳实践。

何时启用

为新项目设置 Git 工作流
决定分支策略（GitFlow、trunk-based、GitHub flow）
编写提交信息和 PR 描述
解决合并冲突
管理发布和版本标签
为新团队成员进行 Git 实践培训

分支策略

GitHub Flow（简单，推荐大多数场景使用）

最适合持续部署以及中小型团队。

main (受保护，始终可部署)
  │
  ├── feature/user-auth      → PR → 合并到 main
  ├── feature/payment-flow   → PR → 合并到 main
  └── fix/login-bug          → PR → 合并到 main

规则：

main 始终处于可部署状态
从 main 创建功能分支
准备好接受评审时开启 Pull Request
审批通过且 CI 通过后，合并到 main
合并后立即部署

Trunk-Based Development（高速迭代团队）

最适合拥有强大 CI/CD 和特性开关的团队。

main (trunk)
  │
  ├── 短期特性分支（最多 1-2 天）
  ├── 短期特性分支
  └── 短期特性分支

规则：

所有人都向 main 提交，或使用极短生命周期的分支
使用特性开关隐藏未完成的工作
合并前必须通过 CI
每天多次部署

GitFlow（复杂，以发布周期为导向）

最适合有计划发布的项目和企业级项目。

main (生产发布)
  │
  └── develop (集成分支)
        │
        ├── feature/user-auth
        ├── feature/payment
        │
        ├── release/1.0.0    → 合并到 main 和 develop
        │
        └── hotfix/critical  → 合并到 main 和 develop

规则：