- 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.
I built this for a special type of content deployment for the company I work for but I think it's only been used internally so far (albeit successfully) - I made the tool as generalised as possible though as the core concept is quite re-usable, but I don't think I have described it's purpose clearly enough for the rest of the world in the readme: . "$(git --exec-path)/git-sh-setup"
require_clean_work_tree "bump" "Please commit or stash them."
https://git-scm.com/docs/git-sh-setupBut 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.
Usually I have source files in a “src” subdirectory and assets in an “assets” subdirectory and configure the web server to serve from these two subdirectories.
So the git repo root is one level above anything served by the web server.
have git data lying around among otherwise public files
There are almost no public files on a server these days. It's mostly backend code generating output by combining data from databases and templates. So since it's already all non public stuff, I don't see a problem having the .git folder there too.