rcheckout

Recursively check out a git branch across root repository and nested submodules.

2|Updated Apr 24, 2026
One-click install
npx skills add https://github.com/geoyws/atmux --skill rcheckout
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: rcheckout
Source: https://github.com/geoyws/atmux/tree/main/.claude/skills/rcheckout
Command: npx skills add https://github.com/geoyws/atmux --skill rcheckout

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) components.

What problem does it solve?

It eliminates the hassle of manually updating a repository plus deeply nested git submodules so they all land on the same target branch, even when some submodules are on detached HEADs or the branch only exists on the remote.

Core Features & Use Cases

  • Recursive submodule checkout: Switches the root repo and every nested submodule to the provided branch in one operation.
  • Detached HEAD and branch-from-remote handling: Attaches detached HEADs to the target branch and creates the branch from origin/<branch> when needed.
  • Operator-oriented reporting: Produces a summary plus per-repo WARN lines so you can quickly identify what succeeded, what partially failed, and what requires manual intervention.

Quick Start

Tell the Skill to run /rcheckout myteam-alpha-dev to switch the root repo and all nested submodules to myteam-alpha-dev.

Frequently Asked Questions about rcheckout

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I checkout a branch across all git submodules in a monorepo?

To checkout a branch across all git submodules in a monorepo, you can use a recursive checkout script that switches the root repository and every nested submodule to the target branch in a single operation. This aligns deeply nested codebases for coordinated team workflows.

How do I switch a git submodule that is in a detached HEAD state to a specific branch?

Switching a git submodule from a detached HEAD state to a specific branch requires attaching the detached HEAD to the target branch. A recursive checkout tool automates this by creating the branch from origin when it only exists on the remote.

What happens if a submodule branch only exists on the remote origin?

If a submodule branch only exists on the remote origin, the recursive checkout process fetches and creates the local branch from origin/<branch>. This ensures all nested submodules align with the target branch even if it is not yet tracked locally.

How can I identify which submodules failed to switch branches during a recursive checkout?

To identify which submodules failed to switch branches, review the operator-oriented reporting generated by the checkout process. It produces a summary plus per-repo WARN lines indicating what succeeded, partially failed, or requires manual intervention.

Can I checkout all submodules without specifying a branch name?

You cannot checkout all submodules without specifying a branch name, as the branch argument is mandatory. Requiring a specific branch name prevents ambiguous selections based on the .gitmodules file and ensures the correct branch is applied recursively.