我正在寻找一个清晰，简单和最佳的策略来处理公共项目，其中包括：
最佳我指的是最少步数，最重要的是 -
最大程度的自动化和创建冲突的可能性极小。
在我的设置中，我正在我的本地dev分支机构工作。假设我已经准备好接受拉取请求了。我有什么步骤，有什么规则可以避免麻烦？
我首先需要确保我最近的commits在当前历史记录之上。因此，除了最近的公共变更之外，我需要rebase我的新提交。我不希望merge避免额外的merge commit，这不符合公众利益：
git rebase origin / master dev
现在我的新commit历史记录很简洁，位于最新的公共master分支之上。我无法push直接向公众origin发送，因为我没有写入权限。相反，我将它推送到Github上的分叉远程存储库。但问题是：
我应该推送哪个远程分支？
问题是干净的历史记录 - 我希望远程分支与我的本地dev完全相同。因此，最佳候选人似乎是从origin/master克隆的新功能分支：
在Github上做任何简单的方法吗？
origin/master的确切副本，因为我的新分支说new-feature-x。我需要将其更新为我本地dev分支的精确副本：最简单，最可靠的方法是什么？
new-feature-x，我可以提交给origin回购的拉取请求。假设（并且希望）没有任何冲突，那么这一步很容易。如果对上述问题有良好的答案，那么这将是一个完美的策略。
感谢任何帮助！
EDIT。
许多来源都提到A successful Git branching model。但是，这似乎不适合有许多合作者的公共项目。公共项目可能甚至没有development分支或类似的东西。无限期地在我的本地仓库中拥有这样一个分支可能是一个痛苦的更新它与任何拉动请求被接受/修改/拒绝等等。
此外，此模型建议保留所有合并记录。但我的内部合并对公众没用，只会增加不必要的开销。如上所述，我想使用干净历史记录制作一个Pull请求，以使维护者的工作尽可能简单。
我发现以下命令在任何push：
git pull --rebase upstream master
我在这里使用名为＆＃34;上游的remote＆＃34;对于公共回购（和＃34;起源＆＃34;对于我自己的分支）。
此命令将拉出公共repo主分支的当前状态，并将其与我即将提交的本地功能分支同步以获取请求。如果有任何冲突，我可以在这个阶段看到并解决所有冲突 - 方便地在我的本地机器上。
完成此操作后，在进行实际拉取请求时，发生冲突的可能性要小得多。
答案 0 :(得分：1)
一旦你分叉了，你应该立即git checkout -b feature-branch（当然feature-branch有一个适当的描述性名称）。一旦您在本地添加了一些提交，就可以执行git push -u origin feature-branch在远程分支上创建该分支。未来推进该分支不需要这些参数。
完成工作后，您只需将拉取请求发布到项目指定的任何分支。可能是master或dev或其他内容否则，取决于准则。
我谨慎地反对过度使用git rebase，因为如果有其他人拉过相同的分支，那么你就会重新定义并git push -f突然间你有两个不同的历史和坏事可能会发生。
补充阅读：