go-github

go-github is Google’s official Go client library for the GitHub REST API v3. It wraps nearly every documented GitHub endpoint in a typed, service-oriented client, letting Go programs manage repositories, issues, pull requests, Actions workflows, GitHub Apps, organizations, and enterprise administration without hand-rolling HTTP calls or JSON parsing.

The library is built around a single Client whose functionality is grouped into services (Repositories, Issues, PullRequests, Actions, Organizations, and dozens more), each mapping directly to a section of the GitHub REST documentation. Nearly all of the generated request/response types, pagination handling, rate-limit tracking, and boilerplate accessor methods are produced by code generators that run against GitHub’s OpenAPI description, which is why the library can track new GitHub API surface area quickly and consistently.

With over a decade of history and adoption by a huge share of the Go GitHub-tooling ecosystem, it is the de facto standard for talking to GitHub from Go, used everywhere from CI/CD bots and ChatOps tools to GitHub Apps and internal automation.

What You Get

• A Client with dozens of typed services (Repositories, Issues, PullRequests, Actions, Organizations, Apps, Admin, and more) covering essentially the full GitHub REST API surface
• Generated accessor methods (Get*()) for every struct field so callers can safely dereference optional pointer fields without nil-checking boilerplate
• Built-in primary and secondary rate-limit tracking, including automatic backoff handling for GitHub’s secondary rate limits
• First-class pagination support via ListOptions and response NextPage fields, plus helper iterators for looping through paginated results
• Pluggable authentication via WithAuthToken, WithTransport, or WithHTTPClient, compatible with oauth2.Transport and GitHub App installation transports like ghinstallation
• An otel subpackage providing OpenTelemetry instrumentation for outgoing GitHub API calls
• A large example/ directory covering common patterns: basic auth, GitHub App auth, uploading release assets, listing environments, rate-limit handling, and more

Common Use Cases

• CI/CD and release automation - creating releases, uploading release assets, and managing deployment statuses from build pipelines
• GitHub App and bot development - authenticating as an installation and calling the API on behalf of a GitHub App to build ChatOps bots, review bots, or merge-queue tools
• Repository and organization management at scale - scripting bulk changes to repository settings, branch protection rules, teams, and member permissions across many repos
• Actions workflow orchestration - triggering, monitoring, and querying GitHub Actions workflow runs, jobs, and artifacts from external tooling
• Internal developer platforms - building internal tools that surface GitHub issues, pull requests, and code review status inside a company’s own dashboards

Under The Hood

Architecture go-github is organized around one Client struct (github/github.go) that owns an http.Client, base/upload URLs, rate-limit state, and a set of typed “service” structs (RepositoriesService, IssuesService, ActionsService, etc.) that each wrap the shared client to call their slice of the GitHub API. A private common service value is reused across all public services to avoid a heap allocation per service, and every outgoing request funnels through shared NewRequest/Do helpers that centralize JSON encoding, header construction (API version, media types, auth), and response decoding. Domain logic is split into one file per API resource (repos.go, issues.go, actions_workflows.go, apps_hooks.go, and 200+ similarly-scoped files), so changing one API area touches a narrow, predictable slice of the codebase rather than a shared abstraction.

Tech Stack The module (github.com/google/go-github/v90, tracking Go 1.26 per go.mod) has a deliberately minimal dependency footprint: github.com/google/go-querystring for encoding list/filter options into query strings, and github.com/google/go-cmp as a test-only comparison helper. Authentication is left to composition rather than a built-in OAuth implementation — the README documents wiring in golang.org/x/oauth2 or GitHub App installation transports like ghinstallation via the standard http.RoundTripper interface. A separate otel submodule adds OpenTelemetry tracing as an opt-in dependency rather than a core one, and a scrape submodule handles the handful of GitHub features with no public REST endpoint.

Code Quality The repository pairs virtually every implementation file with a same-named _test.go file (roughly 200 test files matching ~206 source files), using Go’s standard testing package plus go-cmp for structural diffs and a local setup(t) helper that spins up an httptest server to assert on HTTP method, headers, and query values per endpoint. CI (.github/workflows/tests.yml, linter.yml) runs the test suite alongside golangci-lint and a “check generated code is up to date” step, and AGENTS.md/CONTRIBUTING.md codify explicit conventions for file organization, JSON tags, and pagination patterns that contributions are expected to follow. Errors are returned as typed *ErrorResponse/*RateLimitError values carrying the underlying HTTP response rather than being swallowed, and a large share of the boilerplate (field accessors, JSON stringifiers) is machine-generated via go:generate directives rather than hand-maintained, reducing the surface for manual mistakes.

API Design The library favors an explicit, discoverable calling convention: client.<Service>.<Method>(ctx, ...) mirrors the shape of the GitHub REST docs almost one-to-one, so users familiar with GitHub’s API can guess method names correctly. Optional/nullable JSON fields are modeled as pointer struct fields with generated Get*() accessors, trading a bit of verbosity for nil-safety without requiring manual nil checks at every call site. Every request-issuing method takes a context.Context as its first argument for cancellation and deadlines, list endpoints share a consistent *ListOptions parameter and paginated-response convention, and construction is centered on a single NewClient(opts ...ClientOptionsFunc) functional-options entry point rather than a sprawling set of constructors, keeping the entry surface small despite the library’s overall size.