Question: Sometimes, package updates from MELPA can break some part of emacs and when that happens I'd like to be able to revert back to using an older version of the package.

Right now, I can do it in two ways:

* I've set emacs to delete files by moving to trash and when I update a package, the older version is trashed. I can retrieve the older version and replace the one in `~/.emacs.d/elpa`.
* Go to the github repo of the package that broke functionality, fetch an older version of the package, replace the one in `~/.emacs.d/elpa` with the one from gitub, byte-recompile the file(s).

Both these ways involve a lot of manual work moving things around. Is there an easier(preferably automatic) way to downgrade packages installed from MELPA?

Answer: 
The "nuclear option", as it were, would be to ditch `package.el` entirely and instead use the package manager that I wrote, [`straight.el`](https://github.com/raxod502/straight.el). The advantage would be that `straight.el` installs packages by cloning their Git repositories, thereby making it trivial to use whichever version you would like. Also, `straight.el` provides functionality for dealing with revision lockfiles, which allow you to record the exact state of your package management configuration down to the smallest detail. Then, in the case of an emergency, you can simply revert all packages to their known-good versions.

These kinds of operations are, in general, impossible with `package.el`, and they will always be impossible, due to the overall design.

In response to your desire to avoid making a commit every time you update your packages, this is not necessary with `straight.el`. I would *recommend* writing a version lockfile and committing that every time you update your packages, since that makes it impossible to ever get into a state where your Emacs configuration is broken after an upgrade and you don't know how to revert. But you don't have to do this, if you like living life on the edge.
Lots of people elect not to commit ELPA packages to version control, but this is an example of why I believe you should do so.

Reverting *anything* is trivial if it's all committed.

Depending on the state of the upstream ELPA packages is a risk.