2

我正在 GitHub 上开发一个开源项目，我们已经就一些规则达成了一致（列出相关规则）：

  • 合并到 master 将由 Pull Requests 完成。
  • 每次合并到master必须至少有两个人“触摸”。
  • 每个新功能都将在适当命名的分支上实现。

我遇到的一个真实案例如下：

  1. 出现了对功能 A 的需求。
  2. 我创建了一个分支a并在那里实现了它。
  3. 我已经从分支提出了一个拉取请求a到master，但现在没有人审查它。

我遇到的问题是我想处理另一个功能 B。但是，功能 B 需要存在功能 A 的更改。我应该如何继续存储功能 B 的源代码？

我的想法是：

  • 在分支处创建一个标记a，标记 A 实现的结束。
  • b从那里分支a并进行进一步的更改。
  • b直接从它分支master并结帐a。

我对 Git 不是很有经验，我认为上述所有问题都可能存在我不知道的问题，也许还有其他方法可以理智地管理它。对于我遇到的问题，最好的解决方案是什么？

a注意：在我完成实现 B 之前，很有可能会合并到 master 中。

4

3 回答 3

1

我认为这：

从 a 分支 b 并在那里进行进一步的更改。

是合理的。您仍然可以自行合并 a 。稍后，当将 b 合并到 master 时（在合并 a 之后）应该没有不必要的冲突，并且如果您决定想要 b 而不是 a（或来自另一个分支的替代实现），您可以修复它“足够好“通过变基。

于 2013-07-19T18:53:17.710 回答
1

最自然的方法是A从这里分支并开始你的工作：

  • 如果拉取请求按原样被接受，您可以继续工作流程，就像您从master;分支一样。
  • 如果分支A已被修改，您可以A在提交审核之前将您的工作基于新版本；
  • 如果分支被删除，您可以处理所需功能的新实现，并在新功能准备好后A从中挑选。BA
于 2013-07-19T18:53:59.090 回答
0

如果我忽略您使用 Git 的事实，我会说这类似于 Bazaar 管道的含义。所以，考虑到相似性，我会简单地从特征 A 分支中分支出另一个分支。

更新

集市管道基本上是绑在一起的分支。管道中管道的顺序很重要。重点是能够将单个要素作为多个补丁并行处理主线，并能够传播管道方向的变化。在您的情况下，管道将是 master -- feature-A -- feature-B。稍后，即使管道（功能分支）本身包含许多更改集，您也可以将每个功能折叠为单个更改集。

它与您的情况不同，但它足够相似，特别是因为 B 依赖于 A，我说从 A 分支到实现 B。

于 2013-07-19T18:53:03.680 回答