Wondering how everyone else handles git within their local site installation?
Currently we’re committing the entire WordPress directory into git (potentially moving to using Composer to manage core/plugins later), however in the past we’ve had issues with the folder structure naming, which is probably a Docker based issue.
A sample site would have two folders under /app/ - public and sql. So if we used the standard path without modifying it, every site would live in /app/public. I’m not sure whether its a missing feature, or a feature that other systems have, but a combo of Bitbucket and Gitkraken don’t allow overriding the name of the repo, and will default to the name of the folder it exists in. Hence this being a problem - every site ends up being “public”.
The workaround I came up with was using the volumes manager to remap public to the sites name, eg I’d map C:\path-to-local\example-site\app\example-site to /app/public, ensuring all repos had folder names directly relevant to what they were.
Currently I’m on Local 3.3.0 to keep this workaround, as another dev I work with had some trouble getting the symlinks working on Lightning, so now he’s got a bunch of repos named public.
Assuming I can get the workaround working on Lightning, it’d be something I could live with, though I’d be keen to see if anyone knows any better ways to manage this? Committing at the root level of the site at a minimum is a must - we’ve got additional changes at the wp-config level as well as bunch of custom htaccess rules. Another alternative is committing at the site’s base level, which would also grab the config and logs (could gitignore it, though config might be useful), though in git it’d be a lot of extra levels before you get to the actual site.
Curious what other people’s workflows in regards to how you commit into git are - surely I’m not the only one committing the entire site who’s run into this issue before!
What’s the reason you commit the entire site/public folder? There have been some issues, but I think I don’t understand the benefit to that over just the theme.
Do you use Local to manage WP Engine or Flywheel sites? Or is your team using Local for its, um, local environment only?
I’m on the latest version of Local and our team uses Bitbucket and WP Engine. I also use Tower (https://www.git-tower.com/mac) as a git UI. I have not had an issue naming our Bitbucket repos or the name of the repo in Tower.
Our workflow typically goes like this -
Create the bitbucket repo - naming it whatever you like
Pull the site down with Local to a directory of your choosing
Create an empty git repo in the public folder within Tower for management
Add the remote for bitbucket
Add the remote(s) for WP Engine environment(s)
Add commits as normal pushing wherever the code needs to go. We track all of WordPress as you do with a very detailed .gitignore file for lots of the WP Engine system pieces.
Usually comiting the entire site structure has to do with some sort of deployment strategy of the remote Host.
Since WP Engine and Flywheel are managed WP hosts, we lock down the folder structure as well manage the WP versions of the site. Because of this, we usually recommend against comitting the whole site to source control.
On the other hand, if you’re using a different tool like the Roots.io, you’re likely comiting the whole be Bedrock config so that the site can be re-hydrated remotely using Trellis.
As a general rule of thumb, I like to keep my repos on the small side which for WordPress sites can often mean something like:
One repo for a custom theme
One or more repos for custom plugin(s)
It sounds like you’re looking to use git as part of the deployment strategy for the site. Can I ask what the remote hosting provider is?
From your description, the volumes manager does what you are expecting it to do, but you’re also right that this won’t work in Local Lightning (v.5.0 and up).
We commit the entire folder similar to what Ben’s mentioned - we don’t use Roots specifically but I follow a similar idea for it. I think having either the plugins + core themselves, or a reference to the version for each (so something like composer can install them all) gives a lot more control to make sure nothings out of whack between dev/staging/prod versions, and you know what is where.
We also have various htaccess rules, deploy scripts (we currently do deployment locally using PHPloy, readme/dev log files, special configs etc. If we just have the theme committed, then to rebuild a site would take a lot of manual work, which means we could have some errors between what you installed and what you were supposed to have. I think this setup gives us the potential to move to something like Bitbucket pipelines or Github actions in future - would be able to run node build tools for the custom theme, and composer for core/plugins and deploy all code in one hit. Our host is just a local cpanel/apache provider, so nothing special on their front.
Regarding the repo names, on Bitbucket they’re named correctly, its just that Gitkraken seems to prefer the folder name over the repo name. I know way back when I used Github Desktop for Windows I think it used to prefer the repo name, so might be a limitation of Gitkraken.
Yeah. Those reasons all make sense. My reasons for versioning the full site were a little different. When I needed to it was because I was using gulp/webpack to package the theme.
The script would then copy the dev-theme into a production theme.
I would then have to go out to root (which had a separate repo) so that I could git push to the WP Engine site. As much as I enjoy Local for how easy it is to manage WP instances, I think I prefer using git to push up site changes. I have so much more control that way.
Local is still really helpful for managing the database though.
I have no idea if there are limitations to this, but it looks like I can use a symlink for public. Have you tried some sort of symlink approach to see if it works for your workflow? So something like this:
I have a feeling the symlink will work - If you’ve got it working here I’ll definitely give it a shot. I’ll download Lightning this weekend, setup a test version and give it a shot, will report back once done!
It works! A couple weekends late, but tested and working as intended. The new Local seems to be rather slow on my PC, but a separate issue I’ll tackle. Thanks for the help with this part!
