如何在依赖于另一个尚未合并的 git 分支的新 git 分支上工作？

Posted 2023-02-19

【中文标题】如何在依赖于另一个尚未合并的 git 分支的新 git 分支上工作？

【英文标题】：How does one work on a new git branch that depends on another git branch that is not yet merged?

【发布时间】：2012-02-16 07:33:40

【问题描述】：

这是我的场景：

我的项目遵循主题分支模式。

我创建了一个分支来修复一些问题，我们称这个分支为problem_fixes。我进行了更改，并提交了拉取请求。

我需要开始开发一个新功能，因此我创建了第二个名为 my_feature 的分支并提交了一系列更改。

在某些时候，我意识到 my_feature 依赖于尚未被接受和合并的问题修复（my_feature 分支依赖于第一个分支的一些修复，没有它们我无法取得进展）。

没有纠缠我的项目导致更快地接受和合并我的第一个分支，这里遵循的最佳流程是什么？

我想知道是否需要基于 issue_fixes（而不是 master）启动一个新的第三个分支并将我的提交合并到 my_feature？或者，如果我只是将问题修复合并到 my_feature 并继续工作，是否可以 - 假设问题修复首先合并到主库，当 my_feature 合并时理论上应该没问题（？）

【问题讨论】：

我认为你的问题更适合programmers.stackexchange.com

@Theo：我不这么认为。根据常见问题解答，这个问题是关于“程序员常用的软件工具”。

嗯，我讨厌 stackexchange。碎片化ftw。感谢您的指点，尽管我会检查一下。 （编辑：*** 上的类别会让我比附属的一组独立网站更快乐）

因为这不是编程问题，而是编程方法问题。这没什么大不了的，它可能也会在这里得到一个很好的答案，我只是认为它更适合程序员。

【参考方案1】：

从第一个分支创建您的主题分支。只要将第一个合并到 master 中，您就可以在此基础上进行 rebase，并且假设没有进行太多更改，这应该不是问题。

如果第一个分支的提交未更改，您的新分支将整齐地堆叠在其之上，并且如果提交更改（压扁、编辑或其他），您始终可以对第二个分支进行交互式变基，并且合并第一个分支后对其进行编辑以使其看起来不错。

【讨论】：

看起来我有两个答案似乎可以解决我的问题。格雷格首先回答，并用稍微多一点的分步说明标记为答案，但投票给了你。如果可以的话，我会给你 +2 以迫使我学习变基——这是一个非常重要的 git 概念。

总是选择变基。合并提交没有帮助。

【参考方案2】：

是的，我认为您走在正确的轨道上。我要做的是创建一个新的my_feature 分支，也许工作一点。当我意识到my_feature 依赖于problem_fixes 时，合并该分支。如果你知道你需要它，这可能会立即发生。然后，当 my_feature 合并到 master 中时，您就已经有了所需的更改。

请注意，只要您有健全的代码审查程序，那么如果您尝试在 problem_fixes 之前将 my_feature 合并到 master 中，那么您会在那个时候注意到。

【参考方案3】：

在我从master 开始工作的情况下，然后意识到我需要来自另一个无法合并的分支的一些更改，因为它仍然有一些破坏性的东西 （但我需要的东西已完成） 在这种情况下我会做的可能是

将他们的分支合并到我的分支中

完成我的功能

等待其他开发者完成他的功能

它们合并到master

我挑选我的提交期待合并提交到master

你们认为，这可能是摆脱一个特别痛苦的情况的一种方法，尽管它涉及到挑选樱桃，大多数人认为这是一种痛苦，就像变基一样。