Best-Practice Project Structure and Organization

(Sebastian Kurfuerst) #1


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.

Why are some packages installed inside Application, others inside Framework or Library?
(Rens Admiraal) #2

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

(Aske Ertmann) #3

Another example of .gitignore

(Rens Admiraal) #4

@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.