<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Releases on Artur Rios Lab</title><link>https://lab.artur-rios.tech/tags/releases/</link><description>Recent content in Releases on Artur Rios Lab</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Wed, 21 Oct 2026 12:00:00 +0000</lastBuildDate><atom:link href="https://lab.artur-rios.tech/tags/releases/index.xml" rel="self" type="application/rss+xml"/><item><title>Git Tags: Naming the Commits That Matter</title><link>https://lab.artur-rios.tech/git/git-tags/</link><pubDate>Wed, 21 Oct 2026 12:00:00 +0000</pubDate><guid>https://lab.artur-rios.tech/git/git-tags/</guid><description>&lt;p&gt;Branches move: every commit on &lt;code&gt;main&lt;/code&gt; moves &lt;code&gt;main&lt;/code&gt; forward. Sometimes you need&#10;a name that stays where it is put, such as &amp;ldquo;the commit that went out as&#10;version 1.6.0&amp;rdquo;. That is a &lt;strong&gt;tag&lt;/strong&gt;. Tags mark releases, the build a bug report&#10;refers to, or the last commit before a large refactor, and almost every&#10;release tool, from GitHub Releases to package registries, reads them.&lt;/p&gt;&#10;&lt;p&gt;Tags look simple, and mostly are. The parts that cause trouble are the two&#10;kinds of tag, which behave differently in some commands, and the fact that&#10;tags are not pushed, fetched or overwritten the way branches are. This article&#10;covers both. The commands shown were run with Git 2.56 on 21 October 2026, in&#10;a scratch repository and in this site&amp;rsquo;s own repository. Long temporary paths&#10;in the output are left out.&lt;/p&gt;</description></item></channel></rss>