Best-Practice Project Structure and Organization


What is the best-practice Project structure to use? Should I use one git repository per package, or a shared one for my whole project?


We suggest to keep the number of Git Repositories as small as possible. In a nutshell:

  • Start with a single Git repository for your whole distribution, where you also maintain the packages you create when kickstarting the project.
  • As soon as you need a package across multiple projects, start to separate them into different git repositories.

(TODO: write some more how the single-git-repository-approach works; i.e. .gitignore and dependencies of embedded packages)

Historic Background

When we started with Flow, many of us created a single Git repository per-package - which however proved quite cumbersome and hard to maintain. That’s why we switched to the different mode only having as little git repositories as possible.

1 Like

You can find some snippets for exluding packages in your Packages folder on

Another example of .gitignore

@christianm / @christopher: you also discussed stuff related to such a setup in a different thread about the Neos site. Last remark of @christianm there is

IMHO it would be important to have a consistent composer.lock AND composer autoload information even if we don’t use it now.

What exactly is the issue with the composer autoload information? As I really don’t see the point of the consistent composer.lock as in the end all dependencies are locked in git including the lock file. So there’s always a consistent state between the composer.lock and package that are just available in the git repository.