Git分支上下文恢复工具 - 智能分析代码变更与Linear工单关联

recover-branch-context by casper-studios/casper-marketplace

165 周安装量

10 GitHub Stars

GitHub

安装命令

npx skills add https://github.com/casper-studios/casper-marketplace --skill recover-branch-context

开发项目管理版本控制

🇨🇳中文介绍

恢复分支上下文

你的任务是理解现有分支的意图和当前状态，以便能够有效地恢复或继续工作。代码状态是你的主要事实来源——它可能已经与任何相关的 Linear 工单产生了偏离。

初始响应

当调用此命令时，请回复：

我将帮助你理解这个分支的上下文。让我分析提交记录和变更。

你有这项工作的 Linear 工单 ID 或 URL 吗？（可选 - 没有它我也可以继续）

然后稍等用户的回复。如果他们提供了工单，则获取它。如果他们说不或没有快速回复，则继续进行分析。

处理步骤

步骤 1：确定基础分支

检查常见的基础分支名称：

git branch -a | grep -E "(main|master|dev|develop)" | head -5

查找合并基准点：

# 先尝试 dev（在此仓库中常见），然后是 main/master
git merge-base HEAD dev 2>/dev/null || git merge-base HEAD main 2>/dev/null || git merge-base HEAD master

获取当前分支名称：
```
git branch --show-current
```

步骤 2：收集自偏离以来的提交历史

广告位招租

在这里展示您的产品或服务

触达数万 AI 开发者，精准高效

联系我们

步骤 3：收集未提交的变更

获取已暂存的变更：
```
git diff --name-status --cached
```
获取未暂存的变更：
```
git diff --name-status
```

获取未跟踪的文件：

git ls-files --others --exclude-standard

完整的工作树状态：
```
git status --short
```

步骤 4：获取 Linear 工单（如果提供）

如果用户提供了 Linear 工单：

使用 mcp__linear__get_issue 工具获取工单详情
注意：工单代表原始需求，但代码可能已经演变

步骤 5：按意图分析和分组变更

关键：不要仅仅列出文件。按逻辑功能区域或意图对它们进行分组。

阅读关键的变更文件以理解它们的作用
识别变更中的模式：
- 新功能添加
- 错误修复
- 重构
- 配置变更
- 测试添加
按目的对文件进行分组，而不是按目录

步骤 6：输出摘要

按此结构呈现发现：

# 分支上下文：[分支名称]

**基础分支**：[dev/main]
**自偏离以来的提交数**：[数量]
**Linear 工单**：[如果提供则为 ID，否则为"未提供"]

## 意图摘要

[基于提交和变更，用 1-3 句话描述此分支的总体目标]

## 功能区域

### [功能/意图区域 1]
**目的**：[这组变更实现了什么]
**状态**：[完成/进行中/未开始]

**已提交的变更**：
- `路径/到/文件.ext:行号` - [简要描述]
- `路径/到/另一个.ext` - [简要描述]

**未提交的变更**：
- `路径/到/wip.ext` - [简要描述]

### [功能/意图区域 2]
...

## 未提交的工作

**已暂存**（准备提交）：
- [文件列表]

**已修改**（未暂存）：
- [文件列表]

**未跟踪**（新文件）：
- [文件列表]

## 代码与工单的偏离

[如果提供了 Linear 工单，请注明工单描述与代码实际实现之间的任何差异。代码是事实来源。]

## 建议的后续步骤

[基于分析，指出剩余的工作或自然的下一步行动]

代码是事实来源：分支的提交和变更代表了实际正在构建的内容，这可能与原始工单描述不同。
按意图分组，而非结构：不要仅仅按目录列出文件。理解每个变更实现了什么，并将相关的变更分组在一起。
包含文件:行号引用：描述变更时，指向文件中的具体位置，以便用户快速导航。
识别进行中的工作：区分已完成（已提交）的工作和进行中（未提交）的工作。
注意与工单的偏离：如果提供了 Linear 工单，请明确指出实现已超出或与工单描述不同的地方。
简洁但完整：摘要应提供足够的上下文，让某人能够立即开始工作，而不会用所有细节压倒他们。

# 分支上下文：feat/comment-threads

**基础分支**：main
**自偏离以来的提交数**：3
**Linear 工单**：TASK-142

## 意图摘要

此分支为任务添加了线程化评论功能，允许用户在单个任务上开始讨论线程并回复现有评论。实现包括一个新的数据库表、用于 CRUD 操作的 API 路由，以及任务详情视图中的可折叠线程 UI。

## 功能区域

### 评论数据层
**目的**：用于存储和检索评论线程的数据库模式和 API 路由
**状态**：完成

**已提交的变更**：
- `src/db/schema/comments.ts` - 带有用于线程化的 parent_id 的新评论表
- `src/db/migrations/0012_add_comments.sql` - 迁移文件
- `src/api/routes/comments.ts` - 评论的 CRUD 端点

### 线程 UI 组件
**目的**：用于在任务上显示和撰写线程化评论的组件
**状态**：进行中

**已提交的变更**：
- `src/components/tasks/CommentThread.tsx` - 递归线程显示组件

**未提交的变更**：
- `src/components/tasks/CommentComposer.tsx` - 回复/新评论输入框
- `src/hooks/useCommentThread.ts` - 用于线程状态的数据获取钩子

## 代码与工单的偏离

工单将评论范围定义为扁平（非线程化），但实现通过 parent_id 列添加了完整的线程化支持，包括嵌套回复。

## 建议的后续步骤

1. 完成 CommentComposer 组件并将其连接到 CommentThread
2. 向 useCommentThread 添加乐观更新以实现流畅的用户体验
3. 为评论 API 路由添加测试

