With Magento 1 I used a deploy tool that pulled in the GIT repo, ran commands like modman deploy-all and made sure the var directory was writable. For the .gitignore I used this one which worked pretty well.

But what about Magento 2?

What gitignore works best, how do you deploy your project and what command should one run pre- and post deploy. Looking forward to hearing some insights from the community.

Question will stay open for quite some time

  • Good question @sander Mangel – Amit Bera Dec 13 '15 at 18:38
  • 1
    By definition there can be no canonical answer to this, so it is likely too broad and also a poor fit for the Q&A nature of the site. Should likely be meta. But you already know this. That said, I'll allow it until the bounty expires. – philwinkle Dec 16 '15 at 16:59
  • @philwinkle it might be broad but apparently not too broad since already 3 answers were given. As discussed here: meta.magento.stackexchange.com/questions/745/… Meta is to be used for questions about MageSE, not random posts / questions If you want to delete it I can't stop you but it seems a lot of people are interested in the question and in my opinion it's a valid one, all be it not too specific. – Sander Mangel Dec 20 '15 at 10:51
  • Two things: First, Sander is correct about Meta - it should only be used for questions about the SE platform as it relates to Magento SE (NB: we've maybe not policed Meta well enough to reinforce this rule). Second, "a lot of people [being] interested in" a question has nothing to do with whether a question can be answered canonically or not (and therefore with a question's suitability to the StackExchange format). It's frustrating for sure (I've come up against this myself). I'm inclined to see where this Q/A thread goes. Perhaps an A can be stated well enough to be exclusively "right"... – benmarks Dec 21 '15 at 22:12
  • @benmarks in that case I've picked the wrong reason or subject for the bounty, my motivation behind it was to reward whoever took the time to write down a full answer for this. If this thread does not belong on here I'll copy it and post it somewhere online crediting the authors since I feel it still has value. Please notify me if before deleting – Sander Mangel Dec 22 '15 at 7:27
up vote 47 down vote accepted

Steps below describe how to set up environment for custom module development, not for production.

Project initialization

  1. Add repo.magento.com credentials and github access token to auth.json in composer home directory
  2. Create project using the following command:

    composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition .

  3. Take this .gitignore and put into your project root. Almost all core files/directories are already added to the root .gitignore, but it is better to add the following 2 as well /update and /phpserver (just add these 2 lines to .gitignore)

  4. Initialize new git repository in the project root
  5. Add all untracked files to git and commit them
  6. Start development of your modules as usual (put them under app/code/VendorName/ModuleName), now you will have only your custom code in your git repository

Magento installation

  1. Make sure all filesystem permissions are set as outlined in the official guide
  2. Install Magento using command line, e.g.:

    ${project_root}/bin/magento setup:install \ --db-host=localhost \ --db-name=magento \ --db-user=root \ --backend-frontname=admin \ --base-url=http://base.url.goes.here/ \ --language=en_US \ --timezone=America/Chicago \ --currency=USD \ --admin-lastname=Admin \ --admin-firstname=Admin \ --admin-email=admin@example.com \ --admin-user=admin \ --admin-password=123123q \ --cleanup-database \ --use-rewrites=1

  3. Enable indexers cron job, e.g. on Ubuntu:

    echo "* * * * * php ${project_root}/bin/magento cron:run &" | crontab -u www-data -

  4. Magento will run in default mode and all missing content will be auto-generated upon first request. So no need to run compiler or static content deploy
  5. [optional] If using PHP Storm, run the following command in to enable XSD support:

    bin/magento dev:urn-catalog:generate .idea/misc.xml

  • Hi Alex. Project initialization step 3 - could you expand it a bit? Did you find you had to manually copy that subdirectory to the root? (I am wondering if there is something not working correctly - I was not expecting that step.) – Alan Kent Dec 14 '15 at 4:00
  • @AlanKent currently you get all Magento-related files downloaded to vendor, including magento2-base, which is just a skeleton for a new project. Not sure why this step is not configured to be done automatically by composer, will try to find out. Regarding .gitignore copying from another repo, it is already being discussed, how to eliminate/simplify this step. – Alex Paliarush Dec 14 '15 at 6:51
  • Step 3 is not required. The marshaling of the files/folders is done during step 2. – Maddy Dec 14 '15 at 21:11
  • Thanks @Maddy. @AlanKent, copying magento2-base to the root is not necessary anymore (just verified), seems to be fixed recently. Removed this step from the answer. – Alex Paliarush Dec 15 '15 at 10:24
  • 1) i put all of my code on the repo, already unstalled and everything, when i pull from that repo and just change the settings fort the admin pangel and the db credentials, will everything work correctly ? 2) since i forgot to exclude var/ and pub/ folder during the push, can i delete them completely, so they can delete on the remote repo, will they regenerate back ? Thanks. – Lachezar Raychev Feb 19 '16 at 11:03

