Git工作流程，可以从并行分支中提取[关闭]

Question

我所指的场景是，我在分支 A 中处理一个功能，而我的同事在分支 B 中处理另一个功能。当我工作时，我意识到 B 的一些变化会对我有很大帮助，但是因为它正在进行中，我不确定是否应该从 A 中的分支 B 拉出。

我的问题是：

1. 从分支 B 拉取是否有任何缺点（或者是否甚至建议从除开发之外的其他分支拉取）？
2. 我意识到我现在必须与开发和分支 B 同步，所以下次我想要最新的更改时，我需要从两者中提取。有没有办法自动做到这一点？如果我的分支依赖于 2 个以上的分支怎么办？
3. 除了等待分支 B 合并开发之外，还有更好的方法吗？

我想在大多数情况下，只需挑选一些提交就足够了，但有时你只需要整个分支。

Answer 1

在 git 中有很多方法可以做到这一点——比如 eftshift0 在他们的回答中建议的。但是您专门询问了 gitflow。所以让我们考虑到这一点。请注意，没有法律规定您必须遵循 gitflow，或者您的团队不能选择在 gitflow 上发明一些更适合您自己需求的变体；但这应该是经过深思熟虑的团队讨论，您不仅要关注您从更改中获得的收益，还要关注它们所付出的代价。

从分支 B 拉取有什么缺点（或者甚至不建议从开发之外的其他分支拉取）？

是的。将分支 B 拉入分支 A 后，如果将分支 B 合并到 dev 中，您将携带一组不完整的分支 B 的更改，这可能会导致 dev 上的状态中断。这违背了您应该能够随时从 dev 创建发布分支的想法。

将分支 A 重新定位到分支 B 具有相同的缺点。

如果在将分支 A 合并回 dev 之前，可以确保将分支 B 合并回 dev，则可以缓解这种情况；这可能会或可能不会破坏将分支 B 早期集成到分支 A 的目的。这并不是说没有办法处理它。但是将一个故事分支拉入（或以其他方式合并）另一个故事分支通常会带来风险。

我意识到我现在必须与开发和分支 B 同步，所以下次我想要最新的更改时，我需要从两者中提取。有没有办法自动做到这一点？如果我的分支依赖超过 2 个分支怎么办？

其中包含一些假设，但如果我们坚持您的前提：不，没有一种简单的方法可以设置分支以跟踪多个其他分支。您可以尝试编写脚本，但这样的脚本可能容易出错。潜在的问题是，如果可能发生冲突，那么您必须一次合并一个分支并在开始下一个合并之前解决每个合并（这是一个手动过程）。如果分支 A 与分支 B 纠缠到足以让这个对话发生，那么冲突是可能的。

现在，您想要跟踪分支 B 的想法......为什么？您依赖分支 B 已经编写的代码的情况已经是边缘情况；如果您依赖分支 B 正在进行的工作，那么您应该考虑在分支 A 上处理故事是否为时过早。（至少 gitflow 没有设置为同时处理这些相互交织的故事；即使在持续集成模型中我会怀疑这是否是个好主意。）

更一般地说，听起来您将功能分支视为需要计划维护的长期实体。理想情况下，应该避免这种情况，或者最多是一种例外情况。

除了等待分支 B 合并开发之外，还有更好的方法吗？

据我所知，gitflow 分支策略并不能真正解决您所说的情况。也许它假设功能分支将足够细化以至于不会出现（或者至少在另一个故事完成之前阻止一个故事不会太麻烦），或者您的流程应该为您提供一种方法躲开它。我想他们甚至有可能在开发/记录模型时没有考虑这种可能性。但无论如何，我见过的任何文档都没有给出好的答案。

如果您不能等待分支 B，那么下一个最佳解决方案是从分支 B 有选择地复制如果分支 B 不存在，您将在分支 A 中所做的更改。这可能需要git cherry-pick。 （我经常将 cherry-pick 称为 git 中最被过度推荐的命令，但这是它实际上非常适合的用例之一。）

如果您想要的更改与任何其他更改分开提交，则效果最佳。在这种情况下，您可以简单地挑选那些提交到您的分支。如果更改与其他提交混合在一起，那么您应该考虑更具选择性 - 例如使用cherry-pick -n，然后只暂存和提交您需要的更改。

请注意，当您将两个分支集成回 dev 时，这可能会导致合并冲突。好消息是，合并的两个“边”通常是相同的，因此它们可能会自动解析。

Answer 2

这是可行的，但需要巧妙地实现它而不会搞砸。所以...我的第一个建议：保持您的更改 笔直（不要合并）并放在一起，以便以后在需要时轻松移动它们。因此，首先，我们将分支 A 移到分支 B 的顶部（这样您就可以继续在分支 A 的顶部工作，即您的分支）：

git rebase --onto=branchB your-base-branch branchA # base branch is origin/main or whatever

所以，现在您可以继续在 branchA 上工作...现在，假设 branchB 的开发人员 rebased 他的分支......这是您需要的时候之一小心：

git rebase --onto=branchB old-branchB-position branchA

这是为了让您的更改可以设置在 branchB 的新位置之上。但我看到问题来了：为什么不直接运行git rebase branchB？ BranchB 不是您的责任....开发人员可能已将其破坏得面目全非，并且可能与您最初获得的 原始 branchB 没有任何相似之处的...所以你需要格外小心不要在你重新设置你的分支时移动那些原始修订。