假设我有一个分支demos，它存在以创建针对master中的任何内容的演示代码。我希望demo分支的提交可以非常频繁地对每个人进行ping操作，通常是作为拉取请求的一部分。
也就是说，我创建了分支demos和分支的初始提交，然后从中发出了拉取请求。我想将它合并到master，但也保持拉请求打开，这样当新的提交被推送时，它们就会在同一个拉取请求上变得更多提交。
这似乎很容易实现 - 一旦我从demos手动合并到master，它就会自动＆＃34;关闭＆＃34; github上的pull请求。但现在我想在同一个demos分支中添加更多更改，并提交＆amp;推送，只需将每个关心demos的人都作为同一拉取请求的一部分进行ping操作。
由于这样做并不容易，这让我觉得这是错误的。有时在git中执行简单的操作是错误的（例如使用pull），但规则通常是，如果您不愿意做git无法做的事情。 39;自然而然，你可能错了。
我希望以git社区和最佳做法认为合适的方式处理此案例。但与此同时，它似乎是一个非常明显的用例：一个拉动请求，提醒其他人从分支机构获取更改，但不考虑请求“完成”＆＃39;合并后。正在进行的拉取请求。
我可以一直生成一个新的拉取请求，但是它并没有保持不同的demos提交在逻辑上连接在一起，就如何在github上显示它们并提醒人们。在提交级别，对demos的更改彼此不同，即使来自不同的作者也可能是非常不同的。但是在拉取请求级别，我希望它看起来像＃34;当有人有东西通过demos时，它会通过这一个拉取请求来实现。＆＃34;
该工作流程的不足之处是什么？为什么在git中从PR合并时它不是一个选项？
答案 0 :(得分：0)
我不完全确定我会关注，但我认为单个拉取请求不是处理用例的理想方式。 Github pull请求是一个Github功能，他们已经制作了这些功能，以便一旦提交合并到存储库中，就会关闭该PR。
拉取请求，凭借名称，是一个请求，将一组特定的提交拉入该存储库，并在合并后自动关闭。
如果您使用的是Github，则问题可能符合您协调此问题的需要，您可以从每个拉取请求中引用该问题。如果您使用的是Bugzilla或Trello等不同的错误跟踪系统，或者您想要的任何其他错误跟踪系统，那么可能是最好的长票。
这可能不那么准确，因为我并不完全确定我会遵循你想要做的事情，如果是这样抱歉。
答案 1 :(得分：0)
由于没有可接受的解决方案，我会建议其他可能正在寻找类似内容的人。看一下GitHub的Webhook功能，我认为它比OP请求更适合OP尝试实现的功能。使用它，您可以将提交报告给另一个系统，如AWS SNS，Twitter，IRC等，观察者可以订阅以进行更新。
可以找到第三方服务挂钩列表 https://github.com/github/github-services/tree/master/lib/services