作者回复: 嗯，--force-with-lease 在下面的场景有用处：几个人一起开发某个功能，共享远端的某个特性分支；在开发的初期，代码变动比较频繁，为了灵活地做变动，可能在某个时期，这几个开发人员约好了暂时不把分支保护起来，待稳定后再设置为不运行 -f 。 在这个阶段，需要特别注意：如果你 fetch 之后在本地的 origin 相关分支上已经看到了别人的提交，依然进行强制推送，你还是会覆盖别人的提交。也就是说，--force-with-lease 解决的是本地仓库不够新时，依然覆盖了远端新仓库的问题，如果你执意想要覆盖远端提交，只需要先 fetch 再推送，它也不会拒绝的。 在使用 git push --force-with-lease 命令被拒绝时，可以先 fetch 仓库，然后确认其他人是否对此分支有新的修改，如果没有，就可以继续强制推送。

作者回复: 👍 理解得到位

作者回复: 课件上beijing合入到master，GitHub系统帮我们自动处理了，从beijing分支上把新增的commit的内容一个一个的复制到master分支上，创建了新的commit，但文件变更的内容与beijing分支的commit是一样的。 至于你提到特性分支合入到主干之前，是否应该和master先整合，这个得看你们团队具体情况了。 之前没有类似GitHub或GitLab这些平台的时候，我们往往要求开发人员在本地基于远端分支做rebase，本地测试ok后再推到远端去。随着代码平台提供了类似 squash、rebase 等合并策略，平台会自动帮我们处理特性分支与主干集成的事务，再加上平台越来越强的在线CI服务，我们对本地是否与master集成的要求越来越弱化了。