在git中继续处理包含PR的分支的正确方法是什么？

假设我在分支上工作并进行提交A.我发出拉取请求.在审查公关时,我继续在同一个分支机构工作.最终,分支机构获得批准并合并为主机.现在我已准备好提交B,我想制作一个新的PR.我拉了最新的主人,并在我的分支上重新绑定.这里的问题是 - 因为master包含提交A,因为它是从我的第一个PR获得批准而我的分支包含提交A,因为我继续我的工作,而我的第一个PR正在审核中,是否会有重复的提交？如果是,那么在这里进行提交B的正确方法是什么 - 来自当前分支的新分支,主分支的新分支和第一分支上的变基,或者可能是在第二个PR之前挑选樱桃的交互式变基？

我从未对目前正在审核的分支进行更改.在需要修改时将事情搞砸.

相反,我分支正在审查的提交.这样,您可以更轻松地将最新更改重新绑定到主服务器中的合并提交.

可能有更好的方法,但这是我如何处理它,它的工作原理:-)

一个例子(我不确定我是按照绘制git流的方式绘制所有内容但是我认为它就足够了.)

 A--B--C (master)
        \
         D (issue_101)

有些工作并准备推送提交D,以便可以审查.现在我不想在继续工作之前等待它被审查,所以我分支了.

A--B--C (master)
        \
         D (issue_101)
          \
           E (issue_102)

在分支issue_102中做了一些工作(完成与否问题在这里并不重要),同时提交D被批准.Checkout master并拉出更改,它将如下所示

A--B--C--D'(master)
        \
         D (issue_101)
          \
           E (issue_102)

因为问题101的工作现在在master中,我们不再需要使用commit D的分支,所以我们摆脱它 git branch -D issue_101

A--B--C--D'(master)
        \
         D--E (issue_102)

现在我们通过干预来修改master_102

git checkout issue_102
git rebase -i master

在弹出的屏幕中,删除pick旧D分支.完全删除线.毕竟我们只想在主人身上重新提交E.

完成后它会是这样的

A--B--C--D (master)
          \
           E (issue_102)

我发现这是一种理想的工作方式,因为如果提交D出现问题并且您需要进行一些更改,您可以将您的更改存储在分支问题102中,并结帐到问题101并修改您想要的任何内容.之后你将不得不在101上重新调整102,所以修改后的变化也是102.