# Git tag release build files and reset to commit without

This is part of a library that wants to release builded files (eg dist/*) when published to npm and bower. However, I don't want to commit those builded files for obvious reasons. Bower uses tags, and so I need tag to hold a version that contains builded files.

I didn't think twice, and that's what I came up with:

#!/bin/bash
[[ '' == $1 ]] && echo "Please provide patch, minor, major argument" && exit 1 # build dist files gulp # use npm to get the next semver (ie npm version patch increments patch number) # --no-git-tag-version is to avoid any git interactions newver=$(npm --no-git-tag-version version $1) # dist files are ignored, adding them with the updated package.json git add -f dist package.json # commit and tag the new version with dist files git commit -m$newver
git tag $newver # publish on npm npm publish # reset the latest commit git reset --hard HEAD~1 # issue the npm command again so that package.json gets updated newver=$(npm --no-git-tag-version version $1) # only add the package.json, dist files are gone git add package.json # commit and push tags git commit -m$newver
git push --tags
git push


I'm wondering if this would be considered as a bad-practice, if there is something I could improve, or if someone has a better idea on how to do this. It's working great, but is having a tag that refers to an overridden commit a good idea?

It's a very nicely written script.

It's working great, but is having a tag that refers to an overridden commit a good idea?

It doesn't sound great, but I don't have a better idea either. In any case, I don't see any harm in doing this. The content of these commits don't pollute the history because they are not really part of it.

If repository storage becomes a problem later, you can always wipe out the obsolete tags. (As you mentioned in a comment, this might not be such a good idea if package managers (like bower) rely on git tags for dependencies...)

### Error handling

What if gulp fails? The script will happily go ahead and publish something broken or half-baked. It would be good to add some error handling here, for example:

if ! gulp; then
echo "Fatal: gulp failed, aborting..."
exit 1
fi


### Code duplication

This line appears twice:

newver=$(npm --no-git-tag-version version$1)


As it's a non-trivial command, it would be good to put it in a function, for example:

set_newver() {
newver=$(npm --no-git-tag-version version$1)
}


### Naming

It's good to give command line parameters a proper name early on, and refer to them by that name throughout the script, instead of a meaningless \$1. For example version.

This may be subjective, but I find newver a bit awkward, and perhaps npm_version would be better. I leave that up to you.

• "you can always wipe out the obsolete tags" This is not a good idea if package managers (like bower) rely on git tags for dependencies. – soyuka Jul 6 '16 at 19:53
• Hm, ok, I see your point... Scratched that out, and added your comment. – Stop ongoing harm to Monica Jul 6 '16 at 19:59