Cmd folder for organizing project files in Go

I have searched for a solution for organizing Go files in a project and found this post. I wonder what the role of the cmd folder is, that was used in the 2nd section of that post. Is it a magic word for the Go compiler?
On the other hand I was reading the Go documentation and there is nothing about a cmd folder in there.

So what about this folder? And what is the best practice for structuring project files in Go that support source files, projects binaries, 3rd party packages and unit tests.

So what about this 'cmd' folder?

The post has already made it clear, to summarise:
> 1. It's not a magic nor standard in Go. It's just a convention.
> 2. You can have multiple binaries when putting them into a sub-folder which is not possible in the root folder.
> 3. By making you taking your binary as a client instead of a host or portal of your application, it can drives you to the so-called 'library-driven-development' way of architecting your program. This separation 'helps you make a cleaner abstraction' and more common of you code logic.

And what is the best practice for structuring project files in Go that support source files, projects binaries, 3rd party packages and unit tests.

I'm not sure about the best practice. The official documents have many hints about the project files structuring. <del>On my personal practice, besides the cmd folder for the binaries, I

1. Group source files into packages(sub-folders) inside the src folder,
2. Copy 3rd party packages to the vendor folder;
3. Place unit tests files side by side with its target source file.
   </del>

These links may be helpful:

> Organizing Go code
> The Go Blog: Organizing Go code
> The Go Blog: Package names
> golang-standards/project-layout (*)

As @DiegoMendes pointed out, there are controversy about proposals in the last link. You should also check the issue 117 of that repo which contains a lot of valuable information.

The author of the post you cite explicitly says the Camlistore application introduced him to the cmd convention.

If you look at the source code to Camlistore you will notice that project uses a custom system for building, namely "make.go".

cmd is special only because the Camlistore project uses "go run make.go" to build and make.go is aware of how to build targets in the cmd directory. Or in the more general case, cmd is special only if you use a build system that treats it as special.