title: GIT merge and rebase workflow confirmation?
body: <p>I have read a few others' questions regarding merge VS rebase, what to use and when, but I still have some questions for regular GIT users.  Firstly, let me post what I understand to be good GIT practice:</p>
  
  <ol>
  <li>Create new branch B from existing branch A</li>
  <li>Add/commit changes on branch B</li>
  <li>Rebase updates from branch A</li>
  <li>Merge changes from branch B onto branch A"</li>
  </ol>
  
  <p>From what I understand so far, the workflow above works best when using a heirarchical branching model (i.e. A = master branch, and B = experimental branch for working on a new feature).  In short, it's good to rebase down the tree, and merge back up to the master.  Am I correct in thinking this?</p>
  
  <p>Now, if working with other developers who might be committing/merging changes to A (master branch), I would assume it's best for me to repeat steps 2 and 3 as often as I like to ensure that my work on branch B does not conflict with anything other users have been committing to branch A.  If there are any conflicts, using rebase on branch 2 would reapply my commits and allow me to work out these conflicts BEFORE merging back up to branch A.  Am I correct in my understanding?</p>
  
  <p>Lastly, here's my main question: If I am not working with any other developers, and I am not touching branch A until I've finished my new feature in branch B, can I then skip the rebase (step 3), and just merge branch B into the master branch A?  I guess it still doesn't hurt to do a rebase first, but unnecessary if I know that branch A hasn't been touched since creating branch B.  Am I correct in my understanding?</p>
  
  <p>PS. I'd like to thank you guys in advance for any guidance you can give me!  I'm new to GIT, and never used a SCM system before using GIT.</p>
  
  <p>Thank you,
  Jesse Leite
  <a href="http://www.aurorafxstudios.com/" rel="nofollow">http://www.aurorafxstudios.com/</a></p>