git - 在新分支中使用挂起的分支更改的正确过程

Question

您提交一个 pull 请求以将 Branch A merge 到 master 中。

虽然这是待处理的(大约 1 小时)，并且您想在等待期间使用分支 A 的待处理功能，但您可以创建 Branch B

Branch B 应该是 Branch A 的分支吗

或者 Branch B 应该是 master 的分支，然后 merge Branch A

Answer 1

简答:使用另一个 pullrequest 可能很危险。你仍然可以开发你的 B 功能，有两种方法可以做到这一点:

• 在 A 分支中开发它并更新您的原始 pull 请求，以便它包含这两个功能，或者
• 在临时分支(可以是任何你喜欢的地方)中开发它，但在 merge A 到 master 之后将你的工作重新设置到该 merge 上。

长答案:

这里要注意的一件事(但不是唯一的)是 criss-cross merge .它可能会导致冲突解决问题，有时甚至会默默地恢复一些更改。 (Git 声称对这种情况进行了一些特殊处理，但我不知道它有多好。)即使在简单的情况下也可能发生这种情况，步骤如下:

• 从主提交 a0 创建分支 A
• 代码特征A
• merge A 和一些后来的主提交 b0 并在那里创建分支 B
• 代码特征B
• 在 pull 请求 merge 期间将 A merge 到 master
• 现在 B 与 master 的 merge 将是交叉的:

您可以解决这个确切的问题。例如，您可以将 master merge 到 A，将其推进到该 merge ，然后开始分支 B。那么后续 merge B就不会出现cross-cross:

但是还有更多可能出现的问题。您可以有多个 B 分支。您可以有多个 A 分支。您可能需要在审查后更新 A，而您已经在执行 B 功能。 A 可能根本不正确，应该以其他方式完成，或者根本不这样做。您可能会尝试分析每种情况下的修订图并预测可能出现的问题。但是，如果您在团队中工作，您可能需要一个简单的策略来防止可能出现的问题。许多团队采用的这种策略的最简单情况是，他们不使用彼此重叠的功能分支，而是从某个主提交开始所有功能分支。