Answers:
对于许多（也许大多数）个体开发人员来说，创建拉取请求可能不值得。但是，我可以想到这样做的至少一个潜在原因：
拉取请求可用于更轻松地跟踪您的项目历史记录。拉取请求具有一个可以从提交消息和更改日志中引用的问题ID，这使您可以轻松返回并找到特定更改的合并点和合并提交集，而不必保留您的功能无限地分支。
例如，在先锋（无耻的插件）中，当我们合并一个拉取请求时，我们将一个项目添加到changelog中，其中包含对更改的单行描述和对拉取请求ID的引用。当然，先锋有几个开发人员，但是对于自己开发的开发人员来说，相同的机制可能会有用。
如果您决定坚持线性提交历史记录（在合并之前通过重新定位要素分支，以便可以始终以快进方式执行合并），并且对编辑和压制您非常有纪律，则这可能不太有用。提交到主数据库之前提交，因为在这种情况下，单独的提交消息可以自己用作更改日志。
创建了拉取请求，以便有人可以查看工作，提出意见，建议，进行或请求编辑，然后将代码合并到母版中。
在您的情况下，某人就是您。
作为唯一的开发人员，您仍然应该检查自己的工作，进行重构，并在准备好时将其合并为母版。
我经常使用的一种方法是尝试“戴上另一顶帽子”，“尝试其他角色”。因此，坐一会儿，使自己处于以下情况：小组新手；初级开发人员；您过去曾经尊重过的同事，等等。尝试通过他们的眼光来看一下，并尝试简单地思考如何做才能使更改更明显，更好地用更好的名字书写，从而尽可能避免使用部落和领域知识。
因此，正如您所指出的，当您想要分离出尚未准备好掌握的功能和更改时，应该在分支中工作。您可以在分支中进行所有操作（如果您仍然执行PR任务，甚至不需要拉取请求即可管理它们，但是它可能为您提供有用的结构）。
另外，有时我会发现我的更改没有用，但不是试图从master撤回更改（现在可能与其他master更改混在一起）的恐怖，我可以在一个分支中完成所有操作，然后忽略该分支/如果开始出错，请删除。这是一个巨大的好处。
因此，在决定合并整个分支之前，您应该在分支中工作，而不要直接提交给master。
这些是要遵循的准则，而不是规则。我有时会故意破坏它们。例如，昨天我对master进行了错字修复。
听起来您既有远程分支机构，又有本地分支机构。如果您发现该工作流程的开销过多，那么您始终可以使用本地分支来处理不同的功能，而无需推送它们。
从根本上讲，这取决于您的工作。使用分支对git来说是一个巨大的好处，而github确实使它变得容易，但是作为一个孤独的开发人员，并不需要使用pull request模型，直接提交给master应该很好。当您的项目最终取得令人难以置信的成功并且数十或数百名开发人员正在努力工作时，您会发现从他们的分支中获取拉取请求是跟踪项目的好方法。
拉取请求通常用于代码审查或用户使用他们自己的项目分支的贡献-对于项目中的单个开发人员，我没有真正的目的。
拉取请求与git push最终归结为单个或共享历史之一。主存储库是所有更改的来源，如果其他更改是从中提取并可能在本地进行更改，则推送请求可能会导致这些用户产生问题，因为他们是从更改派生的树。
拉取请求模型（来自自定义分支或个人存储库）是一种为所有使用和从代码派生的代码提供一致历史记录的方式。
您将代码放在github上的部分原因是使代码可用于派生和提取请求。您永远都不知道何时会发生，并且保持共同开发者的历史一致将是一大优势。