ely*_*ely 7 git merge github pull-request
假设我有一个分支 ，demos它的存在是为了针对master. 我希望对demo分支的提交能够非常频繁地 ping 每个人，通常是作为拉取请求的一部分。
也就是说，我创建了分支demos和分支的初始提交，然后从它发出拉取请求。我想将它合并到master但同时保持拉取请求处于打开状态，以便随着新提交的推送，它们只会在同一个拉取请求上变得更多提交。
这似乎并不容易实现——一旦我手动从demosinto合并master，它会自动“关闭”github 上的拉取请求。但是现在我想向同一个demos分支添加更多更改，并提交和推送，只需简单地将所有关心的人demos作为同一个拉取请求的一部分进行ping 。
既然做到这一点并不容易，这让我觉得这是错误的。有时做简单的事情是错误的git（比如使用pull），但规则通常是，如果你不顾自己的方式去做一些git自然不会做的事情，那么你可能会错误地使用它。
我想以git社区和最佳实践认为好的方式处理这个案例。但与此同时，它似乎是一个非常明显的用例：拉取请求提醒其他人从分支中获取更改，但不考虑合并后的请求“完成”。一个持续的拉取请求。
我可以一直生成一个新的拉取请求，但是它并没有将不同的demos提交在逻辑上连接在一起，就其在 github 上的显示方式和提醒人们的方式而言。在提交级别，对 的更改demos彼此不同，即使来自不同的作者也可能是非常不同的事情。但是在拉取请求级别，我希望它看起来像“任何时候任何人都demos可以通过这个拉取请求来推动它”。
该工作流程的不足之处是什么，为什么从 git 中的 PR 合并时它不是一个选项？
我不完全确定我遵循，但我不认为单个拉取请求是处理您的用例的理想方式。Github 拉取请求是 Github 的一项功能，他们创建了这些请求，以便一旦该提交合并到存储库中，它就会关闭该 PR。
拉取请求，顾名思义，就是将一组特定的提交拉入该存储库的请求，一旦它们被合并，它就会自动关闭。
如果您在 Github 上，问题可能会满足您协调此问题的需要，并且您可以从每个拉取请求中引用该问题。如果您使用的是不同的错误跟踪系统，例如 Bugzilla 或 Trello 或任何您想要的系统，那么长期运行的票证可能是最好的。
这可能不那么准确，因为我不完全确定我遵循了您想要做的事情，如果是这样，我深表歉意。