Git tag release build files and reset to commit without

Question

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?

Answer 1

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.