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

Question

我已经阅读了其他几个关于合并VS rebase，使用什么以及何时使用的问题，但我仍然对常规GIT用户有一些疑问。首先，让我发布我理解为优秀的GIT实践：

1. 从现有分支A
创建新分支B.
2. 在分支B上添加/提交更改
3. 来自分支A的重新更新
4. 将分支B的更改合并到分支A“

据我所知，到目前为止，上述工作流程在使用分层分支模型时效果最佳（即A =主分支，B =实验分支，用于处理新功能）。简而言之，最好重新树下树，然后合并回主人。我是否正确地想到这一点？

现在，如果与其他可能正在提交/合并A（主分支）的开发人员合作，我认为我最好经常重复步骤2和3，以确保我在分支B上的工作与其他用户提交分支A的任何内容都没有冲突。如果有任何冲突，在分支2上使用rebase会重新应用我的提交并允许我在合并回分支A之前解决这些冲突。我在我的理解？

最后，这是我的主要问题：如果我不与任何其他开发人员合作，并且在我完成分支B中的新功能之前我没有触及分支A，那么我可以跳过rebase（步骤3），并将分支B合并到主分支A？我想首先做一个rebase仍然没有坏处，但是如果我知道自创建分支B后没有触及分支A，那就没有必要了。我的理解是否正确？

PS。我想提前感谢你们给我的任何指导！我是GIT的新手，在使用GIT之前从未使用过SCM系统。

谢谢你， 杰西莱特 http://www.aurorafxstudios.com/

Answer 1

不要过度使用rebase不是一个好主意。我这样开始但除了合并和重置之外什么也没做。看看my workflow。它基于nvie's。

简而言之，您希望按照自己的工作进行组织。使分支A成为分支B的基础。如果A中的某些内容很糟糕，这可能是件坏事，“撤消”它可能并不容易。

Answer 2

你的理解是合理的。如果没有任何东西触及A，那么你的rebase将是一个无操作。 A不变的好处是你知道不会有冲突！