How can/should Zend Framework 2 be included to a Git versioned project?

How should the version controlling of a Zend Framework 2 project be managed? Is there a best practice / “standard approach” for this? Is “submodule” the right keyword?

  • Cannot get subl command working for ST3 on OSX
  • How do I back up from
  • Moving my SVN local file repo to GitHub
  • How to point Git to use cntlm
  • Git push style deployment for local IIS webserver
  • git-ftp issue: “pathspec '' did not match any file(s) known to git.”
  • Why do you need Gitosis or Gitolite?
  • How do cherry-pick and revert work?
  • sparse checkout gives me an error stderr: fatal: Not a valid object name HEAD
  • Can I add a git remote for all users?
  • Setting up jenkins on centos: problems with ssh keys and git
  • code push to heroku not working
  • One Solution collect form web for “How can/should Zend Framework 2 be included to a Git versioned project?”

    A Zend Framework 2 Project is usually a lightweight skeleton application with various installed modules, which usually are on separate dedicated repositories.

    The main repository isn’t usually affected by many changes, so you can create a git repository (fork of ZendSkeletonApplication) for it. While the modules are more relevant and require some care, the skeleton application usually changes only in a couple details over the months.

    I can suggest following approach:

    1. create your first versions of the app-specific modules as git submodules in the modules/ directory of your skeleton application fork.
    2. work on the modules in the suggested way, by simply committing back to the original repositories and updating the git submodule references in the root repository.
    3. Once you have a fairly well working version (and have some confidence with composer and zf2 in general), you can convert them into composer packages by adding a composer.json file.
    4. Remove the git submodule of the converted zf2 module and use composer to import it instead. To do so, you will simply need to tell composer where the repository is located. This will make the module installable in seconds on any of your applications, helping you in re-using existing components. Re-using code you wrote for different projects becomes really easy from now on.
    5. tag and progressively stabilize dependencies and versions of your packages (because you will start to have your own private composer packages ecosystem)

    This is how I personally do it, and it has turned into a very nice development process. Each time a feature is shared, I simply move it to a new package and update the composer.json in the modules. Satis takes care of the rest, and all our live systems are very fast to upgrade.

    You may want to read some more advanced techniques and tips and tricks about composer once you are familiar with it.

    Git Baby is a git and github fan, let's start git clone.