golang-standards/project-layout

Standard Go Project Layout

View on GitHub ↗Jump to charts ↓

Summary Information

Updated 4 seconds ago
Added to GitGenius on August 31st, 2026
Created on September 9th, 2017
Open Issues & Pull Requests: 95 (+0)
Number of forks: 5,427
Total Stargazers: 56,516 (+1)
Total Subscribers: 598 (+0)

Repository Insights (GitGenius)

Median issue/PR response: 26.2 days
Mean response time: 273.2 days
90th percentile: 834.8 days
Tracked items: 10

Charts & Analytics

Fetching additional details & charts...

Issue Activity (beta)

Open issues: 13
New in 7 days: 0
Closed in 7 days: 0
Avg open age: 1,046 days
Stale 30+ days: 13
Stale 90+ days: 9

Recent activity

Opened in 7 days: 0
Closed in 7 days: 0
Comments in 7 days: 0
Events in 7 days: 0

Top labels

  • question (1)

Most active issues this week

No issue events were indexed in the last 7 days.

Detailed Description

Standard Go Project Layout is a reference guide for organizing Go application source code directories and files.

The project addresses the problem of inconsistent code organization across Go projects by documenting common historical and emerging layout patterns observed in the Go ecosystem. It provides a high-level structural template showing where to place application code, internal packages, command-line tools, configuration, documentation, and supporting directories. The guide explicitly focuses on general layout rather than deep architectural patterns like Clean Architecture, and it acknowledges that the core Go team provides official guidelines on module organization through the `internal` and `cmd` directory patterns.

Developers should adopt this layout when working on projects large enough to benefit from structured organization, particularly when multiple people contribute or when the code will be imported by other projects. The guide is not suitable for learning Go, proof-of-concept work, or simple single-file projects. It emphasizes that this is not an official standard from the core Go team but rather a collection of community patterns, and developers should clone the repository and keep only the directories and files relevant to their specific needs rather than using every element provided.

The project maintains a repository of layout documentation translated into numerous languages, indicating sustained effort to make the guidance accessible across different developer communities. The repository structure itself serves as a working example of the layout patterns it describes, with supporting directories and files demonstrating the recommended organization in practice.