Developing WP locally with git

Workflow
1

I’m curious to hear different approaches, but thought I’d share my workflow for developing WP sites locally using git for the heck of it, so here goes!

First I initialize a git repo for my custom theme in the wp-content/themes/ directory that I installed my Local site in (always under my user folder, as Local generally has to be installed there). Then I add the origin from either GitHub or Bitbucket, copy over my personal WP starter theme and do the “initial commit”.

I do the same if I’m creating custom plugins for the sites, usually grouping them under a project in Bitbucket.

Once I have something ready to put on a staging site, I’ll spin one up in Flywheel and then use DeployHQ to automatically push any new code from my master branch to the theme folder on the staging site. This is why I always advocate against “cowboy coding” because it gets you out of the git workflow and your changes are overridden next time you do a proper push with git.

That’s pretty much it honestly. I usually don’t care a whole lot about syncing data, but if I did I would totally pay for a WP Migrate DB Pro license as that makes your life so incredibly easy to sync data (especially if you just want to clone an existing site to one locally).

Anyway, I’d love to hear others’ workflows!

9 Likes
2

Hey Trevan! I love this - and I have a really similar approach - WP Migrate DB Pro is a serious life saver!

When I’m using Migrate DB Pro, I’ll make sure I’m only ever pulling down data into my local site. If I ever push anything to the live, production site, I might lose production data! Eeeek. :scream:

I also use Advanced Custom Fields Pro, then export my finalized field groups into a PHP file and a JSON file. I add both, then include the entire PHP file in my theme. This is really helpful because then you can basically “version” your database. When you upload or deploy your updated theme, the advanced custom fields are immediately updated to what you need them to be on production. This is a dream for versioning and making sure no information is ever lost. Talk about nifty!!

