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?

  • How to make git-config to use spaces instead of tabs
  • github: Adding commits to existing pull request
  • Git Merge Skipping a commit
  • Discard all changes in Xcode 4.2
  • Automerge issues
  • Concept of git tracking and git staging
  • Git branching / workflow model like “nvie gitflow” but without release branches
  • does git reset delete history?
  • Restoring deleted submodules
  • Force git to add dotfiles to repository
  • git: change one line in file for the complete history
  • Ignoring folder meta files on version control
  • 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.