为何使用git fetch进行快进时会拒绝领先的分支？

1. git merge --ff-only origin/BR 的逻辑 #

当本地BR分支领先于origin/BR时，origin/BR指向的提交其实是本地BR的祖先提交——本地BR已经包含了origin/BR的所有变更。git merge --ff-only的作用是尝试将目标分支的提交快进合并到当前分支，但既然当前分支已经涵盖了目标分支的全部内容，Git自然会提示“already up-to-date”，没有可执行的合并操作。

2. git fetch . origin/BR:BR 或 git fetch origin BR:BR 的逻辑 #

这种写法用了Git的引用规范（refspec），本质是要求Git直接将source（此处为origin/BR）指向的提交，覆盖到dest（本地BR）分支上。

Git对引用更新有严格的安全限制：只有当source的提交是dest的后代（即快进更新，不会丢失本地提交）时，才允许直接更新。而当本地BR领先于origin/BR时，dest（本地BR）的提交是source（origin/BR）的后代，此时强行把BR指向origin/BR的提交属于非快进更新，会直接丢弃本地BR上的新提交——Git为了保护你的代码，就会提示“rejected (non-fast-forward)”，拒绝执行这个危险操作。

简单总结：

• merge是检查分支间的包含关系，确认无新内容就提示已更新；
• 带refspec的fetch是尝试直接修改分支指针，遇到会丢失代码的非快进操作就直接拒绝。

内容的提问来源于stack exchange，提问作者H.v.M.