My workflow on OverrideAudit was/is something like the following:
First, I created the folder
Packages\OverrideAudit, set up a
git repository in it, and shared it on github in a repository with the same name. All core development happens within this single checked out copy on my Linux machine, although I did also have a checked out copy on one of my Windows machines and a MacBook so that I could periodically verify that everything was still working as expected on other platforms.
When it came time to release to Package Control, I released it under the same name as the repository to ensure that it would have the same name "in the wild" as it does locally on my machine, and removed the local directories from all machines except my primary development machine.
Once it was officially in Package Control, I modified my
Package Control.sublime-settings configuration file to include
installed_packages and also in
ignore_vcs_packages (this configuration file syncs across all of my Sublime installs on all machines).
So now all machines automatically install the package and keep it up to date, and if I'm doing any hard core development on one of them I can manually check out the repository and Package Control will leave it alone.
For the most part it's easier to do development on just the one machine. Prior to a release I create overrides for all of the files modified during the last batch of changes and place them on a Windows machine and the MacBook to override their installed versions, just to double check that I haven't broken anything. (for a meta win, OverrideAudit come in handy for testing overrides of itself ).
In all cases I try to keep all development (even locally) in a useable state. So if I'm working on something complicated that can't be finished and primarily tested in a day, I throw it into a branch and then switch back to master locally at the end of my development day to keep my local version working.
As @addons_zz mentioned, I also have a couple of sandboxes with portable installs that I can use to double check that the behaviour I'm seeing is the same as what the user would see. In my case I have one for the latest stable release, the latest development release and one for the build that I set up as the minimum allowable version to support, so that I can cross check that I haven't made any API blunders.
Potential ways to test this way include cloning/copying the raw files to an unpacked package directory of the same name or (I think better), using
Package Control: Create Package File to create a
sublime-package that you manually put into the sandbox
Installed Packages folder.
The latter is most important if you do anything accessing package resources at all, as it will be sure to let you know if you've made any incorrect assumptions about files being present that are not if you're installed as a