Beyond GitHub: Andrew Nesbitt's Forge Seeks to Unify the Fragmented World of Git Forges

Andrew Nesbitt has observed a persistent pattern throughout his work in open source infrastructure: equivalent solutions emerge independently across different ecosystems, each solving the same core problem but with subtle, incompatible variations in their interfaces. With Libraries.io and ecosyste.ms he encountered this in package registries; with git-pkgs it appeared in lockfile formats. Now, turning his attention to Git forges, he sees the same fragmentation where GitHub's gh, GitLab's glab, Gitea/Forgejo's tea, and various Bitbucket tools all manage repositories, issues and pull requests yet demand completely different command syntaxes, authentication flows and API mappings. This repetition isn't merely inconvenient—it represents a systemic inefficiency in how open source tooling evolves.

His response is 'forge', a project designed to absorb these differences behind a single consistent interface. Rather than patching existing tools to cover missing features—a approach he tried initially with tea—he built forge from the ground up as both a CLI and a Go module. The CLI automatically detects the forge type from a repository's remote URL (or allows manual override via --forge-type or a .forge file) and presents uniform commands for core operations: forge issue list, forge pr create, forge ci list, and so on. Under the hood, each forge backend implements a common Go interface with services for repositories, issues, pull requests, releases, CI pipelines and more. This allows programmatic use where developers can write code like client.FetchRepository(ctx, url) without conditional logic per provider, while still supporting raw API access via forge api for edge cases.

The authentication system demonstrates thoughtful pragmatism: forge auth login works interactively or via script, accepting tokens from CLI flags, environment variables (honoring existing GITHUB_TOKEN, GITLAB_TOKEN etc.) or config files. All commands support --output json for scripting, addressing a critical need for AI coding agents that increasingly interact with forges programmatically. Nesbitt notes these agents are often hardcoded to GitHub's API, creating lock-in; forge's abstraction lets agent developers target a single interface that works equally well against a self-hosted Forgejo instance or github.com.

This project extends Nesbitt's broader vision seen in ecosyste.ms/repos—a web service providing unified repository metadata—but moves the abstraction layer locally where it can leverage personal authentication tokens. The implications reach beyond convenience: by reducing the cognitive overhead of switching between forge-specific tools, forge lowers the barrier to adopting self-hosted or alternative forges. For organizations, it simplifies internal tooling that must interact with multiple forge instances. Most significantly, as AI agents become more prevalent in development workflows, a forge-agnostic interface prevents the AI ecosystem from becoming unnecessarily tethered to GitHub's proprietary APIs.

Critics might argue that such abstraction layers inevitably leak platform-specific nuances or fail to cover every niche feature—yet Nesbitt's approach acknowledges this by providing the escape hatch of raw API calls. The real value lies not in perfect equivalence but in reducing the friction of common operations to a level where developers can focus on their work rather than forge-specific command memorization. In an era where developer experience increasingly determines tool adoption, forge represents a philosophical stance: that infrastructure should serve the user, not demand constant re-learning of superficial differences. As AI-assisted coding evolves, tools that minimize ecosystem lock-in may prove as valuable as the intelligence they embed.