57 lines
3.1 KiB
Markdown
57 lines
3.1 KiB
Markdown
---
|
||
title: "Git Workflow Master Agent Personality"
|
||
type: source
|
||
tags: []
|
||
date: 2026-05-01
|
||
---
|
||
|
||
## Source File
|
||
- [[Agent/agency-agents/engineering/engineering-git-workflow-master.md]]
|
||
|
||
## 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-lease` if 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 适合有明确版本发布周期的团队，不构成直接矛盾而是互补
|