为已关闭的分支发送新的推送请求会重新打开该分支，其中之前的提交已经存在
我不会开设新分行。我在分支上进行了更改，推送更改，创建了拉取请求，拉取请求获得批准，然后合并到主分支。 GitHub 自动关闭了该分支。到目前为止一切都很好。
我的问题是，当我需要在本地同一分支（尚未删除）下进行更多（新）更改，然后推送更改时。它再次打开了 GitHub 上关闭的已关闭分支。这对我来说很好，但它实际上带来了我之前所做的更改，这些更改已经再次合并回来，并将新更改添加到底部。
如果这个 PR 被批准并合并到 master，它会尝试合并之前的更改和新的更改吗？或者只是为了审查以前的更改而只会合并新的更改？
I'm not opening a new branch. I made changes on the branch, pushed the changes, created a pull request, pull request is approved and then merged to the master branch. GitHub closed the branch automatically. All good so far.
My problem is, when I needed to make more(new) changes under the same branch locally (which is not deleted yet) and then push the changes. It opens the closed branch that was closed on GitHub again. That is fine with me but it actually brings the previous changes I did that is merged already back again, with the new changes added to the bottom.
If this PR is approved and merged to the master, will it try to merge the previous changes and the new changes? Or is it for review purposes only for previous changes and it will only merge the new changes?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是的，它只会合并新的提交。
每个提交都有一个父提交。这是 git 树中唯一可以存在此提交的位置。例如，如果您对提交进行
rebase或cherrypick操作，则将创建具有新父提交的相同提交。您已合并的最旧的提交有一个父提交，它是创建分支的主分支上的提交。这是此提交可以存在的唯一位置。由于最旧的提交已合并到此位置，因此再次合并此提交时不会发生任何情况。第二个最旧的提交将最旧的提交作为父提交，并且该提交位于主分支上，因此相同的逻辑也适用于第二个最旧的提交和所有其他已合并的提交。
如果您不介意的话，我建议您在 PR 合并后在本地删除分支并在新分支中工作，这是一个更干净的工作流程，其中 PR 仅显示新提交。如果您想要继续在同一分支中工作的唯一原因是您想要继续在同名分支中工作，请创建与已删除分支同名的新分支。
Yes, it will only merge the new commits.
Each commit has a parent commit. This is the only place in the git tree that this commit can ever exist. If you, for example,
rebaseorcherrypicka commit then an identical commit with a new parent commit will be created.The oldest commit that you have already merged has a parent commit that is the commit on the master branch where the branch was created. This is the only place this commit can exist. Since this oldest commit is already merged to this location, nothing happens when this commit is merged again. The second oldest commit has the oldest commit as parent commit, and that commit is on the master branch so the same logic applies to the second oldest and all other already merged commits as well.
A suggestion if you do not mind, I would argue that a cleaner workflow where the PR only shows the new commits is that you delete the branch locally as well after the PR was merged and work in a new branch. Create the new branch with the same name as the deleted branch if the only reason for you wanting to keep working in the same branch is that you want to keep working in a branch with the same name.