How to Create and Store a Symfony Project in Git

How to Create and Store a Symfony Project in Git


Though this entry is specifically about Git, the same generic principles will apply if you're storing your project in Subversion.

Once you've read through Creating Pages in Symfony and become familiar with using Symfony, you'll no-doubt be ready to start your own project. In this cookbook article, you'll learn the best way to start a new Symfony project that's stored using the Git source control management system.

Initial Project Setup

To get started, you'll need to download Symfony and initialize your local git repository:

  1. Download the Symfony Standard Edition using Composer:

    $ php composer.phar create-project symfony/framework-standard-edition path/ '~2.3'

    Composer will now download the Standard Distribution along with all of the required vendor libraries. For more information about downloading Symfony using Composer, see Installing Symfony using Composer.

  2. Initialize your Git repository:

    $ git init
  3. Add all of the initial files to Git:

    $ git add .


    As you might have noticed, not all files that were downloaded by Composer in step 1, have been staged for commit by Git. Certain files and folders, such as the project's dependencies (which are managed by Composer), parameters.yml (which contains sensitive information such as database credentials), log and cache files and dumped assets (which are created automatically by your project), should not be committed in Git. To help you prevent committing those files and folders by accident, the Standard Distribution comes with a file called .gitignore, which contains a list of files and folders that Git should ignore.


    You may also want to create a .gitignore file that can be used system-wide. This allows you to exclude files/folders for all your projects that are created by your IDE or operating system. For details, see GitHub .gitignore.

  4. Create an initial commit with your started project:

    $ git commit -m "Initial commit"

At this point, you have a fully-functional Symfony project that's correctly committed to Git. You can immediately begin development, committing the new changes to your Git repository.

You can continue to follow along with the Creating Pages in Symfony chapter to learn more about how to configure and develop inside your application.


The Symfony Standard Edition comes with some example functionality. To remove the sample code, follow the instructions in the "How to Remove the AcmeDemoBundle" article.

Managing Vendor Libraries with composer.json

How Does it Work?

Every Symfony project uses a group of third-party "vendor" libraries. One way or another the goal is to download these files into your vendor/ directory and, ideally, to give you some sane way to manage the exact version you need for each.

By default, these libraries are downloaded by running a php composer.phar install "downloader" binary. This composer.phar file is from a library called Composer and you can read more about installing it in the Installation chapter.

The composer.phar file reads from the composer.json file at the root of your project. This is an JSON-formatted file, which holds a list of each of the external packages you need, the version to be downloaded and more. The composer.phar file also reads from a composer.lock file, which allows you to pin each library to an exact version. In fact, if a composer.lock file exists, the versions inside will override those in composer.json. To upgrade your libraries to new versions, run php composer.phar update.


If you want to add a new package to your application, modify the composer.json file:

    "require": {
        "doctrine/doctrine-fixtures-bundle": "@dev"

and then execute the update command for this specific package, i.e.:

$ php composer.phar update doctrine/doctrine-fixtures-bundle

You can also combine both steps into a single command:

$ php composer.phar require doctrine/doctrine-fixtures-bundle:@dev

To learn more about Composer, see

It's important to realize that these vendor libraries are not actually part of your repository. Instead, they're simply un-tracked files that are downloaded into the vendor/. But since all the information needed to download these files is saved in composer.json and composer.lock (which are stored in the repository), any other developer can use the project, run php composer.phar install, and download the exact same set of vendor libraries. This means that you're controlling exactly what each vendor library looks like, without needing to actually commit them to your repository.

So, whenever a developer uses your project, they should run the php composer.phar install script to ensure that all of the needed vendor libraries are downloaded.

Since Symfony is just a group of third-party libraries and third-party libraries are entirely controlled through composer.json and composer.lock, upgrading Symfony means simply upgrading each of these files to match their state in the latest Symfony Standard Edition.

Of course, if you've added new entries to composer.json, be sure to replace only the original parts (i.e. be sure not to also delete any of your custom entries).

Vendors and Submodules

Instead of using the composer.json system for managing your vendor libraries, you may instead choose to use native git submodules. There is nothing wrong with this approach, though the composer.json system is the official way to solve this problem and probably much easier to deal with. Unlike Git submodules, Composer is smart enough to calculate which libraries depend on which other libraries.

Storing your Project on a remote Server

You now have a fully-functional Symfony project stored in Git. However, in most cases, you'll also want to store your project on a remote server both for backup purposes, and so that other developers can collaborate on the project.

The easiest way to store your project on a remote server is via a web-based hosting service like GitHub or Bitbucket. Of course, there are more services out there, you can start your research with a comparison of hosting services.

Alternatively, you can store your Git repository on any server by creating a barebones repository and then pushing to it. One library that helps manage this is Gitolite.

This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License .