How to Organize a Multi-File Go Project During Development

By the end of this page, you will understand how Go projects are commonly organized using packages and executable programs, why package main should usually be kept separate from reusable library code, and how to test or run your code during development without reinstalling everything each time.

In Go, project organization is built around packages.

A package is a directory of .go files that all declare the same package name, except for special test files. If you are writing reusable code, that code should usually live in its own package directory such as:

mypack/

Inside that directory, your files might look like this:

// file1.go
package mypack

// file2.go
package mypack

If you also want an executable program that uses that package, that program should normally live in a different directory and use package main.

Why? Because in Go:

• A single directory normally represents one package.
• Files in the same directory must use the same package name.
• package main creates an executable program.
• Other package names create reusable libraries.

So your reusable code and your runnable app are usually separated.

This matters because real Go projects often contain:

• one or more reusable packages
• one or more command-line programs
• test files
• sometimes example programs

A clean structure makes it easier to:

• run code during development
• write tests
• reuse packages in other programs
• keep executable code separate from library logic

Think of a Go package as a toolbox and package main as a worker using the toolbox.

• The toolbox contains reusable tools: functions, types, and methods.
• The worker picks up those tools and uses them to do a job.

You do not usually store the worker inside the toolbox.

In the same way:

• mypack should contain the reusable logic.
• main should live separately and call into mypack.

Tests are like a checklist for the toolbox. They live alongside the toolbox so you can quickly verify that each tool still works.

The key rule is: one directory, one package.

Basic package structure

project-root/
  go.mod
  mypack/
    math.go
    format.go

// mypack/math.go
package mypack

func Add(a, b int) int {
    return a + b
}

// mypack/format.go
package mypack

func Name() string {
    return "mypack"
}

Separate runnable program

project-root/
  go.mod
  mypack/
    math.go
  cmd/
    tryapp/
      main.go

// cmd/tryapp/main.go
package main

import (
    "fmt"
    "project-root/mypack"
)

func main() {
    fmt.Println(mypack.Add(2, ))
}

Consider this project:

project-root/
  go.mod
  mypack/
    greet.go
  cmd/
    tryapp/
      main.go

// mypack/greet.go
package mypack

func Greet(name string) string {
    return "Hello, " + name
}

// cmd/tryapp/main.go
package main

import (
    "fmt"
    "project-root/mypack"
)

func main() {
    message := mypack.Greet("Sam")
    fmt.Println(message)
}

If you run:

go run ./cmd/tryapp

here is what happens:

1. Go finds the main package in ./cmd/tryapp.
2. It sees that main.go imports project-root/mypack.
3. It loads the source files inside the mypack directory.

This package-and-main separation is used in many real Go projects.

Command-line tools

A CLI tool often has:

• reusable logic in internal or package directories
• a small main.go in cmd/toolname

Example:

• parsing files in a package
• calling that package from a CLI command

Web services

A web app may separate:

• HTTP handlers
• business logic
• database access
• executable startup code

The main package sets up the server, while packages contain reusable logic.

SDKs and libraries

If you are building code for reuse by other Go programs, the package should be clean and independent from any particular executable.

Experiments and local demos

During development, many developers create a small runner program to manually try a package without mixing demo code into the package itself.

In real codebases, developers usually avoid putting temporary testing code directly into a library package.

Common patterns include:

Small cmd/... programs

A project may include one or more runnable programs:

cmd/
  api-server/
  worker/
  debug-tool/

Each directory contains a separate main package.

Unit tests for behavior

Instead of manually trying everything through main, developers write tests:

• unit tests for functions
• table-driven tests for multiple cases
• benchmarks for performance-sensitive code

Example programs

Sometimes developers add examples for documentation or learning:

func ExampleAdd() {
    fmt.Println(Add(2, 3))
    // Output: 5
}

Guarding library boundaries

A good library package usually avoids:

• reading command-line flags directly
• printing too much directly to stdout
• hardcoding app-specific behavior

That logic belongs in main or in higher-level application code.

Mixing package main and another package in one directory

This is one of the most common mistakes.

Broken example:

// mypack/file1.go
package mypack

// mypack/trypack.go
package main

This does not work because a directory should not contain files from different packages in normal use.

Using go install as the main development workflow

Beginners sometimes think they must install after every change.

Usually better:

go run ./cmd/tryapp
go test ./...

Use go install when you want the executable installed for repeated use.

Putting too much logic in main

Broken style:

package main

import "fmt"

func main() {
    // all logic here
    fmt.Println( + )
}

go run vs go build vs go install

Core rules

• One directory usually contains one package.
• Reusable code goes in a non-main package.
• Executable code goes in package main.
• Keep main in a separate directory from library code.
• Use *_test.go files for tests.

Common structure

project-root/
  go.mod
  mypack/
    file1.go
    file2.go
    mypack_test.go
  cmd/
    tryapp/
      main.go

Common commands

go run ./cmd/tryapp
go test ./...
go build ./...
go install ./cmd/tryapp

When to use what

• Use go run to quickly execute your app.
• Use go test to test package behavior.
• Use go build to verify compilation.
• Use go install when you want the executable installed.

Remember

• Do not mix package main and package mypack in one directory.
• Import paths come from module paths.

Do I need go install every time I change my Go package?

No. During development, use go run for executable programs and go test for package tests. go install is usually for installing a finished command.

Can I put package main and package mypack in the same folder?

Normally no. Go expects source files in a directory to belong to the same package.

How do I manually try a package while developing it?

Create a small separate program with package main, usually in a directory such as cmd/tryapp, and run it with go run.

Should I test with a manual runner or with go test?

Use both when useful. Manual runners help you experiment, while go test gives repeatable automated checks.

Where should Go test files go?

Usually in the same directory as the package they test, with names ending in _test.go.

What is the purpose of the cmd directory in Go projects?

It is a common convention for storing executable entry points. Each subdirectory usually contains one package.

• Go packages — the core concept behind organizing source files and reusable code.
• package main — used to create executable programs.
• Go modules — define the module path used in imports.
• Go testing — the standard way to verify package behavior.
• Import paths — important for connecting packages correctly.
• go run — useful for quickly executing a main program.
• go build — checks whether code compiles.
• go install — installs executable commands for later use.
• Table-driven tests — a common Go testing style once you start writing more tests.