嘿，我完全理解你遇到这种情况的崩溃心情——半天的工作突然“不见”，换谁都会慌，尤其是之前用SVN/TFS从没碰到过这种事。咱们一步步拆解你的问题：

已推送的提交真的会彻底丢失吗？ #

先给你吃颗定心丸：已推送到远程仓库的提交几乎不可能彻底消失。Git的核心设计就是把每一次提交都作为不可修改的对象存储在数据库里，哪怕这些提交不再被分支标签指向，它们依然躺在仓库的历史记录里，只是暂时“隐身”了而已。

只要你能找到这些提交的哈希值（比如通过本地的git reflog、远程仓库的操作日志，或者GitHub Enterprise的提交历史回溯），就能把它们完整恢复回来，哪怕需要执行一些稍复杂的命令。

Git是不是有缺陷？和SVN/TFS的差异在哪？ #

这绝对不是Git的缺陷，而是两种版本控制模型的本质差异：

• SVN和2013版TFS是集中式模型，所有操作都围绕中央仓库的线性历史，合并也是基于中央仓库的最新状态，几乎不会出现本地与远程历史分叉后被覆盖的情况；
• Git是分布式模型，每个开发者的本地仓库都有完整的历史副本，合并、变基等操作会产生不同的历史走向。有时候某些操作会让提交从分支的可见历史中消失，但它们并没有被删除，只是没被分支引用指向罢了。

为什么你的提交看起来“丢失”了？ #

结合你描述的场景（同事把master合并到feature1后提交消失），最可能的原因有这几个：

• 同事用了**git merge --squash**：这个命令会把feature1上的多个提交压缩成一个全新的提交，原有的提交会从feature1分支的可见历史中消失（但依然存在于Git数据库）；
• 同事误执行了强制推送（git push -f）：如果同事本地的feature1分支和远程不同步，强制推送会直接覆盖远程分支的历史，把你的提交暂时隐藏；
• 你拉取远程分支时用了git pull --rebase：变基操作会重写本地提交历史，可能导致你的提交被“整合”到新的历史中，看起来像是丢失了。

合并时哪些参数要绝对避免？ #

• git merge --squash：除非团队明确约定要压缩提交历史（比如用于整洁的PR合并），否则别用这个参数——它会直接丢弃原有的提交记录；
• git push -f：强制推送会覆盖远程分支的历史，只在你100%确定要修正错误历史（比如撤销误提交）时使用，绝对不能在多人协作的共享分支上乱用；
• 别在公共分支上用**git rebase**：变基会重写提交历史，多人协作的分支上用变基，很容易导致历史冲突和提交“失踪”。

未来怎么避免半天工作“丢失”？ #

分享几个能帮你规避风险的实用习惯：

• 推送前先同步远程分支：每次推送前，先执行git fetch origin，再用git merge origin/feature1（或者直接git pull origin feature1），确保本地分支和远程分支完全同步，避免提交冲突或被覆盖；
• 不在共享分支上重写历史：git rebase、git commit --amend、git push -f这些操作，只在你自己的私有分支（还没推送到远程的）上用；
• 定期查看git reflog：这个命令会记录本地仓库所有的操作历史，哪怕分支被重置，你也能通过它找到丢失的提交哈希值，然后用git checkout <提交哈希>或者git branch 恢复分支名 <提交哈希>把提交找回来；
• 和团队明确合并规则：提前约定是用普通合并（保留完整历史）还是squash合并，避免因为操作不一致导致的历史混乱；
• 推送后立刻确认远程记录：推送完成后，去GitHub Enterprise上查看feature1分支的提交历史，确保你的提交已经出现在远程；
• 开启分支保护规则：在GitHub Enterprise上给feature1分支开启分支保护，禁止强制推送，要求合并前必须通过PR审核，从根源上杜绝误操作覆盖历史的可能。

如果现在要恢复你的提交，先试试本地执行git reflog，找到那些“丢失”的提交哈希，然后创建一个新分支指向它们，再合并回feature1就行；如果本地没有记录，可以联系GitHub Enterprise管理员查看远程仓库的reflog，远程的提交记录通常会保留一段时间。

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