我已经阅读过this和this次讨论，但在了解GitHub上合作的最佳方式方面仍然存在问题。
假设我已经分配了一个仓库并独立开发（原始仓库已暂时没有激活）。所以我确实拥有自己的develop分支，在那里我做了所有更改：从feature分支，在那里开发然后合并回develop。我不时要向原始回购提交PR。但是我不能从feature做PR，因为它会包含develop的所有历史记录。这就是我的所作所为：
master feature挑选樱桃并将其推送到GitHub 当这些PR合并到原始仓库的master时，我从中拉出，然后将master合并到develop。
它工作得相当好，但它导致我自己的回购中相同的提交倍增，所以我不确定挑选樱桃是最好的方法吗？
来自master的分支可能会更好，但是当我完成依赖于feature-1的feature-2时，通常会出现这种情况;并且feature-1仍在等待PR合并，但尚未在master中。
我很感激任何建议和例子。
答案 0 :(得分：5)
理论上，它总是取决于你正在进行的项目，以及项目的负责人。
一般来说，只有在发布版本时才会提交，或者至少编译时没有错误。但是有些项目只是将所有东西都归为主。
真的，在我自己的项目和意见中，你的拉动请求应该被放入主项目开发分支，然后当时间到来时，来自develop的所有内容都会合并到 master < /强>
您的工作流程基本上保持不变。从开发分支以创建新的功能-X ，提交功能-X ，然后您将在上提交拉取请求特征-X 即可。一旦合并到开发，你就会把它拉下来，继续工作;或者只是将它合并到你的私人分叉上并继续工作，git应该理解。一旦项目负责人觉得项目是下一个版本，他/她就会合并成为主人。
请查看此5分钟阅读：Understanding the GitHub Flow。
答案 1 :(得分：0)
我同意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 之后我们回到掌握并重复。如果有人要求更改，我们会隐藏我们正在处理的任何内容和checkout new-branch-name，进行所请求的更改，再次执行git pull -r origin master，然后git push -f origin new-branch-name，然后checkout master和{ {1}}。有时你会进入需要进行更改的地方，在这种情况下，我们只是继续处理新的分支名称并且不在本地删除它，只能在github上或任何你使用的地方删除它。
我知道我有点打破了巴尼风格，但我不想错过任何东西。随意使用它。它对我们来说也很有效，因为我们经常交谈和合作。对于分叉的回购和prs，只要你对你所做的工作感到满意，就打开一个pr。我并不全心全意地同意整个大师，将大师分支到一个开发分支，然后分支。师父应该随时准备好，然后如果你坚持那些你不需要担心的话。此外，如果你害怕一个大公关，可以随意要求多个人审查它，并且它不必只是两个人。我们只有6个人，所以2个为我们工作。希望有所帮助。
答案 2 :(得分：0)
鉴于OP在Ryen Nelsen的回答中发表的评论：
...掌握/开发分离并不是真正的问题 - 通常我遵循gitflow范式。我感兴趣的是 - 如果我的开发工作领先于原始存储库，如何仅为feature-X发送pull-request？我使用樱桃采摘，但它是最好的方式吗？
我会问 - 你的develop分支是否优先于原始存储库（从现在开始我将master分支称为什么）是什么意思？您develop分支中的所有其他内容是什么？
听起来你正在develop完成重要的开发，而短期内不会进入master。在这种情况下，为您正在处理的每个Pull Request /问题/增强功能创建一个单独的功能分支，并将其提交给master。
如果您小心，可以最大限度地减少各个功能分支之间的差异，包括引用中讨论的相互依赖性。例如，假设您正在维护develop并尝试向master和fea1提交拉取请求{/ 1}}。
fea2和fea1，直到他们拥有您需要根据现有的fea2更改进行修改。develop和fea1开发新的修补程序，并在您认为合适的情况下合并（或rebase / squash）到fea2。在这种情况下合并，你是唯一一个在这个回购中发展的人很简单 - 你一次只能在develop，develop或fea1之一工作，所以合并真的会处理你必须要解决的冲突...... 为拉取请求做好准备后，您可以将fea2和fea1置于各自的分支中，并继续单独处理fea2。同时，当Pull请求得到反馈时，您可以随时查看develop或fea1并更新它们，可能需要从fea2合并到fea1，反之亦然，也可能需要合并新的提交以进行开发，以使其保持最新状态。
接受PR后，您可以在回购中的相应私有功能分支上清除所需的任何内容，并确保与其他分支的任何最终合并完成fea2。
然后您可以删除功能分支，但就个人而言，我会标记最后一次提交，以便将来可以根据需要返回它，然后删除分支引用。这样你可以回到一个可能比develop更接近master的提交，虽然取决于已经过了多少时间，但可能没有 - 至少你会有一个选择。例如，如果PR中的缺陷进入develop并且打开了一个新问题，您可以快速压制，但会让其他人花费更长时间，这可能会发生。