git-ready-to-deploy.sh
(pronounced "get ready to deploy") can ensure
that the local clone is clean (no uncommitted changes), and that there
are no local commits to be pushed upstream.
This is useful in a manual deployment setting, where you want to ensure that:
- Nothing uncommitted gets deployed.
- Nothing not yet applied upstream gets deployed.
For example, this repository uses git-ready-to-deploy.sh
on itself,
to help assure the quality of its
releases.
To ensure proper accreditation, manage releases, and reduce code
duplication, git-ready-to-deploy.sh
is generated from an m4
template. To get the shell script, either:
- Fetch the latest release of the shell script, or;
- Type
make
to build it, if you happen to have the m4 macro processor installed.
Please note, the last step of building git-ready-to-deploy.sh
is to
execute the thus built git-ready-to-deploy.sh
. This ensures a clean
release of git-ready-to-deploy.sh
, so long as you mind the exit code
from make
.
This script should be used only if applicable in your deployment process. In particular, a deployment process where someone, perhaps a bot, can pull, make changes, and can deploy without committing and pushing back first.
In this scenario, this script is best-used as an integral part of your
"deploy script". git-ready-to-deploy.sh
fails, if there are changes
to be committed, or pushed. If used properly, it can prohibit
deployment of ill-versioned code.
Alternative deployment strategies include push-to-deploy, or push-to-staging, with a subsequent process for deploying from staging. This script is unlikely to be useful in these scenarios.
Discussed on Hacker News.