GIT合并和rebase工作流程确认？

Question

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:

1. Create new branch B from existing branch A
2. Add/commit changes on branch B
3. Rebase updates from branch A
4. Merge changes from branch B onto branch A"

From what I understand so far, the workflow above works best when using a heirarchical branching model (ie 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?

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?

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?

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.

Thank you, Jesse Leite http://www.aurorafxstudios.com/

Answer 1

No it's not a good idea to over-use rebase. I started out that way but have done nothing but merges and resets. Take a look at my workflow . It is based on nvie's .

In short, you want to be organized with your work. Making branch A the basis for branch B ties them together. This can be a bad thing if something in A is bad, it may not be trivial to "undo" it.

Answer 2

Your understanding is sound. If nothing's touched A, then your rebase would be a no-op. The nice thing with A not changing is that you know there'll be no conflicts!