Using Git to manage both a core repo and project-specific repos

Mike_Waters's picture

I am currently using git to manage my site-specific projects, e.g. code that lives under /sites in a multisite (single core) scenario.

However, I find myself needing to work on two things that will require a separate repository tracking the Drupal core: 1) one-off core patches, and 2) install profiles.

I am not sure exactly how to begin; when working on a project, I am going to need to checkout both repositories, and one is going to technically need to be located inside of the other (/sites directory). However, the two repos absolutely need to be distinct entities, with their own branches and commits. I might even find myself working on a site project, and need to make some changes in the install profile or update core in some way. How would you work this out?

Does anyone manage distinct git repositories for both core and project-specific files? How do you manage them together?

-Mike Waters


drush_make to the rescue

mig5's picture

I only store my custom stuff and my install profile in git, and I use Drush Make to grab core/contrib from d.o 'on the fly' along with checking out my relevant stuff from git. It's a lot easier, incredibly faster, and you store less in your repo as a result.

Drush Make can also retrieve patches (i.e from your git repos) and apply them to any component i.e contrib modules that need to work a different way for your use case or whatever.

My blog post might interest you

Could you please clarify

Mike_Waters's picture

Could you please clarify "grab core/contrib from d.o 'on the fly' along with checking out my relevant stuff from git"?

Am I to understand that, in this instance, you are not relying on your makefile to download your git repository; only to grab core and contrib, and then cd'ing to your sites (or profiles) folder and doing a git checkout for that specific project? And, are you using this method for everyday testing, or just for deployment (when files no longer need to be in SCM)?

So my site is an install

mig5's picture

So my site is an install profile that contains its own make file. It is this make file that will grab the contrib and any other custom stuff i have in my own git

The install profile is a git repo on my server.

I have another make file (I call it a 'build' file) that when executed with drush make:

a) Grabs core
b) clones my install profile from my git server

Drush Make is recursive: that means, one can execute a make file that grabs something that has another make file, and it will recursively execute that. So, when it clones my install profile, it finds the makefile contained therein and proceeds to grab modules, themes, libraries etc.

A good example is ManagingNews install profile which has its own makefile, and my 'build' makefile for it . Or any other example I give in my blog post.

My 'testing/deployment' method might be a bit foreign to you since I use Aegir and you may not. I use this method above for building my platform, which I manage in Aegir.

A live site lives on the platform.

When I want to do work on the site, I 'Clone' it (an Aegir term) to make a 'dev' site of it.

I do my work on it.

I commit back to git the relevant parts (maybe a theme change, or I added a new module, so I add that new module as a dependency in the install profile's make file).

I then make a whole new 'build' all over again which grabs the changes, and

I 'Migrate' (another Aegir term) the live site onto the new platform with the changes, which applies any updates (including update.php) in the process.

The diagram on my blog post is really a better visual example of this cycle process. I can't explain it any better than that diagram does (thanks adrinux for that).

It kind of depends on Aegir in the Clone/Migrate process, but these steps are readily reproducible by hand (like adding a new Drupal core each time and moving the site from the /sites/ to the new build each time, and running update.php, cache clear etc. )

Thanks for the help. It

Mike_Waters's picture

Thanks for the help. It makes a lot of sense.

Edit: Reading through the drush make issues log (and then the source) helped me to realize that it actually clones and checks out the repos into a local directory - it does not just download them.

Thanks mig5 - I have actually

Mike_Waters's picture

Thanks mig5 - I have actually read your article, but hadn't considered using drush make as part of my workflow. My post actually is a result of my experimenting with ds's managingnews install profile, which makes use of drush make.

Your workflow makes more sense, as I am not actually contributing these patches of core upstream, so it is not really necessary for me to maintain a git repo of core; as long as I can build a working system with all the required patches, I am good to go.

Thanks for your input.