git - GitHub 上 Pull Requests 的最佳实践

Question

我读过 this和 this讨论，但仍然难以理解在 GitHub 上协作的最佳方式。

假设我 fork 了一个 repo 并独立开发了它(原来的 repo 已经有一段时间没有事件了)。所以我有自己的 develop 分支，我在其中进行所有更改:从 feature 分支，在那里开发，然后 merge 回 develop。有时我想向原始 repo 提交 PR。但是我不能从 feature 做 PR，因为它将包括 develop 的所有历史。这就是我所做的:

• checkout master 跟踪原始 repo
• 它的分支
• 从 feature 中挑选并推送到 GitHub
• 提交 PR

当这些 PR merge 到原始仓库的 master 时，我从中提取，然后将 master merge 到 develop。

它工作得很好，但它会导致我自己的 repo 中的相同提交成倍增加，所以我不确定这里是否是最好的选择？

从 master 分支可能会更好，但经常会出现依赖于 feature-1 的 feature-2 的情况； feature-1 仍在等待作为 PR 被 merge ，但还没有在 master 中。

如果有任何建议和示例，我将不胜感激。

Answer 1

理论上，它始终取决于您正在从事的项目和项目负责人。

一般来说，只有当它是一个发布版本，或者可以至少编译没有错误的东西时，你才会提交 master。但是有些项目只是把所有东西都扔给 master。

真的，在我自己的项目中，你的 pull 请求应该放在主要项目的 develop 分支中，然后在适当的时候，将 develop 中的所有内容 merge 到 ma​​ster.

您的工作流程基本上会保持不变。从 develop 分支创建一个新的 feature-X，提交给 feature-X，然后您将在 上提交 pull 请求特性-X。一旦 merge 到 develop 中，你就会把它 pull 下来，然后继续工作；或者只是将它 merge 到你的个人分支上并继续工作，git 应该理解。一旦项目负责人认为项目处于下一个版本中，他/她就会将 develop merge 到 master。

看看这个 5 分钟的阅读:Understanding the GitHub Flow .