Another thing that you mentioned was deploying your updated theme. I use Node with Gulp/Grunt/Webpack to combine, clean, and optimize my Sass and Javascript in all my themes now-a-days. Often times, I’m collaborating with multiple developers. The challenge I’ve found with DeployHQ, is that it doesn’t let you compile those files when you deploy, so you have yo add the compiled CSS/JS files into the Git/SVN repo. There are soooo many conflicts that happen because you add those compiled files. Recently I’ve just been using Codeship (https://codeship.com) because it lets you compile before you deploy. It’s a little expensive, unfortunately. If there’s a cheaper option, I’d love to know!

3 Likes
3

@trevan you should really take a look at GitHub Updater. You can use it to install your starter theme or any site specific plugin on your Local environment, then on your site, it will see an update and allow for updating via the dashboard or several other methods.

6 Likes
4

@trevan I can vouch for Migrate DB Pro and Advanced Custom Fields licensed plugin tools.

I am curious where you or others set $ git init for tracking a site on Local. What do you .gitignore? Do you work with Git Hooks? I have on a Vagrant VM but have not tried them here.

1 Like
5

I just initialize git right in the custom theme directory, so it treats the theme as its own project and knows nothing about other plugins or the WP core. I’ve thought about initializing the entire site and ignoring core files (so just my custom theme and custom plugins would get added), but I’ve found it better to more or less treat each theme and plugin as its own little git project.

3 Likes
6

Whoa, nice! I’ll give this a shot.

7

Let me know if you have any questions.

8

Setting up the repo in the theme makes a lot of sense.

I worked with another team that repo’d the whole VM. Git hooks were created to add version control to the database, which was useful to try data or other settings then wipe it all out without affecting files by running a command like $ puppet apply manifests/default.pp.

Thanks so much!

1 Like
9

Hey Trevan,

Thanks for the write-up man! I’d love to hear how you’d (or anyone who’d like to share)set up a workflow if you are working on an existing site that’s live on the web and if you making modifications/ amendments etc.

I use a plugin called Revisr to initiate git on the live server and push the code to gitlab or bitbucket and clone to the local machine. But Revisr doesn’t always work and usually, I only have wp-admin & FTP access.

Cheers
Dylan

10

Have you checked out Buddy?

11

This is definitely the simplest approach to use for themes & plugins IMO. I’d always recommend starting with this.

2 Likes
12

Interesting thread that unfortunately will probably cause many hours this evening to be spent tinkering (again) with git and Tower.

Anyway, I came here looking for what I think is pretty nifty with Laravel Valet, this shell script by Aaron Rutley, ValetPress.

What I especially liked is this automated bit:

git clone https://aaronrutley@bitbucket.org/aaronrutley/turbo-light.git wp-content
cd wp-content
rm -rf .git
git init
eval mv ~/Sites/"$project_name"/wp-content/themes/turbo-light ~/Sites/"$project_name"/wp-content/themes/"$project_name"
wp theme activate "$project_name"

Is there possibly a (somewhat) easy way to recreate this with Local’s Blueprint feature, preferredly without tinkering with obscure commands in some SSH terminal?

13

Hi @trevan ,

I’m pretty new to flywheel hosting and would appreciate any feedback on where things could be improved, especially when considering the features for flywheel hosting. Following approach was done when we haven’t had a bulk plan at geflywheel.

A new project gets created in GitLab, along with a configuration for a GitLab runner (doing some linting stuff, no unit tests, deploying the theme folder to the correct server/folder, installing WordPress plugins via composer and activating them via wp-cli).

The basic structure of our project looks like this:

/dist #folder to hold minified and uglified theme and plugins, ready to be published
/src
—/theme
—/plugins
.gitlab-ci.yml
composer.json
gulpfile.js
package.json

In terms of npm/gulp we have taks like

prod: gulp cleanup && gulp-build-prod
dev: gulp build-dev // also fires a watcher with browsersync reload
install:plugins: // several tasks that copies everything from /src/plugins to 
build/app/public/wp-content/plugins. Afterwards it runs composer update to 
update public plugins and wp-cli to activate all plugins

When a user starts developing, we usually have this workflow:

  • pulling the latest changes from GitLab
  • Executing npm run install:plugins to get/update/activate all required wp plugins
  • pulling the latest DB/media files from live to local via migrate db
  • running npm run dev
  • Working on the theme within a feature branch
    In that scenario, the watcher tasks copy all the files to the corresponding build-folder (the one where local is pointing to) and browsersync works as expected.

Once the developer is done, he or she pushes their changes to Gitlab, create a merge request and once the review is done and got accepted, the shared runner kicks in.

Shared runner (runs on the same server as the WordPress installation)
That one is run after every merge from feature-branch into master and does nothing else than executing npm scripts:

  • npm run lint for checking css and js files
  • npm run prod to build the files for a production server
  • rsync theme and plugins folder to the correct Wordpress-installation
  • executes composer update (for public plugins)
  • executes wp-cli plugin install (for our custom-plugins)
  • executes wp-cli activate

That way, we get the very same result for every developer and pushing to our stage-server is done completely automatically. When we create a TAG in Gitlab, that particular TAG gets deployed to a QA server where a client can test the website without being interrupted by new continuous deployments.

Note: Maybe this is a little bit of an overkill. But theme development could sometimes be so boring and switching on our techie goggles helps to make a seemingly boring project way more exciting (-:

What do you think and do you guys have any tips on how to better include local by flywheel and the newly bought bulk plan?

Best,
Philipp

14

A post was split to a new topic: Hash mismatch when downloading Custom Environment

15

I might be wrong to think like this, but I rather init the git repo on Wordpress root, and use the common .gitignore for Wordpress: https://github.com/github/gitignore/blob/master/WordPress.gitignore

That way I can take care of Wordpress updates, plugin updates and additions, when I make those changes. Those kind of updates can break something on the website and most times felt right to be put in versioning. That way I can update anything locally, resolve any issues, commit and use a Hook to deploy for production with DeployHQ and even roll back or branch a specific update so I can work on it separately :smiley:

I vouch for WP Migrate DB Pro too, used it in many projects and its a life/time saver!

The only thing I have that (I think) is really bad is database versioning… The projects where I work have some things that are created by us, and some that are created by the client, so I have to make backups everytime manually… I would really love a Git for databases :cry:

There are some projects that try to do that, but nothing that I ever felt was worth the effort.
http://www.liquibase.org
https://klonio.com

Do you guys use anything for that?

2 Likes
16

I have a couple questions. Can I email you privately about them? I am trying to use your plug-in but I seem to be missing something really obvious or fundamental, or I am misunderstanding the primary purpose and usage of the plug-in. Thank you.

17

Probably best to move that type of discussion to the Slack. https://github-updater.herokuapp.com/

There is also a lot of information on the GitHub wiki.

18

Thanks for fast response and the link to Slack. I’ve also read the GitHub wiki. That’s why I wrote you; either I’m way before “newbie” and really missing something fundamental, or your tool isn’t built for what I’m thinking it can do. I inherited a WP website and asked the folks at Flywheel to migrate it to Flywheel. From there, I was able to “easily” create the website on my local via Local by Flywheel. Now I need to connect to the GitHub repo that stores all the source code for this website and pull that into my local. The question is simply: does your tool do that? Pull from a Git repo master branch, and into my local? I’ve installed your plug-in into my local but that’s as far as I’ve been able to go. If the answers are in Slack, sure I’ll head there, but I’m embarrassed to say how much time it has taken me to get as far as I have. Your tool really seems like it would save me a bunch of time and make me and the other developers more productive by getting us all on Flywheel and using a common development cadence. But so far that has not been the case. Thanks again for reading this and your next reply.

19

The GitHub Updater plugin will update individual plugins and themes that have been setup to work with it. It does not pull in an entire site.

I use it to develop other plugins, etc, locally and then use GitHub for version control. When I update the version number on GitHub I can then see an update on sites running the GitHub Updater plugin. If I’m not developing a particular plugin on a local site, but I need to use that plugin for the site. GitHub Updater will help keep that plugin updated.

On my list of things to do is to write a post about how I use GitHub Updater during development.

1 Like
20

Can you elaborate on this part?

I don’t understand how to share a theme in a github repo and collaborate on it without comitting an entire wordpress site to github!