Some of our customers have asked us for advice on the best practices for using WP Engine’s Git Push feature.
Daniel Turton, one of our Support Reps, was kind enough to share his Top 4 Tips for Using Git Push.
Should I Appoint a Single Repository/Branch Maintainer?
We recommend you consider appointing a Repository/Branch Maintainer—this person will be responsible for pushing the data up to the Git Push point.
Designating a Repository/Branch Manager will help to avoid merge conflicts at the push point, because only one person will then have the ability to push to WP Engine.
Layout for Data Flow within WP Engine
Should I Still Use BitBucket/GitHub?
GitHub and BitBucket still have their place under many conditions. For example, GitHub and BitBucket continue to be helpful if your team has decided to develop with a central repository in your organizational structure.
Similarly, if you need part of the project to be accessible to the public—or to people that don’t need to make changes to the site—keep using BitBucket/GitHub. Access to Git Push for your site should not be granted freely, because it’s best to keep the number of people who can push changes to the site to a minimum.
WP Engine’s Git Push point was not designed to replace GitHub or BitBucket, so it’s best not to use it for these functions.
Should I Use Private Submodules?
The WP Engine Git Push system was designed to work with publicly accessible submodules. It’s unable to authenticate for SSH-based connections to services like GitHub and BitBucket.
If you need to use data from private submodules, consider bringing them into your project as subtrees. Subtrees don’t require communication with the private repository after the commit has been pushed to WP Engine.
A submodule, on the other hand, will require communication with the private repository to supply data when pushed. This link can provide you with more information on Git subtrees.
Should I continue to use Secure FTP to manage my files?
Since you’re now using Git Push to move your versioned content onto the site, it’s best to avoid making changes to tracked files. This is because they are replaced by what is kept within your repository on every push.
If changes are being made to those tracked files—and you would like to keep track of them within your repository—feel free to download them via SFTP, then commit them locally.
Top 4 Tips for Git Push
There you have it—Daniel’s Top 4 Tips for using WP Engine’s Git Push!
To sum up:
- Designate a single repo/branch maintainer.
- Keep using BitBucket/GitHub if (1) you develop with a central repository or (2) you need to provide outside access.
- Use subtrees to bring data from private submodules into your project.
- Keep SFTP usage to a minimum to avoid file conflicts.
Are there any other WP Engine features you’d like us to publish a best practice guide for?
So, it is better then to discourage the use of SFTP. Since we can’t be always sure that we can track those changes especially when working on a team. And so with plugins, installing them directly to staging and production is not a good practice then? It is better to install the plugin into the local repository the do a Git Push. Please correct me if I am wrong.
Hello James,
You’re correct! When changes or updates are made to code that’s versioned through Git, and those changes aren’t committed back to your local repository, they will be reverted to the versioned copy of the code on your next push.
It’s best to install/update your code through Git while it’s in use on your installation.
– Daniel T.
This is great. But if I update a plugin locally, and then push it live, that does not take into account any DB changes that could happen as a result of the plugin upgrade. Hopefully, this will not really be a problem.
(WP Migrate DB Pro is very cool, but if you are having real users on a live site, you can’t just push DB changes from local to live, that is *not* a good idea.)
If i used git push can i just push to the staging server?
If i used bitbucket to keep my other pc’s/mac’s in sync. could i then pull down from there one one machine and then push that up to the wpengine git server (and hence staging)?
Can you add support for submodules please.
I’m really struggling to fit WPE into our existing git workflow. This maybe lack of knowledge on my part so I’m open to any suggestions. We still need to store all the code centrally in BitBucket. We use vagrant, npm, gulp, sass etc which all place files in the repo which need to be excluded from the publicly hosted site. If I push the repo to WPE these files get copied across. How do I stop this form happening. WPE tech’s only solution was to add them to the .gitignore but then they wouldn’t get pushed to the BitBucket repo either. Or am I missing something?
Well I kind of have the opposite problem. I want things in my .gitignore to be pushed to WPEngine but not to GitHub (mostly generated files from gulp tasks).
I guess WPEngine would need to implement some sort of custom .wpeignore or .wpeinclude file to solve this.