我对 GitHub 不太熟悉，但是我有一个功能分支，我想将其当前的更改合并到 master 多次。理想情况下，我想分解拉取请求，这样一个公关就不会太长。因此，例如，我首先想要一个前端的 pr。合并后，我将为后端推送更改并创建另一个 pr。我想确保同一个特性分支可以有多个 prs 来掌握（但只会有一个打开的 pr）。
Github 允许这样做吗？
【问题讨论】：
标签： github pull-request
@aspiringsomeone，保持每个 PR 增量、独立和简洁是一个很好的策略。但是，最好为新的一组更改（功能）创建一个新分支。在 GIT 中，分支只是标记，不会消耗太多空间/资源。合并 PR 后，您可以删除该分支并为下一个 PR 创建一个新分支。
在您的情况下，第一个分支可能是 feature1_frontend（希望这些更改不依赖于后端或以某种方式禁用，直到后端更改准备好）。 PR_1 合并后，您可以创建 feature1_backend 分支并将其用于下一个 PR，例如 PR_2。当 PR 审核完成并合并后，您可以删除相应的分支并继续前进。
【讨论】：
理想情况下，拉取请求应该是独立的。
不要保留一个长期存在的功能分支并继续合并它（同一个分支）。这是结束无数合并冲突的好方法。您应该始终在合并 PR 分支后立即删除它。
但别担心。如果一个拉取请求必须依赖于另一个拉取请求，那么有一种更好的方法：在 GitHub 中，您实际上可以打开多个源自彼此的 PR，这可能是此处继续进行的方式。所以：
从你的主分支分支形成feature1并推送它并打开一个请求合并到主分支的PR。
从feature1 分支形成feature2 并推送它并打开一个PR 要求合并到feature1。
从feature2 分支形成feature3 并推送它并打开一个PR 要求合并到feature2。
这是最酷的部分。当feature1 被批准并合并到主分支时，GitHub 会自动变基feature2 PR，以便它现在要求合并到主分支，这正是你想要的。以此类推。
【讨论】：