Is there any good reason to merge a short-term, tagged change in the software? <p>Suppose I've got some software whose last released version is 1.1. Development from there has continued on two tracks:</p> <ul> <li>Normal updates on <code>master</code></li> <li>Temporary changes meant to be released for a while as version 1.2, but not included in any subsequent versions. For example, imagine an <code>april_fools</code> branch.</li> </ul> <p>My plan is to tag the temporary code as <code>v1.2</code> and release it, but <strong>never merge it to master</strong>. This is because if I did merge it:</p> <ul> <li>I'd have to to deal with merge conflicts</li> <li>Once all was resolved, I'd want to revert all of that temporary code anyway</li> </ul> <p>Version 1.3 would be tagged and released based on the latest commit on <code>master</code> when the time came.</p> <p>This seems like the cleanest solution, but I'm a little hesitant. <strong>Should I worry about having a lineage of commits where versions 1.1 and 1.3 have no intervening commit tagged 1.2?</strong> Could this cause confusion for later developers looking at the commit history?</p>