3

I would like to install/manage Drupal with Git, Drush, and configuration synchronization.

Should I add core/ and vendor/ into the .gitignore so that instead of pushing/pulling core I simply update core on prod/dev and synchronize configuration only?

This way I could potentially manage a Drupal site with few repositories:

  • Repository for configurations
  • Repository for a custom theme
  • Repository for custom modules

When updating a module, this would be my workflow.

On development

  1. git pull
  2. drush up
  3. drush config-export to-prod
  4. git push

On production

  1. git pull
  2. drush up
  3. drush config-import to-prod

I ask because it doesn't seem to make sense that I have to push/pull all of Drupal 8 with every update.

  • Why wouldn't you want to use composer? Isn't that the reason for its popularity? I even hear it is better than the equivalent tools for java, ruby and other languages – Cesar Moore Sep 7 '18 at 21:04
  • This isn’t a good workflow. Doing drush up will change the state of your repo in unexpected ways - this is precisely why you’d use Composer. Look at deployment workflows. – Kevin Sep 8 '18 at 11:33
  • @CesarMoore I had a rough start with composer updating from 8.3 to 8.5. Apart from that it's been a treat, but I am worried about difficult updates for large production apps. I'll have to see if this has improved as many seem to suggest that composer is the way forward. – ymdahi Sep 10 '18 at 0:19
  • Related: drupal.stackexchange.com/q/254407 – leymannx Mar 24 '19 at 16:30
7

If your goal is to minimize the size of your repository, then you should use Composer, following the pattern described in the project drupal-composer/drupal-project.

One possible workflow would then be:

On dev:

  1. git pull
  2. composer install
  3. drush config-export
  4. git add / commit / push

On stage:

  1. git pull
  2. composer install
  3. drush config-import

On live:

  1. rsync from stage to live
  2. drush config-import

The workflow you propose will not work. The command drush pm-update will not do anything if Drupal is already at the most recent version. drush pm-download is not a good alternative either, as it will overwrite portions of your code base. You could potentially repair this with a git reset --hard or some similar trick, but that would not be very clean.

If you do not wish to use Composer, your best option is to simply commit the core and vendor directories.

  • Thanks for the suggestion, I'll read up on the link provided. I should have clarified that I have hesitations for using composer due to difficulties I ran into upgrading from 8.3 to 8.5 and the recent two drupalgeddons. I'm trying to replicate my D7 approach which omits drupal core, which is kept updated via git (origin d.org), and drush up on module updates. While custom code is from my own repos. – ymdahi Sep 10 '18 at 0:25
2

I ask because it doesn't seem to make sense that I have to push/pull all of Drupal 8 with every update.

The whole point of Git is that it’s incremental. It only pulls and pushes what has changed, the differences.

If you modify a file, it only needs to send the differences. That’s what’s stored in a commit. Not the full file again.

  • Thanks for pointing out that typo. I meant: "push/pull all of drupal 8 each time I init a project based". This isn't the biggest issue, but the number of files does become a factor on a 5400rpm hdd :/ – ymdahi Sep 10 '18 at 0:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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