3.1 KiB
3.1 KiB
title, type, tags, date
| title | type | tags | date |
|---|---|---|---|
| Git Workflow Master Agent Personality | source | 2026-05-01 |
Source File
Summary（用中文描述）
- 核心主题：Git 工作流与版本控制策略专家 Agent 个性定义
- 问题域：团队协作中的分支管理、历史整洁、提交规范、CI/CD 集成
- 方法/机制：
- 原子提交（Atomic Commits）：每次提交只做一件事
- Conventional Commits 规范：
feat:/fix:/chore:/docs:/refactor:/test: - 两种分支策略：Trunk-Based Development（主推）和 Git Flow（版本发布）
- 高级技巧：Worktree / Interactive Rebase / Git Bisect / Reflog / Cherry-pick
- 安全强制推送：
--force-with-lease - 合并策略：
--no-ff或 Squash Merge
- 结论/价值：帮助团队维护干净的提交历史，避免合并地狱（merge hell），建立可追溯、可协作的版本控制规范
Key Claims（用中文描述）
- 每个提交原子化（每次只做一件事，可独立回滚）
- Conventional Commits 格式保证提交历史可读、可自动化解析
- Trunk-Based 是大多数团队推荐的分支策略（短生命周期特性分支）
- Git Flow 适合有明确版本发布周期的团队
- 永远不要在共享分支上强制推送，应使用
--force-with-lease - PR/MR 合并前必须 rebase 到目标分支最新代码
Key Quotes
"Atomic commits — Each commit does one thing and can be reverted independently." — Git Workflow Master 核心原则 "Never force-push shared branches — Use
--force-with-leaseif you must." — 安全推送规范 "Branch from latest — Always rebase on target before merging." — 合并前规范
Key Concepts
- AtomicCommits：每次提交只做一件事，可独立回滚的提交单元
- ConventionalCommits：标准化的提交信息格式（feat/fix/chore/docs/refactor/test）
- TrunkBasedDevelopment：主分支始终可部署，短生命周期特性分支的分支策略
- GitFlow：含 main/develop/release/hotfix 多分支，适合版本化发布的分支策略
- ForceWithLease：
--force-with-lease安全强制推送版本，避免覆盖他人提交
Key Entities
- 无关键外部实体（本文档为 Agent 个性定义，无外部公司/产品引用）
Connections
- CodeReviewer ← informs → GitWorkflowMaster（代码审查需基于规范化的提交历史）
- CIGithub ← integrates_with → GitWorkflowMaster（CI pipeline 依赖分支保护规则和自动化检查）
- GitOps ← extends → GitWorkflowMaster（GitOps 以 Git 工作流为基础，扩展了 IaC 和部署自动化）
Contradictions
- 与 Git Flow 页面冲突：
- 冲突点：Trunk-Based vs Git Flow 哪个是"推荐"策略
- 当前观点（Git Workflow Master）：Trunk-Based 适合大多数团队
- 对方观点（GitFlow）：Git Flow 是处理版本发布和多环境管理的标准方案
- 说明：两者各有适用场景，Trunk-Based 适合持续部署团队，Git Flow 适合有明确版本发布周期的团队，不构成直接矛盾而是互补