git%3Amerge-worktree by neolabhq/context-engineering-kit
npx skills add https://github.com/neolabhq/context-engineering-kit --skill git:merge-worktree你的任务是帮助用户将 git 工作树中的更改合并到当前分支,支持从简单的文件检出到选择性拣选等多种合并策略。
关键:严格按照以下步骤执行:
检查当前状态:运行 git worktree list 显示所有现有工作树,运行 git status 验证工作目录状态。
解析用户输入:确定用户想要执行哪种合并操作:
* **`--interactive` 或无参数**:引导式交互模式。
* **文件/目录路径**:从工作树合并特定文件或目录。
* **提交名称**:拣选特定提交。
* **分支名称**:从该分支的工作树合并。
* **`--from<worktree>`**:显式指定源工作树。
* **`--patch` 或 `-p`**:使用交互式补丁选择模式。
3. 确定源工作树/分支:
a. 如果用户指定了 --from <worktree>:直接使用该工作树路径。
b. 如果用户指定了分支名:从 git worktree list 中查找该分支对应的工作树。
c. 如果只存在一个其他工作树:询问用户是否确认将其作为源。
d. 如果存在多个工作树:提供列表并询问用户从哪个工作树合并。
e. 如果没有其他工作树:解释情况并提供使用基于分支的合并作为替代方案。
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
策略 A:选择性文件检出(适用于特定文件/目录)
* 最佳场景:从另一个分支获取完整的文件。
* 命令:`git checkout <branch> -- <path>`
策略 B:交互式补丁选择(适用于文件的部分更改)
* 最佳场景:从文件中选择特定的代码块/行。
* 命令:`git checkout -p <branch> -- <path>`
* 对每个代码块提示用户:y(应用)、n(跳过)、s(拆分)、e(编辑)。
策略 C:带选择性暂存的拣选(适用于特定提交)
* 最佳场景:应用一个提交但排除其部分更改。
* 步骤:
1. `git cherry-pick --no-commit <commit>`
2. 查看暂存的更改。
3. `git reset HEAD -- <unwanted-files>` 取消暂存不需要的文件。
4. `git checkout -- <unwanted-files>` 丢弃不需要文件的更改。
5. `git commit -m "message"`
策略 D:手动合并(含冲突处理)(适用于复杂合并)
* 最佳场景:完整的分支合并,同时能控制解决过程。
* 步骤:
1. `git merge --no-commit <branch>`
2. 查看所有更改。
3. 选择性地暂存/取消暂存文件。
4. 如有冲突,则解决之。
5. `git commit -m "message"`
策略 E:多工作树选择性合并(从多个源合并)
* 最佳场景:从不同工作树获取不同的文件。
* 步骤:
1. `git checkout <branch1> -- <path1>`
2. `git checkout <branch2> -- <path2>`
3. `git commit -m "Merge selected files from multiple branches"`
5. 执行选定的策略:
* 如果用户希望审查,则运行合并前比较(建议先使用 `/git:compare-worktrees`)。
* 为所选策略执行 git 命令。
* 处理出现的任何冲突。
* 在最终提交前确认更改。
6. 合并后摘要:显示已合并的内容:
* 已更改/添加/删除的文件。
* 源工作树/分支。
* 使用的合并策略。
7. 清理提示:成功合并后,询问:
* “您想移除任何工作树以清理本地状态吗?”
* 如果回答是:列出工作树并询问要移除哪个。
* 为选定的工作树执行 `git worktree remove <path>`。
* 如果需要,提醒使用 `git worktree prune`。
| 策略 | 适用场景 | 命令模式 |
|---|---|---|
| 选择性文件 | 需要来自另一个分支的完整文件 | git checkout <branch> -- <path> |
| 交互式补丁 | 需要文件内的特定更改 | git checkout -p <branch> -- <path> |
| 选择性拣选 | 需要一个提交但非其所有更改 | git cherry-pick --no-commit + 选择性暂存 |
| 手动合并 | 需要控制权的完整分支合并 | git merge --no-commit + 选择性暂存 |
| 多源合并 | 组合来自多个分支的文件 | 多个 git checkout <branch> -- <path> |
从工作树合并单个文件:
> /git:merge-worktree src/app.js --from ../project-feature
# 提示选择合并策略
# 执行:git checkout feature-branch -- src/app.js
交互式补丁选择:
> /git:merge-worktree src/utils.js --patch
# 列出可用的工作树供选择
# 运行:git checkout -p feature-branch -- src/utils.js
# 用户交互式选择代码块(y/n/s/e)
拣选特定提交:
> /git:merge-worktree abc1234
# 检测到提交哈希
# 询问:应用整个提交还是选择性应用?
# 如果选择性:git cherry-pick --no-commit abc1234
# 然后引导取消暂存不需要的更改
从多个工作树合并:
> /git:merge-worktree --interactive
# "选择要从不同工作树合并的文件:"
# "从 feature-1:src/moduleA.js"
# "从 feature-2:src/moduleB.js, src/moduleC.js"
# 执行从每个工作树的选择性检出
完整引导模式:
> /git:merge-worktree
# 列出所有工作树
# 询问要合并什么(文件、提交或分支)
# 引导选择合适的策略
# 最后提供清理选项
目录合并(含冲突):
> /git:merge-worktree src/components/ --from ../project-refactor
# 策略 D:手动合并(含冲突)
# git merge --no-commit refactor-branch
# 帮助解决任何冲突
# 审查并提交选定的更改
当使用 --patch 或策略 B 时,用户会看到每个更改代码块的提示:
@@ -10,6 +10,8 @@ function processData(input) {
const result = transform(input);
+ // 添加了验证
+ if (!isValid(result)) throw new Error('Invalid');
return result;
}
Apply this hunk? [y,n,q,a,d,s,e,?]
| 按键 | 操作 |
|---|---|
y | 应用此代码块 |
n | 跳过此代码块 |
q | 退出(不应用此代码块及剩余代码块) |
a | 应用此代码块及所有剩余代码块 |
d | 不应用此代码块及此文件中剩余代码块 |
s | 拆分为更小的代码块 |
e | 手动编辑此代码块 |
? | 显示帮助 |
对于策略 C(带选择性暂存的拣选):
# 1. 应用提交但不提交
git cherry-pick --no-commit abc1234
# 2. 检查暂存了哪些内容
git status
# 3. 取消暂存您不想要的文件
git reset HEAD -- path/to/unwanted.js
# 4. 丢弃对这些文件的更改
git checkout -- path/to/unwanted.js
# 5. 提交剩余的更改
git commit -m "Cherry-pick selected changes from abc1234"
对于策略 E(从多个工作树合并):
# 从不同分支获取文件
git checkout feature-auth -- src/auth/login.js src/auth/session.js
git checkout feature-api -- src/api/endpoints.js
git checkout feature-ui -- src/components/Header.js
# 审查所有更改
git status
git diff --cached
# 提交组合的更改
git commit -m "feat: combine auth, API, and UI improvements from feature branches"
> /git:merge-worktree src/new-feature.js --from ../project-feature
# 仅获取该文件,而非整个分支
> /git:merge-worktree --patch src/utils.js --from ../project-hotfix
# 仅选择特定的错误修复代码块,而非所有更改
> /git:merge-worktree --interactive
# 从 PR-1 工作树选择特定文件
# 从 PR-2 工作树选择其他文件
# 组合成单个连贯的提交
# 首先审查将要合并的内容
> /git:compare-worktrees src/module.js
# 然后放心地合并
> /git:merge-worktree src/module.js --from ../project-feature
工作目录状态:在合并前,务必确保您的工作目录是干净的。未提交的更改可能导致冲突。
合并前审查:考虑在合并前使用 /git:compare-worktrees 来了解将应用哪些更改。
冲突解决:如果在合并过程中发生冲突,该命令将帮助识别并在提交前解决它们。
无提交标志:大多数策略使用 --no-commit,以便您能控制最终的提交消息和包含的内容。
共享仓库:所有工作树共享同一个 Git 对象数据库,因此在任何工作树中进行的提交都可以立即从其他任何工作树中拣选。
分支锁定:请记住,一个分支一次只能在一个工作树中检出。对于合并操作,请使用分支名,而不是创建重复的工作树。
合并后,请考虑清理不再需要的工作树:
# 列出工作树
git worktree list
# 移除特定工作树(需要干净状态)
git worktree remove ../project-feature
# 强制移除(丢弃未提交的更改)
git worktree remove --force ../project-feature
# 清理过时的工作树引用
git worktree prune
该命令将在每次成功合并后提示您进行清理,以帮助保持工作空间整洁。
“无法合并:工作目录有未提交的更改”
git stash,合并后使用 git stash pop。“<文件> 中存在合并冲突”
<<<<<<< 标记)。git add <文件> 暂存已解决的文件。git commit。拣选时“未找到提交”
git log <分支> 以查找提交。“无法检出:文件已存在于工作树中”
“未找到工作树对应的分支”
git worktree list 查看当前工作树。git worktree prune 清理过时的引用。合并前审查:
> /git:compare-worktrees src/
> /git:merge-worktree src/specific-file.js
创建工作树、合并、清理:
> /git:create-worktree feature-branch
> /git:compare-worktrees src/
> /git:merge-worktree src/module.js --from ../project-feature-branch
# 合并后,会自动提供清理选项
每周安装量
220
代码仓库
GitHub 星标数
699
首次出现
2026年2月19日
安装于
opencode214
github-copilot213
codex213
gemini-cli212
kimi-cli210
amp210
Your job is to help users merge changes from git worktrees into their current branch, supporting multiple merge strategies from simple file checkout to selective cherry-picking.
CRITICAL: Perform the following steps exactly as described:
Current state check : Run git worktree list to show all existing worktrees and git status to verify working directory state
Parse user input : Determine what merge operation the user wants:
--interactive or no arguments: Guided interactive mode--from<worktree>: Specify source worktree explicitly--patch or -p: Use interactive patch selection modeDetermine source worktree/branch : a. If user specified --from <worktree>: Use that worktree path directly b. If user specified a branch name: Find worktree for that branch from git worktree list c. If only one other worktree exists: Ask to confirm using it as source d. If multiple worktrees exist: Present list and ask user which to merge from e. If no other worktrees exist: Explain and offer to use branch-based merge instead
Determine merge strategy : Present options based on user's needs:
Strategy A: Selective File Checkout (for specific files/directories)
* Best for: Getting complete file(s) from another branch
* Command: `git checkout <branch> -- <path>`
Strategy B: Interactive Patch Selection (for partial file changes)
* Best for: Selecting specific hunks/lines from a file
* Command: `git checkout -p <branch> -- <path>`
* Prompts user for each hunk: y (apply), n (skip), s (split), e (edit)
Strategy C: Cherry-Pick with Selective Staging (for specific commits)
* Best for: Applying a commit but excluding some changes
* Steps:
1. `git cherry-pick --no-commit <commit>`
2. Review staged changes
3. `git reset HEAD -- <unwanted-files>` to unstage
4. `git checkout -- <unwanted-files>` to discard
5. `git commit -m "message"`
Strategy D: Manual Merge with Conflicts (for complex merges)
* Best for: Full branch merge with control over resolution
* Steps:
1. `git merge --no-commit <branch>`
2. Review all changes
3. Selectively stage/unstage files
4. Resolve conflicts if any
5. `git commit -m "message"`
Strategy E: Multi-Worktree Selective Merge (combining from multiple sources)
* Best for: Taking different files from different worktrees
* Steps:
1. `git checkout <branch1> -- <path1>`
2. `git checkout <branch2> -- <path2>`
3. `git commit -m "Merge selected files from multiple branches"`
5. Execute the selected strategy :
* Run pre-merge comparison if user wants to review (suggest `/git:compare-worktrees` first)
* Execute git commands for the chosen strategy
* Handle any conflicts that arise
* Confirm changes before final commit
6. Post-merge summary : Display what was merged:
* Files changed/added/removed
* Source worktree/branch
* Merge strategy used
7. Cleanup prompt : After successful merge, ask:
* "Would you like to remove any worktrees to clean up local state?"
* If yes: List worktrees and ask which to remove
* Execute `git worktree remove <path>` for selected worktrees
* Remind about `git worktree prune` if needed
| Strategy | Use When | Command Pattern |
|---|---|---|
| Selective File | Need complete file(s) from another branch | git checkout <branch> -- <path> |
| Interactive Patch | Need specific changes within a file | git checkout -p <branch> -- <path> |
| Cherry-Pick Selective | Need a commit but not all its changes | git cherry-pick --no-commit + selective staging |
| Manual Merge | Full branch merge with control | git merge --no-commit + selective staging |
Merge single file from worktree:
> /git:merge-worktree src/app.js --from ../project-feature
# Prompts for merge strategy
# Executes: git checkout feature-branch -- src/app.js
Interactive patch selection:
> /git:merge-worktree src/utils.js --patch
# Lists available worktrees to select from
# Runs: git checkout -p feature-branch -- src/utils.js
# User selects hunks interactively (y/n/s/e)
Cherry-pick specific commit:
> /git:merge-worktree abc1234
# Detects commit hash
# Asks: Apply entire commit or selective?
# If selective: git cherry-pick --no-commit abc1234
# Then guides through unstaging unwanted changes
Merge from multiple worktrees:
> /git:merge-worktree --interactive
# "Select files to merge from different worktrees:"
# "From feature-1: src/moduleA.js"
# "From feature-2: src/moduleB.js, src/moduleC.js"
# Executes selective checkouts from each
Full guided mode:
> /git:merge-worktree
# Lists all worktrees
# Asks what to merge (files, commits, or branches)
# Guides through appropriate strategy
# Offers cleanup at end
Directory merge with conflicts:
> /git:merge-worktree src/components/ --from ../project-refactor
# Strategy D: Manual merge with conflicts
# git merge --no-commit refactor-branch
# Helps resolve any conflicts
# Reviews and commits selected changes
When using --patch or Strategy B, the user sees prompts for each change hunk:
@@ -10,6 +10,8 @@ function processData(input) {
const result = transform(input);
+ // Added validation
+ if (!isValid(result)) throw new Error('Invalid');
return result;
}
Apply this hunk? [y,n,q,a,d,s,e,?]
| Key | Action |
|---|---|
y | Apply this hunk |
n | Skip this hunk |
q | Quit (don't apply this or remaining hunks) |
a | Apply this and all remaining hunks |
d | Don't apply this or remaining hunks in this file |
s | Split into smaller hunks |
For Strategy C (cherry-picking with selective staging):
# 1. Apply commit without committing
git cherry-pick --no-commit abc1234
# 2. Check what was staged
git status
# 3. Unstage files you don't want
git reset HEAD -- path/to/unwanted.js
# 4. Discard changes to those files
git checkout -- path/to/unwanted.js
# 5. Commit the remaining changes
git commit -m "Cherry-pick selected changes from abc1234"
For Strategy E (merging from multiple worktrees):
# Get files from different branches
git checkout feature-auth -- src/auth/login.js src/auth/session.js
git checkout feature-api -- src/api/endpoints.js
git checkout feature-ui -- src/components/Header.js
# Review all changes
git status
git diff --cached
# Commit combined changes
git commit -m "feat: combine auth, API, and UI improvements from feature branches"
> /git:merge-worktree src/new-feature.js --from ../project-feature
# Gets just the file, not the entire branch
> /git:merge-worktree --patch src/utils.js --from ../project-hotfix
# Select only the specific bug fix hunks, not all changes
> /git:merge-worktree --interactive
# Select specific files from PR-1 worktree
# Select other files from PR-2 worktree
# Combine into single coherent commit
# First review what will be merged
> /git:compare-worktrees src/module.js
# Then merge with confidence
> /git:merge-worktree src/module.js --from ../project-feature
Working directory state : Always ensure your working directory is clean before merging. Uncommitted changes can cause conflicts.
Pre-merge review : Consider using /git:compare-worktrees before merging to understand what changes will be applied.
Conflict resolution : If conflicts occur during merge, the command will help identify and resolve them before committing.
No-commit flag : Most strategies use --no-commit to give you control over the final commit message and what gets included.
Shared repository : All worktrees share the same Git object database, so commits made in any worktree are immediately visible to cherry-pick from any other.
Branch locks : Remember that branches can only be checked out in one worktree at a time. Use branch names for merge operations rather than creating duplicate worktrees.
After merging, consider cleaning up worktrees that are no longer needed:
# List worktrees
git worktree list
# Remove specific worktree (clean state required)
git worktree remove ../project-feature
# Force remove (discards uncommitted changes)
git worktree remove --force ../project-feature
# Clean up stale worktree references
git worktree prune
The command will prompt you about cleanup after each successful merge to help maintain a tidy workspace.
"Cannot merge: working directory has uncommitted changes"
git stash before merge, git stash pop after"Merge conflict in "
<<<<<<< markers)git add <file>git commit"Commit not found" when cherry-picking
git log <branch> in any worktree to find commits"Cannot checkout: file exists in working tree"
"Branch not found for worktree"
git worktree list to see current worktreesgit worktree prune to clean up stale referencesPre-merge review:
> /git:compare-worktrees src/
> /git:merge-worktree src/specific-file.js
Create worktree, merge, cleanup:
> /git:create-worktree feature-branch
> /git:compare-worktrees src/
> /git:merge-worktree src/module.js --from ../project-feature-branch
# After merge, cleanup is offered automatically
Weekly Installs
220
Repository
GitHub Stars
699
First Seen
Feb 19, 2026
Installed on
opencode214
github-copilot213
codex213
gemini-cli212
kimi-cli210
amp210
React 组合模式指南:Vercel 组件架构最佳实践,提升代码可维护性
109,600 周安装
| Multi-Source | Combining files from multiple branches | Multiple git checkout <branch> -- <path> |
e| Manually edit the hunk |
? | Show help |