Hello again!
Is it possible to use multiple GIT repositories under “parent” repository with Bedrock? This is my folder structure:
|-- app
| |-- mu-plugins
| | |-- mu-plugin-1 // repository 1 - public, GitHub
| | |-- mu-plugin-1 // repository 2 - public, GitHub
| |-- themes
| | |-- parent-theme // repository 3 - public, GitHub
| | |-- child-theme // repository 4 - private, client, BitBucket
| |-- plugins
| | |-- plugin // repository 5 - public, GitHub
Each repository is defined in composer.json and downloaded on composer update command.
I expect to tweak the mu-plugins and parent-theme quite often. Because of that, it would be awesome to push commits to online GitHub repos from EVERY project built on Bedrock I will be working on.
However when I do a change to e.g. “repository 4”, I get message: "Your branch is ahead of 'composer/master' by 1 commit."
I’m trying to find the sollution to the error myself (as I am an absolute GitHub beginner).
My question is: What is the most compatible approach with Roots/Bedrock in such cases? Does my way of “nested” repositories make sense? Or should I use submodules, as a lot of forum posts suggest (but you do not)? Or something entirely different?
Thanks in advance, being stuck in such problem is quite annoying. 
Look at git subtree it takes some time to set up, but it is in my view much better then git submodules. There are some pitfalls, so read up properly before you init the repo.
Not exactly sure if I’ve got your situation correct, but here’s my understanding:
- Your folder structure actually looks completely standard for Bedrock (assuming all those repositories are managed by Composer which you said they are).
- Those repositories aren’t actually sub repos WITHIN a project. I’m assuming you have them
git clone'd outside of your WP project dirs.
- When you make updates to any of those repos, you’re doing so outside of a WP project dir/repo.
- Whenever you push an update to any of those repos, you want ALL (or at least multiple) Bedrock-based project to automatically run
composer update and get the version you just pushed.
What I would probably do:
- Make sure your versions in Composer are set to
dev-master or some wildcard that would ensure you’re always going to get the latest commit.
- Ideally you’d have a Git hook like
post push but since that doesn’t exist, simplest way is to write a Bash script and use it like this git push && update-projects. (note:update-projects would have to live in your $PATH and be executable).
- You can further simplify this by creating some custom git alias like
push-update or something than just did git push && update-projects automatically.
The bash script would just loop over all your projects (you can manually define the list or have it loop over all dirs in some parent dir), and run composer update.
More on the lack a post push hook: http://stackoverflow.com/questions/1797074/local-executing-hook-after-a-git-push
1 Like
Scott, thanks again for a very detailed answer!
- Yes, I haven’t changed the folder structure of Bedrock - it is
actually the main reason, why I like Bedrock as much as I do.
- Yes, “nested repositories” (mu-plugins, parent theme, …) are
git clone'd versions of my repositories. Can you have a look to my
composer.json file to see exactly what I mean?
- I would like to do the updates (commits/pushes) straight from Bedrock projects - that’s what does not work for me now. I have one Bedrock project, WPGrouse, solely intended for developing the framework. In fact the Composer.json file I’ve linked to belongs to it. I make updates to “subrepositiories” from it and than push/commit them to GitHub (or at least it is what I would like to do). Besides that, it would be great if I could commit/push to e.g. parent-theme “subrepository” from other projects as well, so when I make an update to parent theme in the client’s work locally, I would not have to do the same thing in WPGrouse project.
- Not necessarily, but of course, it would be awesome. More important for me though is to be able to make the changes to parent theme etc. from particular projects, as I’ve described before.
Does this make it more clear?
And about proposed steps:
- Already doing something like that.
- This exceeds my current Git and terminal knowledge to be honest, but at least I know what to Google now.
Thank you very much!
To cut long story very short - I am definitely not alone, a lot of people ask how to use nested GIT repositories. Usual answer on Stack Exchange etc. is “use Submodules” or “use Subtree” (as @sten_e_winroth pointed out as well).
Does it apply to my Composer & Bedrock case as well? Or do Subtrees? Or is the right approach just to use “nested repositories” as I intended, but (maybe) configured wrongly?
Thanks!
I’m trying to figure out strategy for this as well.
I’m building a multi-site project and need a strategy to manage the Bedrock, the primary site theme, and several sub-site themes.
I initially started with submodules, and that’s been a complete mess, especially after trying to deploy with Capistrano.
Now looking at sub-tree strategies.
I wonder if anyone has a decent solution?
Composer should still be the best solution for this. Submodules are just trouble.
So you are suggesting I create a bare repo outside of my bedrock project directory, push it up to a remote, and then pull that down into bedrock using composer?
What exactly is your setup? By multi-site project do you mean a single WP network install with multiple sites?
Yes, a sub-domain install with domain mapping, and multiple sites.
I have a bunch of custom plugins (and mu-plugins) as well as themes, that I’d like to manage independently of the main project (on bedrock). Locally I’ve set these up in their own directories, outside of the project, and pushed them up to bitbucket.
I’m trying to use composer as you suggested but having some problems that I noted over here:
http://discourse.roots.io/t/best-way-to-install-private-paid-plugins-with-composer/1045/8
You have the right idea. Ideally all those plugins and mu-plugins are separate projects/repos/Composer packages and you just require them in any project you want. You can do the same with themes if you want as well. But I’d only do that if it was either a) a parent theme you aren’t modifying, or b) other themes you’re sharing across multiple projects. Otherwise the themes should just be part of the site repo itself.