Recover from a stupid plugin update

It's happened a couple of times. Sometimes, before pushing my changes I create a new .zip file for a plugin to test on a live server. I find some problems, fix them, commit the changes, create a new zip file and re-upload. But I don't pay attention to where I'm uploading the new .zip file. WordPress lets me know I'm replacing the current version, but I know that so I continue. Then I realise I've just uploaded the .zip file into a local install where the plugin I've updated was symlinked to the master GIT repo. The plugin I've updated appears to work. But I then discover that the master GIT repository is a completely empty repo.

No .git directory, Nothing.

Fortunately I have the newly installed plugin and the latest .zip file from which it came. But, because my zip process doesn't package everything the I'm missing the following folders:

node_modules
tests
assets

I can rebuild the node_modules, but can't recover the brand new tests I wrote, nor the commit history since the most recently pushed commit.

BUGGER

Is this a bug?

Is this a bug in WordPress? Possibly. I know it's something I've tried to address in oik, detecting GIT repositories and symlinked folders. But when oik's not activated, then this protection is not provided. So the answer is Yes. It would appear to be limitation of the new updating capability of WordPress core.

Could I improve my process?

Yes. Before creating the zip file push the most recent commits.

So process would be something like

commit changes
l10n - Run internationalization and localization routines
pu - Run PHPUnit tests
tgh - To Git Hub
zip - package
commit zipped version
tgh
upload and test

If there's a problem with the zipped version I really only need to change the version number if no one else has had access to the new version.

bobbingwide / oik-bob-bing-wide

Recover from a stupid plugin update #41

Is this a bug?

Could I improve my process?