What's the best way to replace an old copy of WordPress with a fresh one and push to GitHub?
I have been version controlling my WordPress site with Git and pushing to GitHub for quite some time. I develop locally, push to GitHub, and pull from GitHub to my production server.
I would like to scrap my current WordPress core on my local environment and replace it with a fresh new copy to then be pushed to GitHub and pulled to my production server.
- How to deploy a plugin to Heroku
- Ignore containing folder, but not a folder within
- What is the dummy's way to work on wordpress locally (w/versioning) and migrate changes to server, including databases?
- Version control for both Vagrant config and themes being developed
- WordPress site team development
- Permissions for local development with git and MAMP
My question is…am I going to run into any sort of tracking errors wit Git by replacing my WordPress core? Any other suggestions for me when I do this?
2 Solutions collect form web for “What's the best way to replace an old copy of WordPress with a fresh one and push to GitHub?”
I handle this by adding the WordPress core as a subrepository. WordPress maintains a mirror of their SVN repository on GitHub. Then you can update to a new version easily by going into the subdirectory containing the WordPress core files and checking out the tag for the current version:
git fetch --tags git checkout 3.3.2
The repo also includes beta releases, if you prefer those.
Here’s the guide that I used to set up this process: Install and Manage WordPress with Git
I understood you’re talking about updating wordpress. You should note that, like documented in the update instructions, during update you should
- check the requirements
- take a backup of your database contents
- disable the plugins you have
So all this you should do regardless. Also, you should be sure to update your database content, too, if needed.
WordPress contains instructions on updating using svn, and it seems it is, according to them, a perfectly fine approach to have. I would see no major difference for you to do essentially the same thing with git, provided you can tell exactly which files are appropriate to store on version control and which aren’t.