By ericxb on

With regard to the excellent document Building a Drupal site with Git, I have several questions about how this translates to Drupal 8; so I'm posting each as a separate topic.

When following the best-practice outlined in Building a Drupal site with Git, one ends up with two git remotes: the drupal one with all the core code and your own, fooproject, encompassing drupal core along with your site adds. Both git trees are rooted in the same folder.

[fooproject_dev] a.k.a [core]
   |------[.git] remote drupal & remote fooproject
   |------[sites]

Given that the best practice for exporting/importing d8 configurations is to specify a `config` directory outside the drupal tree; we now want to include the parent directory (with its config tree) in fooproject. I would assume from what I've read about git, that splitting the tree into two is possible but fraught with confusing pain for those less initiated. 

[fooproject_dev]
   |------[.git] remote fooproject
   |------[config]
   |------[drupal core]
              |------[.git] remote drupal
              |------[sites]

Can the above be combined into a single .git?
How would one perform such git magic?

⋅ Categories: Drupal 8.x

Comments

John_B’s picture

John_B commented

It is a good question. You can read about workflow in D8 in various places, for example here and here and here. I think that the unspoken assumption behind all those discussions, is that after an initial git clone, no further code is taken from git.drupal.org and updates and installing contributed modules will be done with drush, not git, and committed to your site repository.

From the last link above, also note

Because the configuration management of Drupal 8 only works between different instances of the same site, the different instances of the site need to be cloned.

[i.e. cloned from your own site repository] The idea in that documentation page of using git fetch for Drupal core updates does not seem very pragmatic, especially once the site has a lot of contributed code. However, I hesitate to edit that documentation page you link without running this question past others first (you are more likely to find core devs on IRC than here), though if this becomes clearer to you, maybe you will edit it.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

ericxb’s picture

ericxb commented

Thanks.

I have a problem with the idea that one must abandon the git feed after the initial deployment.

I think for the time being; I will customize the config dir to contain from_dev, from_stage, and ~maybe~ from_prod (might just suppress the option to change config on the production sites). And do something to obfuscate the path and perhaps add something to the httpd conf to prevent direct access but leave the config dir within the Drupal tree simply to obviate the git confusion.

I'll post something on StackExchange about this git issue and see what I can find there.

ericxb’s picture

ericxb commented

Amazee Labs - git submodule cookbook

ericxb’s picture

ericxb commented

I hope that someone with better git skills than I can look this over. However, if this seems reasonable, I will happily perform the legwork to update Building a Drupal Site with Git.