For Initialisation and Installation follow the steps from Alex his answer for most of the steps, only differences I would recommend:

Git configuration

Only store the following files in your Git repository:

  • composer.json
  • composer.lock
  • app/etc/config.php

For your project custom code, also use separate modules that you include thru composer. Managing this thru composer is easier as you can lock a specific version/release that you want to deploy. This also forces you to use the same approach for internal and external modules.


During development you update the modules on your environment (dev/test) with the command:

composer update

This will update the composer.lock file with the versions installed on that installation.

On staging/pre-production/production you can create/install the same setup with the command:

git pull
composer install

This will install all the same modules as used in dev/test to ensure that the testing before publishing to production is done with the same module versions as it is developed with.

After the installation to run the following commands:

bin/magento setup:upgrade
bin/magento setup:di:compile (or setup:di:compile-multi-tenant)
bin/magento setup:static-content:deploy

This will update the database (schema and data upgrade), generate the DI configuration and deploy all static view files.

  • Maybe it make sense to use sample data instead of generating fixtures? Fixtures populate only the most critical modules and seem to be useful for performance testing only. – Alex Paliarush Dec 14 '15 at 9:28
  • Thanks, removed that part as it's not needed when using a site in production. – Vladimir Kerkhoff Dec 14 '15 at 9:29
  • This follows very closely the approach that I am using as well. This is also working well with Magento 1 as well(with a less complex build process) Let composer do its job, it works for deployments really well in my experience, and we have not seen many downsides other than complexities with .gitignore strategy when you do not follow the smaller footprint in git. – Aepod Dec 14 '15 at 17:24
  • This install looks like the 'integrator' way. It adds the repos in vendor/magento/*. No code will be in app/code/.. and other dirs. How would I have Magento 2 core dirs as in the .zip archive. Is it possible to add via composer a module (other git repo) and than to end up in app/code/... automatically? – obscure Mar 1 '16 at 23:36
  • 4
    risky, composer is not a deployment tool. if something fails on composer install when running in production... – Claudiu Creanga Mar 14 '16 at 15:46

Re .gitignore, 2.2 onwards official Magento answer will be "config.php goes into git, env.php does not".

We are looking at composer plugins like the Mediawiki one to get internal dev closer to extension development and customer sites. Still exploring, not final yet.

I quite liked using the Composer "Path" repository type with a path of ../othergitrepo/app/code/*/* to pick up modules, but it uses symlinks which does not work so well with dev environments using Unison or similar.

we run a different approach which does not involve a separate build-server/process, we locally develop as if in production

we then commit all files necessary for production. we then simply deploy the changesets to the server and run the upgrade command.

getting to a version which is suitable for development but also runs in production mode was the tricky part and is still not perfect but now we got a recipe which works.

the reason is that we want to have 100% control over what code goes into production. since magento2 generates a ton of code we must run it locally to be able to understand all the effects and being able to debug as if in production.

I'm aware that this not what many people recommend to do but for us it works best.

frontend-setup steps

In order for these scripts to work set your shop to production mode in your env.php and setup your theme in dev/tools/grunt/configs/themes.js. (the following steps were put into an ansible playbook)

  1. delete var/cache
  2. delete var/view_preprocessed
  3. delete pub/static/* (don't delete the .htaccess)
  4. delete var/composer_home
  5. run php bin/magento cache:flush
  6. run php bin/magento setup:static-content:deploy %your_languages%
  7. delete all themes/languages you don't actually use from pub/static/frontend
  8. remove hard-copies of less files from pub/static/frontend
  9. run php bin/magento dev:source-theme:deploy --locale="%your_language%" --theme="%your_theme%" css/styles-m css/styles-l css/email css/email-inline
  10. optional: we use a bash-script to change the absolute symlinks, created in step 9, into relative ones, making it possible to run grunt from outside the vm
  11. run grunt less:your_theme

backend/di-setup steps

  1. delete var/cache
  2. delete var/generation
  3. delete var/composer_home
  4. delete var/di
  5. run php bin/magento cache:flush
  6. run php bin/magento setup:di:compile

You should ignore these files too
/.idea/workspace.xml //phpstorm

  • 2
    If you ignore the config.php you will need to enable new extension again after pushing to an other environment, therefore its better to include it in your repository. – Vladimir Kerkhoff Dec 14 '15 at 20:06

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.