GitHub上Pull Requests的最佳实践

Question

GitHub上Pull Requests的最佳实践

11

我已经阅读了这个和这个讨论，但我仍然难以理解在GitHub上合作的最佳方式。

假设我已经fork了一个repo并独立开发它（原始repo已经有一段时间没有更新了）。所以我有自己的develop分支，在那里进行所有更改：从feature分支开始，进行开发，然后将其合并回develop。不时地，我想向原始repo提交PR。但我无法从feature分支中提交PR，因为它会包含整个develop历史记录。所以我做的就是：

切换到跟踪原始repo的master
从它进行分支
从feature中挑选需要的代码，并将其推送到GitHub
提交PR

当那些PR被合并到原始repo的master中时，我从中拉取，然后将master合并到develop中。

它运行得相当好，但它会导致在我自己的repo中重复相同的提交，因此我不确定cherry-pick是否是最佳选择？

也许从master分支开始会更好，但通常有这样一种情况：我已经完成了依赖于feature-1的feature-2；而feature-1仍然等待作为PR合并，但尚未被合并到master中。

我将感激任何建议和示例。

- Vladimir

不算是一个答案，但这也是我一直在使用 pull request 的方式。如果你自己的 repo 比 upstream 要领先，你就需要从 upstream 的主分支上创建一个分支，以避免拉取所有的更改。我还使用 cherry-picking 在我的 fork 和 Pull Request 的分支之间移动更改。 - nwinkler

3个回答

2

我同意Ryen的观点，这取决于项目的具体情况。

在我的工作中，我们已经制定了一个非常好的系统，我们都同意采用。

从最新的主分支开始。
进行开发或特性工作。
git add -p（针对你的更改）或 git add <filename>（针对新添加的内容）。
git checkout -b new-branch-name
git commit -m "whatever you feel should be said"
git pull -r origin master
git push origin new-branch-name
打开一个PR并等待2个批准。
合并到主分支。
删除new-branch-name。

之后我们只需回到主分支并重复操作。如果有人请求更改，我们会将正在进行的工作隐藏起来，然后 checkout new-branch-name，进行所请求的更改，再次执行 git pull -r origin master，然后执行 git push -f origin new-branch-name，接着 checkout master 并执行 git stash pop。有时您可能需要所做的更改，这种情况下我们只需继续在新的分支上工作，并且不会在本地删除它，仅在 github 或您使用的其他平台上进行删除。

我知道我有点像小学老师一样解释了，但我不想遗漏什么。随意使用它。这对我们来说也非常有效，因为我们经常交流和协作。至于forked repos和prs，只要你满意自己所做的工作，就随时打开一个pr。我并不完全同意整个从主分支分叉到dev分支，然后再从那里分支的做法。Master应该随时准备好生产，如果你坚持这些prs，就不需要担心了。此外，如果你害怕一个大的pr，请随时要求多个人审查它，而且不仅仅是两个人。我们只有6个人，所以2个人对我们来说已经足够了。希望能帮到你。

- Richi Jeffery

0

根据OP在Ryen Nelsen的回答中发布的评论：

...主/开发分离并不是真正的问题 - 通常我遵循gitflow范例。我感兴趣的是 - 如何仅为feature-X发送pull-request，考虑到我的develop比原始存储库要先进得多？我使用cherry-picking，但这是最好的方法吗？

我想问一下，你所说的develop分支比原始存储库（我从现在开始称之为master分支）要先进得多是什么意思？你的develop分支中还有其他东西吗？

听起来你正在完成重要的开发工作，但短期内不会进入master。在这种情况下，为每个将提交给master的Pull Request/issue/enhancement创建一个单独的功能分支。

如果你小心谨慎，你可以最小化你的各种特性分支之间的差异，包括引用中讨论的相互依赖关系。例如，假设你正在维护develop并尝试向master提交fea1和fea2的拉取请求。

设置两个特性分支，从主分支创建并从开发分支 使用樱桃选取或变基 到 fea1 和 fea2 直到它们拥有您需要的来自现有 develop 更改的基础。如果存在相互依赖关系，这意味着您将在每个特性分支上樱桃选取一些相同的提交，或者最终会开发新代码，在两个特性分支之间合并或变基。为 fea1 和 fea2 开发新修复程序，并根据需要合并（或重新基于/压缩）到 develop。在这种情况下进行合并，因为您是唯一在此repo中进行开发的人，所以很简单-您一次只能处理develop、fea1或fea2中的一个，因此合并实际上将处理您必须解决的冲突。

一旦准备好了拉取请求，您可以将fea1和fea2保留在它们自己的分支中，并继续单独在develop上工作。同时，随着拉取请求获得反馈，您始终可以检出fea1或fea2并更新它们，可能需要从fea1合并到fea2或反之亦然，并且还可能需要将新的提交合并回develop以使其保持最新状态。

一旦PR被接受，您可以清理您存储库中相应的私有功能分支上需要的任何内容，并确保对其他分支和develop的任何最终合并都已完成。

然后你可以删除功能分支，但个人而言，我会标记最后一次提交，以便将来需要时可以回到它，然后删除分支引用。这样，您可以返回到一个提交，该提交可能比develop更接近master，尽管取决于经过了多长时间，也许不是-至少您会有选择。例如，如果您的PR中存在缺陷，并且新问题已打开，您可以快速解决，但其他人需要更长时间。

- LightCC

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Ryen Nelsen · Accepted Answer

理论上，这取决于你正在工作的项目和项目负责人。

一般来说，只有在发布版本或可以至少编译无误时才将代码提交到主分支(master)。但是有些项目会把所有东西都提交到主分支(master)。

在我自己的项目和观点中，您的拉取请求应该放置在主项目develop分支中，然后在合适的时候，从develop合并到master。

您的工作流程基本上保持不变。从develop创建新的feature-X分支，提交到feature-X，然后在feature-X上提交拉取请求。一旦合并到develop，您就可以将其拉下来继续工作；或者只需将其合并到个人分支并继续工作，git应该能够理解。一旦项目负责人认为项目处于下一个版本，他/她就会将develop合并到master。

阅读这篇5分钟的文章：了解GitHub Flow。