This uses git subtree

  • On your central repository machine, create a bare repository:
    git init --bare --shared fooproject
    Initialized empty shared Git repository in /usr/local/var/gitroot/fooproject/
  • On your working machine, initiate dev repository by pulling down the empty tree:
    git clone ssh://ada_lovelace@git.dev.net/usr/local/var/gitroot/fooproject d8_fooproject_dev
    Cloning into 'd8_fooproject_dev'...
    warning: You appear to have cloned an empty repository.
    Checking connectivity...
    done.
  • Create a working branch:
    cd d8_fooproject_dev
    git checkout -b fooproject
  • At the moment, because the repository is empty, .git/HEAD doesn't reference anything meaningful (meaning: I don't entirely grok the issue). This means that adds and merges will fail; so we need to touch some files (git doesn't see empty dirs) and check them in so that later tasks will work (The README's provide an opportunity for documentation too):
    mkdir configs
    touch README.org
    touch configs/README.org
    git add .
    git commit -m "Added some empty README's in order to initiate HEAD"
  • Add the drupal remote and fetch it:
    git remote add drupal http://git.drupal.org/project/drupal.git
    git fetch drupal
  • Now add drupal core as a subtree (I'm putting core in a folder named 'd8' and checking out tag '8.0.0-beta12'):
    git subtree add --prefix=d8/ drupal 8.0.0-beta12
  • push the whole thing up to your central repository:
    git push

At this point, you've got a parent project directory which contains drupal as a subtree. This allows parallel tracking of any drupal configs (and any other trees that you want to track in your git but store outside of drupal core like: drush_backups, drupal_private/[mumble], etc.). Your other development and production sites do not see the d8/core as a subtree; so they need no special care or knowledge of git when pulling from your central repository.

In order to update your drupal core:

  • fetch and merge fresh core code:
    git fetch drupal
    git subtree merge --prefix=d8 [new tag ref] --squash

Please review and correct.

It is worth noting that git subtree is not a built-in git command, but is a shell script included in the git contrib directory. My distro installs the script and creates a man page. [ymmv]

John_B’s picture

John_B commented

Thanks for that. I don't feel able to give an authoritative answer. It would be good to raise some others who will not see this post. If you hang out on IRC as many Drupallers do, it would be worth asking there, or maybe ask a few directly, or raise on stackexchange. If you feel you have done enough work already, and this workflow is working for you, I think it would be OK to go in and edit the documentation, perhaps with a proviso that this is not the only method (as well as drush, you may have seen the idea of using git only for custom code in the recent blog post on managing a site with Composer).

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

scottsawyer’s picture

scottsawyer
Primary language English
Location Atlanta
commented

Since using composer seems to be the D8 way of doing things, I have a question about it as it pertains to git.

What I understand to be the recommended way of managing a Drupal site is composer. I get that part. You install drupal, contrib, and custom modules and themes with composer install, composer require, composer update. Then your composer gets committed to git. This is fine and good.

However, when it comes to developing the custom modules and themes, I still need to make changes to them ( the custom modules and themes ), and commit them to my dev git branches ( assuming each module and theme is in it's own repo ).

How do I commit my changes back to git?

In the past, what I would do is create a directory for my module:

mkdir modules/custom_module
cd modules/custom_module
git init
git add remote <custom module remote>
touch README.txt
git add --all
git commit -m "Initial commit"
git push -u origin master

Then I delete the module directory, and add it to my Drupal repo as a submodule:

cd ../../
rm -Rf modules/custom_module
git submodule add <custom module remote> modules/custom_module
drush en custom_module -y
git add --all
git commit -m "Installed custom module"
git push -u origin master

Now I have an outer repo and a submodule repo, if I want to make changes to my module, I cd into the submodule directory, make my changes, commit to the submodule repo, commit to the outer repo.

Since the site is now managed with composer, I don't have a local git repo for my module ( modules/custom_module ). So how do I push changes in my custom module back to my custom module git repo?

ScottSawyerConsulting.com

John_B’s picture

John_B commented

Since the site is now managed with composer, I don't have a local git repo for my module ( modules/custom_module ).

Why not? You can commit locally, you can push that to remote, and you can install the module as a git repo by getting it back from the repo using composer.

If you do not want the git folder on copies of the module on production etc. you could remove the .git directory when installing the custom module using composer, as suggested here for a different use case.

I cannot see that it matters whether the local git repo is in the copy of the custom module under doc root, or whether keep your dev site free of git folders and just copy the custom module to a different directory on the dev server and commit there before pushing to remote. Though that extra step could cause problems if more than one person were sharing a dev site.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

scottsawyer’s picture

scottsawyer
Primary language English
Location Atlanta
commented

I appreciate it, and was actually just reading that post!

I am just learning about how to use composer, I didn't realize that when I install a custom module with it, I would get .git dir. I guess I was thinking about composer the wrong way, since whatever you do to your packages after composer downloads them, composer doesn't care. I was thinking about it more like git, where once you make changes, it's no longer in sync and you need to commit. Composer isn't syncing anything, it's just pulling stuff in, overwriting as it feels like ;)

Which means, if I am developing something, I need to make sure I push it to it's repo before updating with composer, or the old version will just overwrite it, no?

ScottSawyerConsulting.com

John_B’s picture

John_B commented

I am just learning this stuff too, and heard the recent Drupal Easy podcast on that composer is best practice

Which means, if I am developing something, I need to make sure I push it to it's repo before updating with composer, or the old version will just overwrite it, no?

I think that has to be right. And if you have committed on dev then clearly there is no point in updating with composer on dev as you already have the most recent version, assuming you have checked out master branch.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors