title: Tutorial on the life-cycle of a forked GIT repository while using remote tags
body: <h2>Disclaimer</h2>
  
  <p>I'm a bit new to GIT so please excuse me if I have this ting entirely wrong. I've been using Subversion for a very long time and see the huge benefits of GIT and am actively trying to make the switch. However, I've come up with this issue which I can't seem to find a good tutorial or how-to on.  That is the proper use of upstream tags.</p>
  
  <h2>What I've Done</h2>
  
  <p>My example is with github.com hosted repository, redmine. It contains many tags for stable releases and branches and a current running master.</p>
  
  <p>I've forked it on my own system by issuing </p>
  
  <pre><code>cd /srv/git-repos
  git clone --mirror https://github.com/redmine/redmine.git redmine.git
  </code></pre>
  
  <p>I've then cloned my local fork by doing the following</p>
  
  <pre><code>cd /opt
  git clone /srv/git-repos/redmine.git
  </code></pre>
  
  <p>Then I followed the github.com instructions of adding a remote upstream by</p>
  
  <pre><code>cd /opt/redmine
  git remote add upstream https://github.com/redmine/redmine.git
  </code></pre>
  
  <p>Cool, at this point I have a forked copy of the redmine on my system which I can commit and push and pull from. I also have added the real redmine as upstream which I can also pull from.</p>
  
  <p>So the first thing I want to do is get this new repo at the state that my current install is running.</p>
  
  <p>Seems easy enough:</p>
  
  <pre><code># Checkout the older tag I'm on
  git checkout v1.1.0
  
  # Add a plugin as a submodule
  git submodule add git://github.com/delaitre/redmine_time_tracker.git vendor/plugins/redmine_time_tracker
  git submodule update --init --recursive
  </code></pre>
  
  <p>Now I want to commit this to my fork (I'm pretty sure I've already gone wrong)</p>
  
  <pre><code>git commit -m 'Added a new submodule'
  </code></pre>
  
  <h2>Where I'm At</h2>
  
  <p>Awesome! I'm now back where I started from not using git, but everything is versioned and safe and hopefully easier to manage.</p>
  
  <h2>The problem</h2>
  
  <p>The whole point of this is I wanted to be safe before upgrading to a new version (v1.4.0) which is a tag upstream.</p>
  
  <p>So, how do I switch to the new tag on upstream while keeping the commits I've made to my local fork?</p>
  
  <p>I said above (I think I already went wrong). From some additional reading I think I should have branched the remote tag some how and been committing to a new branch based off the remote tag. This is because I'm sure right now I'm in a "detached HEAD state" which is apparently bad.</p>
  
  <h2>Looking For</h2>
  
  <ol>
  <li>How do I branch from a tag.</li>
  <li>What is the best practice for naming this "branched tag" (e.g. _v1.2.0 , my_v1.2.0, local_v1.2.0)
  <ul>
  <li>Am I being overly anal and who gives a crap what it's named?</li>
  </ul></li>
  <li><strong>Next Step</strong>: How do I merge in the new remote tag (i.e. v1.4.0)</li>
  <li>How do I commit this new merged in tag, etc.</li>
  </ol>
  
  <h2>Conclusion</h2>
  
  <p>Am I completely off base, nuts, flat-out wrong, or missing the point? Is this an uncommon scenario? Am I missing out on documentation on how to do this?</p>