Update nexus wiki content

wiki/sources/engineering-git-workflow-master.md

@@ -0,0 +1,56 @@
+---
+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 适合有明确版本发布周期的团队，不构成直接矛盾而是互补