Git basics, GitHub, Dropbox and version controlling your WordPress projects

Most of us use the Dropbox service as cloud storage for the files that we need most often. And probably a big number of us [developers] use the GitHub service to host our code. And, at least, the official plugin and theme repository at isn’t meant for developing and pushing each commit separately. Some might know the following statement

“If I catch you at it, then I will ban you from The SVN only needs your final working version committed to it, not the entire history of the hundreds of changes you made using Git. Flatten your changes to a single commit.”


So we decided to go with Dropbox as our local, private and GitHub as our public facing repository. In the following article I will try to also show you how you can use both locations for your repository (where Dropbox goes first/is the main repo container) and gather as much info about your remotes as possible.

Checking, rechecking and reading the info provided by, is one of the best things you can do to better understand git and what’s going on behind the scenes in your repositories.

To continue, you’ll need to have the have Git GUI installed. At least if you want to try it out and not just read it. First we need to init a bare repo in our local Dropbox folder. A bare repo is different from a cloned repo as it doesn’t contain any code, but some very cryptic files instead (we’re not diving into this topic now). Let’s open our Dropbox folder and add a new folder in there, named like the actual development folder of our plugin. Then open Git Bash or your preferred CLI and switch over to our new Dropbox plugin folder.

# Init the bare repo
git --bare init

After we did this, we head back to our local development folder and do a basic

git init there. Finally we just need to add our new remote source: The Dropbox folder.

# Init the repo
git init
# Now add the remote source
# Make sure your path matches
git remote add dropbox /C/Dropbox/plugin-repos/plugin-name 

Of course, you could just

git clone your Dropbox repository or manage the cloning via calling git gui, but I prefer doing the above. Now, as a last step, we add a new repository to our GitHub account from within their web interface. After you created it, you’ll find three different types of addresses that GitHub offers: * HTTP: https:// * SSH: git@ * Git Read-Only: git://:// To add our GitHub repository as second remote location, we’re going to use the SSH link. This will avoid prompting us for our username + password on every commit. The only thing we need for this up front is our

SSH key set up. We’ll name our GitHub remote location origin as this is somewhat the default name (as master is the default name for the production/working branch). This will make it much easier for your to read and understand different tutorials you may find in the internet.

# Add GitHub as second remote location
git remote add origin 

Now we’re ready to go and can commit and push to Dropbox as well as to our GitHub account. Just make sure to select the right location when pushing. And to be sure that everything went right, we’ll also check our remote locations (and, in case, remove the wrong ones).

# Check first
# This will output a list of remote locations
git remote -v
# There's also an alias that is easier to remember
git remote show

# In case something went wrong, we remove the location
git remote rm dropbox 
# If we just had a typo in our remote location name, 
# we can simply rename it
git remote rename prodpox dropbox 

# Finally, after pushing, we check the details of our remote source
# In case we have branches this will also show us 
# if our branches are properly linked
git remote show dropbox
# Now we just check the state of our repo
git status 

A final note: A commit just adds data to our queue. It doesn’t push anything. You can commit and commit as long as you want and then, as final step, push your commits to your remote locations. Until you didn’t push, you’ll won’t be able to see any changes in your GitHub account and git status will always tell you that you have “unstaged changes”. Use this command as often as possible (or just hit F5 often in your Git GUI Commit Tool). Disclaimer: This article is mostly to have this written down somewhere for myself. If you got suggestions, improvements, find errors, etc. please feel free to drop me a note or leave a comment. Thanks.


  1. Seems like a lot of work to me. Why not create a separate “feature” or “bugfix” branch, do all your work on that branch and then use GitHub’s pull request feature to pull all the commits into a “master” branch when you are finished?

    1. The covered topic of “remote sources” is about different locations where you host your code, while branches (which I will cover in a follow up article) are different versions of your code. You can have “feature” and “bugfix”, as well as a “master” branch while still having your git repository synced on Dropboy and GitHub.

      About “lot of work”) Setting up your remote sources a one minute task that only has to be done once. I just counted it and it’s only four commands you have to enter (once). The other shown commands will help you to make sure that everything went ok. So in the end it’s a 30 seconds, one time task.

      If you got more questions about branches or need some clarification about it, just leave another comment or contact me via my about page. I will then try to cover that in the article about branches too.

      1. By “lot of work” I was referring to the fact of having separate remotes. I don’t see the need to push to one remote (dropbox in this case) and then when you are ready to release to your github remote. It would seem to me that using separate branches would take care of the problem that Otto was referring to in his comment.

        I understand the need to not have hundreds of changes, but you can squash commits. This writeup is the best that describes what I’m talking about without having the need to write it all here.

Comments are closed.