Git分支异常覆盖master分支的原因及相关操作疑问

嘿，咱们来一步步拆解你遇到的这些Git和BitBucket的问题，帮你理清来龙去脉：

这核心原因是你的工作分支内容已经被合并到master了，结合你们用的「Squash, fast-forward only」合并策略，具体过程是这样的：

• 当你的同事误把工作分支合并到master（而不是反过来），因为你们的策略是「fast-forward only」，如果master和工作分支之间没有冲突，Git会直接把master的指针“快进”到工作分支的最新提交上——这就导致master的代码和工作分支完全同步。
• 而BitBucket里PR的提交标记为「REMOVED」，本质是这些提交已经被整合进master的历史了，PR的目标分支（master）已经包含了这些变更，所以系统会标记它们为已移除（不再需要通过这个PR来合并）。

答案是有可能，分两种场景：

• 权限绕过：如果你的同事是项目管理员或者拥有「绕过PR直接修改master」的权限，他可以在本地执行以下操作，BitBucket的规则不会阻止：

  git checkout master
  git merge --ff-only your-working-branch
  git push origin master
  

• 误操作PR：同事本来想把master合并到你的工作分支，结果在BitBucket创建PR时选错了源分支和目标分支（把工作分支设为源，master设为目标），然后该PR被正常批准合并了——这种通过PR的合并是符合规则的，所以会成功把工作分支内容合并到master。

这大概率是BitBucket的操作日志关联或者误操作导致的，几种可能性：

• 误触合并按钮：你在修复回滚的过程中，可能不小心打开了旧PR，误点击了合并按钮（虽然此时master已经和分支内容一致，但BitBucket可能会记录这次操作，标记你为合并者）。
• 日志关联错误：当你通过回滚PR把master恢复正常后，BitBucket的系统可能把回滚操作的记录错误关联到了旧PR上，导致显示你合并了旧PR。
• 权限共享：如果你的同事使用了你的账号权限来合并PR（比如你曾授权过，或者共享了登录凭证），日志会显示你的名字，但这种情况概率较低。

你可以通过以下方式确认具体过程：

• 查看本地Git日志，理清分支合并历史：

  git log --oneline --graph master your-working-branch
  

• 登录BitBucket查看项目的审计日志，能看到谁在什么时候修改了master分支，以及所有PR的创建、合并操作记录。

内容的提问来源于stack exchange，提问作者Petr Schukin