Package: git-release-tag
git release tagsemantic versioning support for components in git repositories.With the advent of continuous integration and continuous delivery, every commit to the source code repository delivers
a new version of the software. The git source code repository system uses a 40 character long revision number, which
very accurately point at a specific version of the source code. However, these revision number are hard to read
for humans. This tool allows you to combine the best of both worlds: human readable version numbers while still being
able to uniquely identify a specific commit of the source code.How do I use this?First you initialize the release configuration as follows:git-release-taginitialize--initial-release1.0.0--tag-prefixv.
>>INFO:commitchangesto.releasein.
>>INFO:release1.0.0of.taggedbyv1.0.0This will add a file  called.releaseto the repository. It contains both the release and tag of the component
and place the tag.Now you can show the current version of the source code:git-release-tagshow>>1.0.0If you have outstanding changes in your workspace, the version is appended with the first 8 digits of the git revision number anddirty:git-release-tagshow
>>1.0.0-81aca04e-dirtyIf you commit changes to the repository, the version just shows the commit indicating a new version of the componentgit-release-tagshow
>>1.0.0-63a8d99bumping the versionIf you want to release the latest commit as a new version, type:git-release-tagbump--levelpatch>>INFO:commitchangesto.releasein.
>>INFO:release1.0.1of.taggedbyv1.0.1If there are no changes since the last version. bump with not change anything:git-release-tagbump--levelpatch>>INFO:.hasnochangessince1.1.1.multiple components in a single repositoryIf you have multiple components in a single repository, initialize the repository as follows:git-release-taginitialize--initial-release1.0.0uibackend.
>>INFO:commitchangesto.releaseinui
>>INFO:release1.0.0ofuitaggedbyui-1.0.0
>>INFO:commitchangesto.releaseinbackend
>>INFO:release1.0.0ofbackendtaggedbybackend-1.0.0
>>INFO:commitchangesto.releasein.
>>INFO:release1.0.0of.taggedbyapi-1.0.0When you want to release a new version of the component, type:git-release-tagbump--recursive--levelpatch.>>INFO:commitchangesto.releasein./ui
>>INFO:release1.0.1of./uitaggedbyui-1.0.1
>>INFO:./backendhasnochangessince1.0.0.
>>INFO:commitchangesto.releasein.
>>INFO:release1.0.1of.taggedbyapi-1.0.1As you can see, the ui now has version 1.0.1, the backend version is unchanged and the applicationhas bumped to 1.0.1  too, because of the changes to the ui.dependencies between multiple components in a single repositoryWhen you need to bump the version of a component when there are changes in other components in the
same repository, specify the dependency in the fieldtag_on_changes_inin the .release file.So let's say that the UI always has to change when the api changes, change the .release as follows:release=1.0.1
tag=ui-1.0.1
tag_on_changes_in=../apiNow, when there are changes in the ../api directory with respect to the tag in the ui directory,
a new release will be created.validating your configurationAs tags are not part of the commit, it sometimes happens that somebody forgets to push the tags along with the
commits. To validate the integrity of your release configuration, type:git-release-tagvalidate--recursive.
>>INFO:okIt reports an error if the configuration:references tags which are not in the repository.use the same tag for different components.including the current version in your applicationTo include the version of the release in the source code you can add a pre-tag-command to your configuration. This
is a command that is executed before the changes are committed.git-release-taginitialize\--initial-release1.0.0\--tag-prefixv\--pre-tag-command'sed -i "" -e "s/version=.*/version=\"@@RELEASE@@\",/g" setup.py'\.
>>INFO:commitchangesto.release,setup.pyin.
>>INFO:release1.0.0of.taggedbyv1.0.0The content of setup.py now reflects the released version and is included in the commit:grepversion=setup.py
>>version="1.0.0",installing the utilityTo install the utility, type:pipinstallgit-release-taginspired by native git describeIf you use a single git repository for each deliverable that you produce in the build process, you may usegit-describeinstead. How does it work? Well you create a tag on a particular commit, and then type:gittag1.0.0
gitdescribe--tags--dirty
>>1.0.0If you add something to the repository, it will append the number of commits since the tag and first 8 digits of the
revision number:gitdescribe--tags--dirty
>>1.0.0-1-g6123dd2If you have uncommited changes in the staging area, it will appenddirtyto it:gitdescribe--tags--dirty
>>1.0.0-1-g6123dd2-dirtyIf you commit your changes and place a new tag it show a clean tag again. git-describe does not work for the situation
where you have multiple artifacts in a single repository.