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系统。

谢谢你，Jesse Leite http://www.aurorafxstudios.com/

Answer 1

不，过度使用rebase不是一个好主意。 我这样开始但除了合并和重置之外什么也没做。 看看我的工作流程 。 它基于nvie的 。

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

Answer 2

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