我正在关注a success Git branching model（也称为git流）。
我做了一个修补程序，按照“完成修补程序分支”一节中的指导。
我在master上创建了一个hotfix分支：
> git checkout -b hotfix upstream/master
做了一些工作并手动将其合并到master中：
> git checkout master
> git merge --no-ff hotfix
然后手动将其合并回dev：
> git checkout dev
> git merge --no-ff hotfix
我对德夫做了更多的工作。一切看起来都很好。但当我去把德夫合并成师父的时候，它不能。
> git checkout master
> git merge --ff-only dev
fatal: Not possible to fast-forward, aborting.
似乎来自修补程序的合并提交是不同的。
我以为遵循这个过程会保持一段共同的历史。我做错了什么？
最佳答案
您没有提供关于您的历史拓扑的详细信息，因此从一个普通的案例开始，创建hotfix可以
$git checkout-b修补程序上游/主
$Git洛拉
*81A514A（开发）惊人功能
*CB4D5E6功能强大
*D4A7906冷却功能
|*39E449A（头部，上游/主，热修复）v0.2
|/
*264DDBC（主）v0.1
注意：git lola是一个非标准但非常有用的别名。
合并hotfix到master给出
*567F066（主管，主管）合并分支“修补程序”
|\
|*1B1B6E3（热修复）修复讨厌的错误
|*39E449A（上游/主）V0.2
|/
|*81A514A（开发）惊人功能
|*CB4D5E6功能强大
|*D4A7906冷却功能
|/
*264DDBC第0.1版
将hotfix单独合并到dev是事情偏离轨道的地方。
*36aa1c8（head，dev）将分支“hotfix”合并到dev
|\
*| 81A514A惊人的特征
*| CB4D5E6功能强大
*| D4A7906冷却功能
||*567F066（主）合并分支“修补程序”
|||\
||//
|/|/
||/
|*1B1B6E3（热修复）修复讨厌的错误
|*39E449A（上游/主）V0.2
|/
*264DDBC第0.1版
此时，master不是dev的直接祖先，而是它的兄弟姐妹。
向dev添加更多的提交将使master成为其叔父。
*D89AA74（负责人，开发人员）杰森又做了一次
*杰森拯救了这一天
*36aa1c8将分支“hotfix”合并到dev
|\
*| 81A514A惊人的特征
*| CB4D5E6功能强大
*| D4A7906冷却功能
||*567F066（主）合并分支“修补程序”
|||\
||//
|/|/
||/
|*1B1B6E3（热修复）修复讨厌的错误
|*39E449A（上游/主）V0.2
|/
*264DDBC第0.1版
回想一下，dev通过一个特征分支和master合并到达--no-ff。可能release-1.0从您的修补程序开始并得到另一个错误修补程序。
*f0398ba（head，release-1.0）v1.0的错误修复
*D89AA74（开发人员）杰森又做了一次
*杰森拯救了这一天
*36aa1c8将分支“hotfix”合并到dev
|\
*| 81A514A惊人的特征
*| CB4D5E6功能强大
*| D4A7906冷却功能
||*567F066（主）合并分支“修补程序”
|||\
||//
|/|/
||/
|*1B1B6E3（热修复）修复讨厌的错误
|*39E449A（上游/主）V0.2
|/
*264DDBC第0.1版
假设按下释放按钮，则返回到
$git merge—没有ff-m“v1.0”版本1.0
$Git洛拉
*5A384C8（机头、主机）v1.0
|\
|*f0398ba（1.0版）v1.0的错误修复
|*D89AA74（开发人员）杰森又做了一次
|*杰森拯救了这一天
|*36aa1c8将分支“hotfix”合并到dev
||\
|*| 81A514A惊人的特征
|*| CB4D5E6功能强大
|*| D4A7906冷却功能
*|| 567F066合并分支“修补程序”
|\\\
||//
|/|/
||/
|*1B1B6E3（热修复）修复讨厌的错误
|*39E449A（上游/主）V0.2
|/
*264DDBC第0.1版
当然，确切的解决方法取决于你的历史细节。