Skip to content

Recommended Git Workflow

Jack Lowrie edited this page Aug 2, 2020 · 2 revisions

While not strictly necessary (this repo will still work without git/github), the following workflow is recommended for setting up new projects with WP-Gizmo.

For Individuals (and Individual Projects)

This project is based on WP Rig, so the recommended git workflow is nearly identical to their git workflow. The bird's eye view is to follow the instructions in the step-by-step above to set up your project, then set the upstream to this repo. That way, as improvements are made to WP-Gizmo, you can merge them into your own project(s) as they make sense. So wp-gizmo is upstream of [your-plugin]-gizmo.

For Teams (agencies, organizations, any group of people that will build more than one plugin together)

Chances are if you're building plugins as part of a team, you'll want some boilerplate/build process features that are unique to you and your workflow. The recommended process for using WP-Gizmo in that case is largely the same as the git workflow for individuals, however instead of setting this repository as the upstream for your plugins, you'll have your own (differently named) version of WP-Gizmo to spin new projects off of. In other words, use this template repo to create a template repo of your own! For a name, I recommend replacing 'wp' with your team's name or abbreviation (so MegaCorp's template becomes megacorp-gizmo or mc-gizmo). Publish the repo to your team's github organization, then set the upstream to this repo. Now, when it's time to build a new plugin, your repeat the process, but set the upstream for your new plugin to your organization's version of Gizmo. That way, you can pull in updates to wp-gizmo to your organization's copy and adapt them for your workflow first, before pulling them into individual plugins. So, if MegaCorp was an organization that built plugins, and they wanted to use a customized version of WP-Gizmo to create many plugins including a plugin called Deplanitizer, then they'd set up their git-flow so that wp-gizmo is upstream of megacorp-gizmo. MegaCorp can make modifications to megacorp-gizmo and merge them into all their plugins, and if they see an update to wp-gizmo that they like, they can merge it into megacorp-gizmo, integrate it with all their customizations, and then send everything down to their plugins

Naming Individual Plugin repositories for Teams

Just like for individuals, I recommend against naming individual plugin repos after the desired plugin name, and instead prefixing your plugin slug with your team's slug or the slug of your team's version of WP-Gizmo. I would advise against prefixing with gizmo, wp-gizmo, etc. in order to distinguish between gizmos that are downstream of your organization's version of WP-Gizmo and gizmos that are directly downstream of WP-Gizmo (especially if you have both!). That said, it's more important to follow a naming convention that is consistent and makes sense to everyone on your team. So if MegaCorp was making the Deplanitizer as a wordpress plugin, they'd call their repo megacorp-deplanitizer, and set its upstream to megacorp-gizmo.