问题

Question

开发人员假设从master创建一个功能分支，然后开始编码，但是相反，他们已经从developer分支创建了一个功能分支，然后合并到一个develop分支。（并非来自develop分支的所有功能都将位于master分支上）

当我尝试创建PR以将其功能分支（未开发）合并到release分支（release分支是从master分支创建的）时-它显示PR上的提交，但他未提交，并且正在显示来自master分支上不存在的developer分支。为什么会这样呢？

开发人员仅将Task-6 Suspend Post提交到Task-6-Suspend-Post分支。

示例：

我需要摘樱桃还是其他解决方案？几个功能分支存在相同的问题。

Answer 1

合并操作将两个（或多个）分支合并到一个提交中（合并提交）。您有以下情况：

A - B (master)
     \              
      C - D (develop)     
           \     
            E (Task-6-Suspend-Post)

由于Task-6-Suspend-Post是根据develop创建的分支，因此在其历史记录中包含提交C和D。将Task-6-Suspend-Post合并到master中时，以下历史记录如下所示：

A - B --------- G
     \         / 
      C - D   /
           \ /
            E

换句话说，PR是重新创建主提交上最新提交的合并提交的记录（B和最新的Task-6-Suspend-Post（E）。这将使提交C和D在主服务器的历史记录中可用，并因此包含在拉取请求中。

解决方案

制作Task-6-Suspend-Post中的rebase可以解决您的问题。

git rebase master Task-6-Suspend-Post

上面的命令将创建一个新提交E'，其内容与E相同，但以master头（B）为父。分支指针Task-6-Suspend-Post将附加到新的E'提交中。

     E' (Task-6-Suspend-Post)
    /
A - B (master)
     \              
      C - D (develop)

通过强制推送新的Task-6-Suspend-Post并发出新的拉取请求，PR中仅应包含一次提交。

git push origin -f

Answer 2

如果是一次提交，则选择樱桃是可行的。但是，rebase为您移动分支需要做很多工作。通过多次提交，重新设置基准也可以减少您的工作量。

对于具有当前功能和错误修复的developer分支，常见的工作流程是从developer分支而不是master分支创建新的功能分支。然后将功能分支合并到开发中。然后，当您准备好并且最终版本发生时，也可以从development创建一个版本分支。将其合并到master中并标记该版本。