
Show HN: Git-Ready to Deploy? Check for uncommitted and non-pushed changes - oleks
https://github.com/oleks/git-ready-to-deploy
======
tomxor
I wrote a git-tag based cli content deployment tool that does something like
this as part of the deploy stage. It's intended for use with multiple users
with a single remote, so before attempting to deploy anything it does the
following to ensure no conflicts and that outdated content is never
accidentally deployed:

    
    
        - 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:

[https://github.com/LearningScience/pegit](https://github.com/LearningScience/pegit)

------
wereHamster
Do you know about `git-sh-setup`? As in:

    
    
        . "$(git --exec-path)/git-sh-setup"
        require_clean_work_tree "bump" "Please commit or stash them."
        
    

[https://git-scm.com/docs/git-sh-setup](https://git-scm.com/docs/git-sh-setup)

~~~
oleks
This will only spot uncommitted changes to tracked files. I want a completely
clean repository before I deploy, where there are neither uncommitted changes
to tracked files, nor (new) untracked files.

But no, I did not know of git-sh-setup, thanks for the tip :-)

~~~
wereHamster
If that's your goal, it might be better to just never deploy from a checked
out repository and instead always make a new copy of the code (git clone, git
archive, download the tarball from github etc). As in, make the deploy script
do that for you, so you never even get into a situation where you could have a
dirty working tree in the first place.

~~~
brazzledazzle
You could take it a step further and setup a dead simple server that does it
for you and tracks the results in a central place for the whole team. With a
manual trigger if you so desired.

~~~
wahnfrieden
CircleCI etc are decent at this.

------
TekMol
I'm confused. How is that different from 'git status'?

~~~
oleks
It first performs a git status, then fetches changes from upstream, and checks
if all local changes have been pushed upstream (using git cherry).

~~~
TekMol
I'm curious what the workflow is here.

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.

~~~
oleks
Yes, so this is useful where deployment is "manual" in the sense that it is
not a mere git push. It is bad practice to have git data lying around among
otherwise public files, so you have to either set up git hooks on the public
server, or fine-tune your public server access rights. Both require (slightly)
more work than simply not pushing the git data in the first place.

~~~
codetrotter
> It is bad practice to have git data lying around among otherwise public
> files

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.

------
colemickens
`git status --porcelain` and `if git diff-index --quiet HEAD -- ; then ...`
might be lighter/easier ways (and include non-staged files [as well]).

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.

------
kbob
On a somewhat related note, I created check-git a few months ago. It scans a
directory tree for unclean git repositories. Maybe someone will find it
useful.

[https://kbob.github.io/2016/11/08/check-
git](https://kbob.github.io/2016/11/08/check-git)

------
kinow
Useful. Maven checks that for autpmated deployments. It delegates that part to
SCM plugins as far as I know. Wonder if this one does the same as Maven. On
mobile, but may check later (tis probably around here
[https://github.com/apache/maven-scm?files=1](https://github.com/apache/maven-
scm?files=1))

------
wiz21c
In my job I've written a small script that compares JIRA entries to what lies
into git. This I way I can spot things that were forgotten or put on the wrong
branch...

------
_ZeD_
ok, seriously, is "using git push to do a deploy" a thing? WTF?

~~~
TomMarius
What is the correct way in your opinion?

~~~
gregmac
If you have code that needs to compile, pull in packages, load configuration
or for any other reason can't just run in production from a clean checkout,
then the proper way is to go through a CI server (teamcity, Jenkins, Travis,
etc), and have a script that gets from your clean checkout to a package/zip
that runs in production.

