我最近正在与一个使用GitHub Enterprise的开发人员团队合作。
我在一个分支上工作了，我们称之为origin/feature1了几个小时，并做了一些有效地推动的提交。同时，一位同事正在进行从origin/master到origin/feature1的合并。当他完成合并后，似乎我最近的一些提交都丢失了，并且由于我在注意到问题之前就撤消了，所以我也在本地丢失了它们。
问题：
是否真的有可能丢失被推送的提交，或者一切可以恢复（即使这意味着运行大量的秘密命令）？
如果是，这是否意味着Git在某种程度上...坏了？我的意思是，作为SVN的快乐用户，我从未失去使用SVN的任何工作。顺便说一下，2013年的TFS也没有。
执行合并时我在这里。进行合并的人似乎并没有做任何“特殊”的事情，也没有执行任何看起来像他们可以丢弃某些提交的命令。我不认为这是一个错误（Git客户端和GitHub Enterprise都差不多是最新的）。那么，合并时是否应该指定一些特定的参数？还是某些特定的合并模式，默认情况下 会导致提交丢失？
从本质上讲，如何避免将来失去半天的工作？
答案 0 :(得分：2)
您的同事可能在未合并您的更改的情况下以-f推送了其分支，因此，在该分支上，您的更改会“丢失”。您总是可以保留本地分支，以便仍然可以对其进行处理...并且，如果您已删除本地分支，则可以始终检查reflog以取回旧的提交。
如何避免浪费时间？我想您（不是您，而是您，您的团队）应该学习如何使用他们面前的工具。如果开发人员想扮演牛仔（出于娱乐目的，或者可能不了解强制推杆的后果）...那么，就轻松吧。目前，请尝试找回更改。
PS哦，不用担心。 个人意见免责声明：经过数轮使用git并了解其工作原理后，您会想知道您是如何通过使用SVN这么长时间实现的。 :-D
答案 1 :(得分：2)
该同事正在其本地存储库中进行合并。 origin/feature1是指其存储库中的一个远程分支，它与您推送的分支不同。 git remote update将进行同步。
我怀疑涉及推力，您通常不想这样做。如果您的同事力量推到origin/feature1，那将改变feature1指向您的提交的提交。
您的本地存储库中可能仍包含您所做的提交；找到它们超出了我的答案范围。
解决方案：
答案 2 :(得分：2)
如果我们俩都开始研究origin/feature1，并且您先推送了一些提交，然后又尝试推送了不同的提交，那么Git会给我类似的错误
! [rejected] feature1 -> origin/feature1 (non-fast-forward)
error: failed to push some refs to 'https://your-repo.com'
hint: Updates were rejected because a pushed branch tip is behind its remote
hint: counterpart. Check out this branch and integrate the remote changes
hint: (e.g. 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
要正确处理这种情况，我可以运行git fetch origin将推送的提交内容放入本地git，然后使用merge或rebase将您所做的更改合并到我自己的内容中
在您所处的情况下听起来好像发生了（正如其他人所说的那样），是您的同事改为运行git push --force，它告诉git忽略它第一次给出的错误，而只是覆盖{{1} }和我的origin/feature1分支。
为避免将来出现这些问题，我建议：
feature1或-f标志。并确保将该消息传达给团队的其他成员。可以在GitHub的分支上禁用强制推送。要恢复所做的更改，可以运行--force，查找“ commit”条目以找到您对该主题进行的最后一次提交，然后git reflog进行相应的提交哈希。您的本地Git会保留您所做的每次提交至少30天，除非您删除checkout目录，否则丢失它是不可能的。