放心，只要你已经把本地master同步到远程最新状态，合并你的分支到本地master后再推送，绝对不会覆盖远程master上别人新增的fileB.html变更。下面给你详细拆解原因和正确的操作流程：

为什么不会覆盖？ #

当你执行git pull origin master后，你的本地master分支已经完全同步了远程master的最新代码——也就是包含了别人修改的fileB.html的内容。这时候你把自己的开发分支（假设叫my-feature）合并到本地master时，Git会执行三方合并：

• 以你当初从master分叉出my-feature时的共同提交为基础
• 对比你在my-feature里对fileA.html的修改
• 对比远程master上新增的fileB.html的修改

只要这两个修改没有冲突（比如你们没同时改fileB的同一部分），Git会自动把这两部分变更整合到一起，生成一个新的合并提交。之后你推送到远程的就是这个整合后的版本，远程master的原有变更会被完整保留。

如何让你的分支同步master的变更？ #

虽然直接合并到最新master也能得到正确结果，但更规范的做法是先让你的开发分支同步master的最新变更，再合并或者直接推送（如果用rebase的话），这样能让提交历史更清晰。推荐两种方式：

方式1：合并master到你的开发分支 #

1. 切换到你的开发分支：

   git checkout my-feature
   

2. 拉取远程master的最新变更并合并到当前分支：

   git pull origin master
   

   （如果有冲突，解决冲突后提交合并结果）
3. 切换回master分支，合并你的开发分支：

   git checkout master
   git merge my-feature
   

4. 推送到远程master：

   git push origin master
   

方式2：将你的开发分支rebase到master上（适合追求干净提交历史的场景） #

rebase会把你的提交“移动”到master的最新提交之后，相当于在最新的master基础上重新做你的修改：

1. 切换到master分支，拉取最新变更：

   git checkout master
   git pull origin master
   

2. 切换回你的开发分支，执行rebase：

   git checkout my-feature
   git rebase master
   

   （如果有冲突，解决冲突后执行git rebase --continue，直到完成）
3. 切换回master，合并你的分支（此时是快进合并，不会生成新的合并提交）：

   git checkout master
   git merge my-feature
   

4. 推送到远程master：

   git push origin master
   

额外提醒 #

• 如果在你合并或rebase的过程中出现冲突（比如你和别人同时修改了同一个文件的同一行），Git会提示你解决冲突，解决后再继续操作即可。
• 永远不要在本地master落后于远程的情况下直接合并你的分支并推送，那样才可能导致覆盖，但你已经用git pull origin master同步了，所以完全不用担心这个问题。

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