3

我已经阅读了其他一些关于合并 VS 变基、使用什么以及何时使用的问题，但对于普通 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 仍然没有什么坏处，但是如果我知道分支 A 自创建分支 B 以来没有被触及，则没有必要。我的理解是否正确？

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

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

4

2 回答 2

1

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

简而言之，你希望你的工作井井有条。使分支 A 成为分支 B 的基础将它们联系在一起。如果 A 中的某些内容不好，这可能是一件坏事，“撤消”它可能并非易事。

于 2012-06-01T19:47:11.580 回答
1

你的理解是正确的。如果什么都没有触及 A，那么你的 rebase 将是一个空操作。A 不变的好处是你知道不会有冲突！

于 2012-06-01T19:55:10.667 回答