title: Git: Merging a new commit back to master, made against a very old commit
body: <p>I've got a project in git where everything is being done directly on the master branch, with tags being used to mark released versions of the code.
  I'm aware that this is not ideal and have been looking at git flows such as this one: <a href="http://nvie.com/posts/a-successful-git-branching-model/" rel="nofollow">http://nvie.com/posts/a-successful-git-branching-model/</a> - However, even using a better setup, I can't easily see a way that a 'hotfix' could be applied to an previous release of the project and committed back to the master branch...</p>
  
  <p>The git repo I'm using has a remote origin and currently just myself and one other developer have clones of it.
  The master branch log looks something like this right now:</p>
  
  <pre><code>master: A--B--(C)--...--F--G
  </code></pre>
  
  <p>Commit C is tagged as a release point e.g. "v0.2" and I want to change that code base.
  I can checkout refs/tags/v0.2 into a new local branch and commit a change to a file (e.g. Main.java in this case), and even tag that commit (Commit H tagged as 'v0.3')</p>
  
  <pre><code>master: A--B--(C)--D--...--F--G
  v0.2  :        C--(H)
  </code></pre>
  
  <p>But really, I don't want to have a branch hanging around for each version - I just want relevant tags along the master branch. Having tagged commit H as 'v0.3', if I try to delete branch 'v0.2' I get:</p>
  
  <blockquote>
    <p>'error: The branch 'v2' is not fully merged. If you are sure you want
    to delete it, run 'git branch -D v2'</p>
  </blockquote>
  
  <p>Okay, so it's not merged back to master but the edited part of Main.java doesn't even exist any more in the latest version, so is this a problem?</p>
  
  <p>I think I can still delete the branch with '-D' and not lose the commit because the commit is still referenced by a tag.</p>
  
  <p>Doing this on a scratch repo and then running 'git log --graph --all' from the master branch shows me:</p>
  
  <pre><code>* Commit I
  |
  * Commit G
  ...
  |
  * Commit D
  |
  |  * Commit H
  |/
  * Commit C
  ...
  |
  * Commit A
  </code></pre>
  
  <p>What problems might I encounter if I leave the history as above?
  If not can anyone suggest the best-practice approach to handling this scenario please?</p>
  
  <p>I hope I'm not over-thinking this :-)  Any suggestions much appreciated.</p>