Saving discrete code changes in version control with Git enables you to track the history of changes throughout the lifecycle of a project. Commit your changes (early and often) to Git and push them to a remote GitHub repository to deploy them to a targeted, specific environment (Development, Staging, or Production) and collaborate with anyone from anywhere. After you’ve shipped a new feature and want to get all the latest data from the production site, you can use Local’s Connect and sync what you want when you want.<\/p>\n\n\n\n
This post is part of a series that helps set up an end-to-end workflow for developing sites.<\/em><\/p>\n\n\n\n Notice how I put “(in Local)” in parenthesis? Local does not offer any integration with Git version control or GitHub, for that matter. However, our WordPress codebase exists because Local generates the WordPress core files for us and stores them on your computer. We want to focus on taking some of those files and directories and putting them under Git version control while intentionally ignoring the rest. This allows us to keep a discrete history of changes to our codebase.<\/p>\n\n\n\n There are many ways to go about how to version control and organize your Git repository. Consider using Composer to manage your WordPress plugins<\/a> and theme dependencies or utilize WP Engine’s Smart Plugin Manager<\/a> service to auto-update your plugins and themes.<\/p>\n\n\n\n It is also worth noting that you can rely on WP Engine’s WordPress core auto-updates<\/a> or test and manually trigger WordPress core updates yourself (either in WP Engine’s portal<\/a> or in your site’s WP admin dashboard<\/a>), but we won’t cover including WordPress core files in our version control.<\/p>\n\n\n\n Ultimately, it is a matter of what works best for you and your team, and WP Engine aims to offer the flexibility to meet most teams’ workflow needs. Mostly, we encourage you to keep your Git repository lean because it’ll help keep your GitHub Action deployments shorter. The more plugins you add (and files) to your repository will increase the time it takes to run a deployment, which can create a counter-productive side-effect for your team.<\/p>\n\n\n\n If you’ve been following along, you should have the Yoast SEO plugin and Frost theme installed on your Local site, which we will continue to work with for this end-to-end demonstration.<\/p>\n\n\n\n It is crucial to tell Git what you want to keep a history of and what you want to ignore. There is a particular file that Git uses to maintain this list of allowed and disallowed files and directories. It is called the .gitignore file.<\/p>\n\n\n\n If you’ve been following along then your Local site’s In our case, we only<\/em> want to track the So, let’s create a new file in VSCode (or your editor of choice) called Below is the complete code for our \n
Telling Git what to ignore<\/h2>\n\n\n\n
wp-content\/<\/code> directory likely looks like this:<\/p>\n\n\n\nDirectory<\/th> Description<\/th><\/tr><\/thead> wp-content\/plugins\/index.php<\/code>wp-content\/plugins\/wordpress-seo\/*<\/code><\/td>WordPress plugins directory with Yoast SEO plugin installed and the standard index.php<\/code> file.<\/td><\/tr>wp-content\/themes\/index.php<\/code>wp-content\/themes\/frost\/*<\/code><\/td>WordPress themes directory with the Frost theme installed and the standard index.php<\/code> file.<\/td><\/tr>wp-content\/upgrade<\/code><\/td>Where WordPress often stores backup info when running upgrades.<\/td><\/tr> wp-content\/uploads<\/code><\/td>WordPress media library uploads directory.<\/td><\/tr><\/tbody><\/table> wordpress-seo<\/code> plugin and frost<\/code> theme directories with Git.<\/p>\n\n\n\n.gitignore<\/code> , add the following necessary rules to allow and disallow the pertinent files and folders, and save the .gitignore<\/code> within the wp-content\/<\/code> directory, which is the root of our Git repository.<\/p>\n\n\n\n.gitignore<\/code>.<\/p>\n\n\n\n