我们有以下 GIT "工作习惯"。我将简短地描述它，以澄清我后面问题的上下文。
我们与三个常设分支机构(DEV，STAGE，MASTER)合作。一般来说，STAGE应该与MASTER同步。但是DEV被认为是"肮脏的"，这意味着它可以包含许多永远不会合并到STAGE或MASTER中的提交。我们只将功能分支或单个提交从DEV合并到STAGE中。然后我们将STAGE合并到MASTER中。
现在在某个时候，我们开始了一个巨大的"更改集"(主要项目升级)并创建了一个专用的功能分支，为此说升级。 此功能的工作持续了 3 个月。
现在我想将这个巨大的功能分支合并到 STAGE 中，但我不能 100% 确定我是从STAGE/MASTER还是从DEV创建了分支升级。 我们没有记录这一点。
由于DEV是"脏的"，如果升级是从DEV分支的，我就无法进行合并！
所以这是我的问题：现在我想确保我们从 STAGE/MASTER 而不是从DEV分支升级(我应该采用STAGE/MASTER，但现在我不确定)。如何从存储库中获取最可靠的信息？
我已经做了一些研究并尝试使用">git merge-base"。 以下是我尝试过的三个命令。
1)git show --summary 'git merge-base upgrade dev'
2)git show --summary 'git merge-base upgrade stage'
3)git show --summary 'git merge-base upgrade master'
但它们都提供了只有几天历史的相同树。
所以在这里我的问题再次：现在我想确保我们从阶段/主分支升级而不是从DEV分支升级。如何从存储库中获取最可靠的信息？
更简单的方法是使用以下任何命令：
git log --oneline --decorate --graph --all
gitk --all
您可以明显地查看分支结构。例如下图中有master和new分支，我们可以找到new分支是从master分支创建的。您可以使用相同的方法来查找创建UPDATE的位置。
* 0d04f17 (HEAD -> master, origin/master, origin/HEAD) 5
* 74d5ed3 5
* 6146194 4
* e5ddeac 3
* a33f9ee 2
* 8373f5d hi1
* 3df7047 hi
* 3f27319 6
| * f0cca03 (new) 1
|/
* 38236ae Update config
将
分支UPDATE变基到过去的提交
假设UPDATE分支是从DEV分支创建的，过去的提交是提交D，提交历史记录如下所示：
A---B---C---D---E master
F---G---H---I DEV
J---K---L UPDATE
1.直接变基UPDATE(不要保留原来的UPDATE分支)：
git rebase --onto <commit id for D> DEV UPDATE
然后提交历史记录将如下所示：
J'---K'---L' UPDATE
/
A---B---C---D---E master
F---G---H---I DEV
2.将UPDATE的更改变基为新分支，并保留原始UPDATE分支：
git checkout -b new <commit id for D>
git rebase --onto new DEV <commit id for L>
git branch -f new
git checkout new
然后提交历史记录将如下所示：
J'---K'---L' new
/
A---B---C---D---E master
F---G---H---I DEV
J---K---L UPDATE