🇺🇸English

Recover Branch Context

You are tasked with understanding the intent and current state of an existing branch so you can resume or continue work effectively. The code state is your primary source of truth - it may have drifted from any associated Linear ticket.

Initial Response

When this command is invoked, respond with:

I'll help you understand the context of this branch. Let me analyze the commits and changes.

Do you have a Linear ticket ID or URL for this work? (optional - I can proceed without it)

Then wait briefly for the user's response. If they provide a ticket, fetch it. If they say no or don't respond quickly, proceed with the analysis.

Process Steps

Step 1: Determine the Base Branch

Check common base branch names :

git branch -a | grep -E "(main|master|dev|develop)" | head -5

Find the merge base :

# Try dev first (common in this repo), then main/master
git merge-base HEAD dev 2>/dev/null || git merge-base HEAD main 2>/dev/null || git merge-base HEAD master

Get current branch name :
```
git branch --show-current
```

Step 2: Gather Commit History Since Divergence

Get all commits since diverging from base :

git log --oneline $(git merge-base HEAD dev)..HEAD

Get detailed commit messages for understanding intent:

git log --format="%h %s%n%b" $(git merge-base HEAD dev)..HEAD

Get files changed across all commits :

git diff --name-status $(git merge-base HEAD dev)..HEAD

Step 3: Gather Uncommitted Changes

Get staged changes :
```
git diff --name-status --cached
```
Get unstaged changes :
```
git diff --name-status
```

Get untracked files :

git ls-files --others --exclude-standard

Full working tree status :
```
git status --short
```

Step 4: Fetch Linear Ticket (If Provided)

If the user provides a Linear ticket:

Use the mcp__linear__get_issue tool to fetch the ticket details
Note: The ticket represents the original requirements but the code may have evolved

Step 5: Analyze and Group Changes by Intent

CRITICAL : Do not just list files. Group them by logical feature area or intent.

Read key changed files to understand what they do
Identify patterns in the changes:
- New feature additions
- Bug fixes
- Refactoring
- Configuration changes
- Test additions
Group files by their purpose , not by directory

Step 6: Output Summary

Present findings in this structure:

# Branch Context: [branch-name]

**Base branch**: [dev/main]
**Commits since divergence**: [count]
**Linear ticket**: [ID if provided, or "None provided"]

## Intent Summary

[1-3 sentences describing the overall goal of this branch based on commits and changes]

## Feature Areas

### [Feature/Intent Area 1]
**Purpose**: [What this group of changes accomplishes]
**Status**: [Complete/In Progress/Not Started]

**Committed changes**:
- `path/to/file.ext:lines` - [brief description]
- `path/to/another.ext` - [brief description]

**Uncommitted changes**:
- `path/to/wip.ext` - [brief description]

### [Feature/Intent Area 2]
...

## Uncommitted Work

**Staged** (ready to commit):
- [files]

**Modified** (not staged):
- [files]

**Untracked** (new files):
- [files]

## Code vs Ticket Drift

[If a Linear ticket was provided, note any discrepancies between what the ticket describes and what the code actually implements. The code is the source of truth.]

## Suggested Next Steps

[Based on the analysis, what appears to be remaining work or natural next actions]

Important Guidelines

Code is the source of truth : The branch's commits and changes represent what's actually being built, which may differ from the original ticket description.
Group by intent, not structure : Don't just list files by directory. Understand what each change accomplishes and group related changes together.
Include file:line references : When describing changes, point to specific locations in files so the user can quickly navigate.
Identify work-in-progress : Distinguish between completed (committed) work and in-progress (uncommitted) work.
Note drift from ticket : If a Linear ticket was provided, explicitly call out where the implementation has evolved beyond or differs from the ticket description.
Be concise but complete : The summary should give someone enough context to immediately start working, without overwhelming them with every detail.

Example Output

# Branch Context: feat/comment-threads

**Base branch**: main
**Commits since divergence**: 3
**Linear ticket**: TASK-142

## Intent Summary

This branch adds threaded comments to tasks, allowing users to start discussion threads on individual tasks and reply to existing comments. The implementation includes a new database table, API routes for CRUD operations, and a collapsible thread UI in the task detail view.

## Feature Areas

### Comments Data Layer
**Purpose**: Database schema and API routes for storing and retrieving comment threads
**Status**: Complete

**Committed changes**:
- `src/db/schema/comments.ts` - New comments table with parent_id for threading
- `src/db/migrations/0012_add_comments.sql` - Migration file
- `src/api/routes/comments.ts` - CRUD endpoints for comments

### Thread UI Components
**Purpose**: Components for displaying and composing threaded comments on tasks
**Status**: In Progress

**Committed changes**:
- `src/components/tasks/CommentThread.tsx` - Recursive thread display component

**Uncommitted changes**:
- `src/components/tasks/CommentComposer.tsx` - Reply/new comment input box
- `src/hooks/useCommentThread.ts` - Data fetching hook for thread state

## Code vs Ticket Drift

The ticket scoped comments as flat (non-threaded), but the implementation adds full threading support with nested replies via a parent_id column.

## Suggested Next Steps

1. Complete the CommentComposer component and wire it into CommentThread
2. Add optimistic updates to useCommentThread for snappy UX
3. Add tests for the comment API routes

Weekly Installs

112

Repository

casper-studios/…ketplace

GitHub Stars

First Seen

Feb 18, 2026

Security Audits

Gen Agent Trust HubPass SocketPass SnykPass

Installed on

opencode112

codex112

cursor112

claude-code111

windsurf109

github-copilot107

React 组合模式指南：Vercel 组件架构最佳实践，提升代码可维护性

118,000 周安装