- Fetches
- Checks the branch you are deploying from hasn't diverged from it's tracking branch.
- Checks whether each path+tree-object combo trying to be deployed has already been tagged.
- Checks whether each tree path being deployed is clean.
- Finally, if it fails to push new tags it reverts everything to prevent deploys unavailable to everyone else.
. "$(git --exec-path)/git-sh-setup"
require_clean_work_tree "bump" "Please commit or stash them."
But no, I did not know of git-sh-setup, thanks for the tip :-)
My workflow looks like this:
A feature branch is mature enough to get merged into master. So I merge it into master on the staging server. And then push it to the public server.
But everyone’s workflow is different. The author maybe should have added a reason why he uses that instead of git status
Seems unusual that all branches are involved in deployment though. Isn't the typical workflow that only one branch get's deployed to the user facing machine?
Er, I guess that doesn't tell if you if you have un-pushed changes... but if your deployment process allows someone to deploy without pushing, your process is broken. Someone will deploy to Prod and forget to push their config changes, eventually.
One of the major reasons Kubernetes is a thing is because all of your deployment can be declarative. Deploy-via-Git means I can destroy my entire world and bring it back in a minute or less.