Answers.Body: <p>Drush can support VCS deployments and you can tell drush make to keep the .git directory with "drush make --working-copy your-platform.make". However, unless it's changed recently, drush doesn't have post-install hooks, so it won't handle composer/bower/npm well.</p>
  
  <p>Composer has support for "post-install-cmd", but civicrm itself is not on packagist. I'm not familiar enough with composer to comment further, but from experiences so far, I find Composer more interesting than Drush on many many aspects (not CMS-specific, huge community, great tool).</p>
  
  <p>Personally, and this is not an ideal solution: I build platforms (drupal+contrib+civicrm+extensions) using the tar.gz of each project. Extensions/themes that are actively developed get added as git submodules. All my servers use the same git repo (except for site-specific extensions/themes/modules which are in their own repos) and when I do upgrades, I run a git pull everywhere.</p>
  
  <p>The main down side to this is that I cannot cherry-pick patches from upstream, which was the main issue of your question. I usually apply patches manually.</p>
  
  <p>The main issue I had with running upstream git in production, is that this means I have to run composer/bower/npm/gencode on all production servers whenever there is a new version. That has a too high risk of failing (I manage ~ 20 servers, some with a mix of 4.7-D6, 4.7-D7, 4.6-D7, 4.7-WP).</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-09-15T18:46:23.027Z
Answers.LastActivityDate: 2016-09-15T18:46:23.027Z
Answers.UserDisplayName: bgm
Body: <p>First, I know compatibility with Drupal 8 is <a href="https://civicrm.stackexchange.com/questions/4414/">not full yet</a>. There are still open bugs, a bunch of open PRs and an apparent lack of code review.</p>
  
  <p>But let's ignore that for a moment and consider civi d8-ready. I want to do a test install for a migration from Joomla, but also maintain some level of tracking, so it's easier to work with custom changes and any (<em>knock on wood</em>) malicious ones are easier to detect and revert. Looking at various docs, I've found at least these options:</p>
  
  <ul>
  <li>classical install: drupal, civi</li>
  <li>drush: nicely handles downloads, upgrades and backups (no idea if it has VCS support by itself)</li>
  <li>composer: seems to be unofficially preferred for drupal8; not that much info available; more dependency heavy</li>
  <li>civi-buildkit: seems like a complete overkill, as I don't need a full development environment</li>
  </ul>
  
  <p>All of them can be preceded by initing a blank git repo and manually tracking from there. The buildkit is already fully based on git. <strong>Can any of</strong> the others track upstream automatically, to avoid the need for manual commits-on-update and working with tarballs? Did I forget an even better option, some combination?</p>
  
Tags: <drupal><civicrm-buildkit><drush><drupal-8><deployment>
Title: What's the optimal way to install and track CiviCRM with Drupal and git?
ThreadText: # What's the optimal way to install and track CiviCRM with Drupal and git?
  
  (Asked by: username_0 on 2016-09-13)
  
  First, I know compatibility with Drupal 8 is [not full yet](https://civicrm.stackexchange.com/questions/4414/). There are still open bugs, a bunch of open PRs and an apparent lack of code review.
  
  But let's ignore that for a moment and consider civi d8-ready. I want to do a test install for a migration from Joomla, but also maintain some level of tracking, so it's easier to work with custom changes and any (*knock on wood*) malicious ones are easier to detect and revert. Looking at various docs, I've found at least these options:
  
  * classical install: drupal, civi
  * drush: nicely handles downloads, upgrades and backups (no idea if it has VCS support by itself)
  * composer: seems to be unofficially preferred for drupal8; not that much info available; more dependency heavy
  * civi-buildkit: seems like a complete overkill, as I don't need a full development environment
  
  All of them can be preceded by initing a blank git repo and manually tracking from there. The buildkit is already fully based on git. **Can any of** the others track upstream automatically, to avoid the need for manual commits-on-update and working with tarballs? Did I forget an even better option, some combination?
  
  **Tags:** drupal, civicrm-buildkit, drush, drupal-8, deployment
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2016-09-15. Score: 2 | Accepted answer
  
  Drush can support VCS deployments and you can tell drush make to keep the .git directory with "drush make --working-copy your-platform.make". However, unless it's changed recently, drush doesn't have post-install hooks, so it won't handle composer/bower/npm well.
  
  Composer has support for "post-install-cmd", but civicrm itself is not on packagist. I'm not familiar enough with composer to comment further, but from experiences so far, I find Composer more interesting than Drush on many many aspects (not CMS-specific, huge community, great tool).
  
  Personally, and this is not an ideal solution: I build platforms (drupal+contrib+civicrm+extensions) using the tar.gz of each project. Extensions/themes that are actively developed get added as git submodules. All my servers use the same git repo (except for site-specific extensions/themes/modules which are in their own repos) and when I do upgrades, I run a git pull everywhere.
  
  The main down side to this is that I cannot cherry-pick patches from upstream, which was the main issue of your question. I usually apply patches manually.
  
  The main issue I had with running upstream git in production, is that this means I have to run composer/bower/npm/gencode on all production servers whenever there is a new version. That has a too high risk of failing (I manage ~ 20 servers, some with a mix of 4.7-D6, 4.7-D7, 4.6-D7, 4.7-WP).
  
  
  ---
  
  