假设我有一个分支demos，它的存在是为了针对master中的任何内容创建演示代码。我希望demo分支的提交能够频繁地ping每个人，通常是通过pull请求的一部分。
也就是说，我创建了分支demos和分支的初始提交，然后从它发出一个pull请求。我想把它合并到master，但也要保持pull请求打开，这样当新的提交被推送时，它们只是在同一个pull请求上变成更多的提交。
这似乎并不容易实现--一旦我手动将demos合并到master，它就会自动“关闭”github上的pull请求。但现在我想在同一个demos分支中添加更多更改，并提交和推送，只是让它ping每个关心demos的人作为同一个pull请求的一部分。
有时在git中做简单的事情是错误的（比如使用pull），但规则通常是，如果你特意去做一些git不自然做的事情，那么你可能使用错了。
我想以一种被git社区和最佳实践认为是好的方式来处理这种情况。但同时它似乎是一个非常明显的用例：一个pull请求，提醒其他人从分支中获取更改，但在合并后不认为请求“完成”。一个正在进行的pull请求。
我可以一直生成一个新的pull request，但是它并没有保持不同的demos提交在逻辑上连接在一起，就如何在github上显示和提醒人们而言。在提交级别，对demos的更改彼此不同，甚至可能是来自不同作者的非常不同的事情。但是在pull request级别，我希望它看起来像“所有的时间，当任何人都有东西推通过demos它来通过这一个拉请求。”
这个工作流程的不足之处是什么？为什么在git中从PR合并时它不是一个选项？