Remote repository management made easy
3.7k
Stars
207
Forks
45
Open issues
30
Contributors
AI Analysis
ghq is a command-line tool for organizing and managing clones of remote repositories (GitHub, GitLab, etc.) in a standardized directory structure, similar to how `go get` works. It serves developers and teams who maintain multiple repository clones and need a consistent, navigable file organization system. It is not a replacement for Git itself, but rather a management layer on top of Git for handling repository discovery and local organization.
Inferred from signals mentioned in the README (tests, CI, type safety) — not a review of the actual code.
AI's overall editorial judgment — not an average of the bars above, can weigh other factors too.
Go utility for standardizing remote repository organization across developers and teams
ghq organizes Git/Mercurial/SVN clones under a single root directory using repository URLs as a naming scheme (inspired by Go's package management). It solves the problem of scattered repository clones across developer machines by imposing a consistent directory structure. Adoption appears concentrated among Go developers and terminal-centric workflows, particularly in Japan and among users seeking workspace organization without full monorepo tooling. Real-world adoption is not extensively documented but appears stable in its niche.
ghq was created in 2013 as a lightweight alternative to ad-hoc repository cloning practices. It formalized the Go package management pattern (github.com/user/project) into a general developer workspace tool. The project has maintained steady activity over 13 years with incremental feature additions rather than major rewrites.
The project gained approximately 3,696 stars over 13 years—roughly 284 stars per year, suggesting slow but consistent adoption. Recent activity (13 stars in last 7 days) is typical of mature, stable projects with modest ongoing interest. The growth trajectory suggests the project found a stable niche rather than explosive market adoption. No evidence of viral adoption waves or major enterprise deployment announcements.
Adoption not verified. README and repository metadata provide no case studies, enterprise usage data, or community size metrics. No testimonials, integration documentation with other tools, or industry visibility. The project exists and is maintained, but real-world production adoption scale is undocumented. Moderate GitHub stars (3,696) relative to similar tools suggest existing user base but not dominating the category.
Based on README, ghq is a command-line tool written in Go that wraps VCS operations (git clone, hg clone, svn checkout) and organizes results in host/user/project directories. Likely implements URL parsing, VCS detection, and filesystem operations. Supports multiple root directories, shallow clones, bare clones, and partial clones (blobless/treeless). The design appears intentionally minimal—it delegates actual VCS operations to underlying tools rather than reimplementing them.
README shows CI/CD badge linking to GitHub Actions test workflow and codecov coverage badge, indicating automated testing is in place. Exact coverage percentage not stated in README.
Last push 2026-07-05 (1 day before evaluation date) indicates active maintenance as of analysis time. README is detailed and well-organized. Project is 13 years old with regular updates, suggesting stable long-term maintenance model rather than abandonment risk. Slow growth rate is consistent with a mature, solved problem rather than churn or decline.
ADOPT IF: You work in Go-heavy environments, terminal-first workflows, or multi-machine setups where consistent repository organization reduces context switching and improves discoverability of local clones. You prefer lightweight, Unix-philosophy tools that delegate to system VCS. AVOID IF: You rely on IDE-integrated clone management, monorepo tooling, or complex workspace orchestration. You need enterprise documentation or commercial support. Your workflow involves frequent mass repository operations requiring scripting integration. MONITOR IF: You are evaluating developer productivity tools and want to assess whether standardized repository organization meaningfully reduces friction in your team's workflow before broader adoption.
Independent dimensions
Mainstream potential
3/10
Technical importance
5/10
Adoption evidence
2/10
- Adoption and user base are not documented; unclear how many teams/individuals actually use this in production or whether satisfaction is high.
- Limited to standard VCS operations; cannot replace full monorepo or workspace orchestration platforms if teams grow beyond local clone organization.
- Go-centric history may create perception of being a Go-only tool, even though it works with any VCS and any programming language.
- Depends on presence and configuration of underlying VCS tools (git, hg, svn) on user machines; no bundled VCS implementation.
- Maturity and slow growth may signal the problem space is 'solved well enough' by alternatives (monorepos, IDE cloning, package managers), limiting future adoption runway.
ghq will likely remain a stable, maintained tool for its niche audience (developers who value consistent local repository organization) without achieving mainstream adoption. Expect continued slow growth, occasional feature additions, and low deprecation risk due to simplicity and minimal dependencies.
Explore similar
Newsletter
Get analyses like this every Monday
Free weekly digest of the most interesting open-source discoveries.
Languages
Information
- Language
- Go
- License
- MIT
- Last updated
- 5d ago
- Created
- 163mo ago
- Analyzed with
- anthropic/claude-haiku-4-5
Stars over time
Contributors over time
Top 100 contributors only — repos with more will plateau at 100.
Open issues
feature request: `migrate` should accept multiple repositories
Option to use SCP-style SSH URLs (git@host:path) instead of ssh:// protocol form
Feature request: Support Jujutsu (jj) as a VCS backend
How do I go to the repo after cloning it
Add option to name remote
Top contributors
Similar repos
| Repository | Stars | Week Δ | Language | Score | Updated |
|---|---|---|---|---|---|
|
x-motemen/ghq
this
|
3.7k | +10 | Go | 8/10 | 5d ago |
 gabrie30/ghorg
|
2.1k | — | Go | 7/10 | 6d ago |
 cli/cli
|
45.2k | — | Go | 9/10 | 15h ago |
 lindell/multi-gitter
|
1.2k | — | Go | 8/10 | 13h ago |
 go-git/go-git
|
7.6k | — | Go | 8/10 | 1d ago |
 go-gitea/gitea
|
56.8k | — | Go | 9/10 | 11h ago |
Broader scope—bulk organization of GitHub/GitLab organizations into local directories. ghq is narrower, focused on individual repository management. ghorg appears positioned for DevOps teams; ghq for individual developers.
GitHub's official CLI is much larger in scope and adoption. cli/cli handles authentication, PR/issue management, and workflows. ghq is orthogonal—manages local clones, not remote interactions. Different use cases; not direct competitors.
Targets bulk repository operations and CI/CD workflows across multiple repos. ghq focuses on local organization first. multi-gitter is scripting/automation-oriented; ghq is workspace-organization-oriented.
Low-level Git library for Go. ghq uses (likely) system git rather than go-git. go-git targets library consumers; ghq targets end-user developers.
Most developers still manually organize clones or use ad-hoc scripts. ghq's main advantage is standardization; trade-off is learning a new tool for a solved (if messy) problem.
