我这里有一点情况。我重新设计了一个开发分支，试图推动它，但它被拒绝了（非快进）...因为我不知道为什么，我来找你......
我做了什么：
git checkout dev
git rebase G
# Here, I had to manually merge some files
# Result (in gitk) was :
# A---B---C remote/dev A'---B'---C' dev
# / /
# D---E---F------------------G---H remote/master
git push remote dev
我知道为什么我的推动是“非快进”而被拒绝了？
答案 0 :(得分：6)
这不是快进，因为你做了一个rebase 。 rebase接受一堆提交并从它们创建新的提交（可能在提交DAG中的不同位置）。请确保在实际执行此操作之前了解运行git rebase的所有含义。不能快进是其中一个含义。
重新发布已发布的历史通常被认为是一个坏主意。如果你真的必须重新绑定你的分支并推送它，请将-f标记传递给git push，或者在+（git push remote +dev）之前添加你的refspec。
克隆了您的存储库并在该分支中工作的其他人必须执行相同的rebase，否则您将在下次与其中一个贡献者合并时合并旧历史记录。
阐述快进：
从图表中可以很容易地看到它。快进基本上只会追加历史承诺。每个提交都由其提交哈希唯一标识。通过提交内容以及提交的历史记录计算提交哈希。这意味着根据定义，具有不同祖先/父级的提交将具有不同的哈希值。
如果您进行了大量提交并将它们插入DAG中的其他位置，它们将描述不同的历史记录并将获得新的提交哈希值（提交时间也已更新，但这不是重点）。因此，快进是不可能的，因为它不再是仅追加。此外，在重新定位和推送结果后，您将无法访问旧提交（不依赖于reflog）。
另一种思考方式：push不会将提交附加到旧的（remote/dev）分支，而是将提交附加到其他地方（commit G）。