开发人员使用诸如Git之类的源代码控制系统的一个重要原因是避免灾难。如果您执行错误删除文件这样的简单操作，或者发现对十二个文件所做的更改都是不明智的，那么您可以轻松撤消所做的事情。
即使对于有经验的Git用户，某些Git错误也更令人生畏且难以逆转。但是，只要稍加注意（在您不惊慌的情况下），您就可以从程序员所知的一些最严重的Git灾难中退缩。
这是一些更大的Git boo-boos的列表，以及一些退出和阻止其中一些的提示。您走得越远，灾难就越大。

Git错误＃1：您忘记在上一次提交中添加更改

这是最容易恢复的Git错误之一。假设您将一些工作提交给本地分支，然后意识到您没有暂存许多所需的文件。或者您忘记在提交消息中添加某些详细信息。
不怕。首先，如果您要上演新的更改，请执行此操作。然后键入git commit --amend以编辑提交消息。完成后，按Esc键，然后输入:xq保存并退出编辑器。（最后一步是经常让Git新手感到沮丧的步骤，他们并不总是意识到内置的Git编辑器本身就是动物。）
如果您只是在更改文件，而无需修改提交消息，则可以使用git commit --amend --no-edit来添加文件并跳过消息编辑过程。
避免这种错误的一种方法是调整您在Git中进行提交的方式。如果您正在进行一些不断提交少量修订以跟踪增量修订的工作，请在一次性分支中进行。在执行此操作时，请记录您在某处所做的主要更改-不要等到面对git commit命令行将其全部写下来之后，再进行记录。然后，当您达到一个重要的里程碑时，可以使用git merge --squash一次性分支将结果作为单个干净的提交保存到进行中的分支中，并使用对提交消息所做的注释。

Git错误＃2：您已将更改提交给（本地）主服务器

另一个常见的愚蠢现象：您已经尽责地进行了许多更改……但是错误地将代码存储到了仓库的主分支中。您真正想要做的是将它们提交到新分支，或dev专门用于中断更改的分支。
一切都不会丢失。此错误可以通过以下三个命令解决：
git branch new-branch
git reset HEAD~ --hard
git checkout new-branch
第一个命令创建我们要使用的新分支。第二条命令将主分支重置为上一次提交之前的状态，但将您刚进行的更改保留在新分支中。最后，我们切换到新分支，等待您的更改。
如果进行了多次提交，请使用git reset HEAD~ --hard，这是您要返回的提交数量。或者，您可以使用git reset ，如果方便的话，哪里是目标提交的哈希ID。
为避免此错误，无论何时开始使用代码进行任何会话，都要养成建立新分支并切换到它们的习惯，即使只是要丢弃它们。

Git错误＃3：您垃圾了文件或目录

另一种常见的灾害被错误地捣毁一个文件的内容…只有找出很多关于它提交到分支后的事实。幸运的是，有一个简单的解决方法。
首先，使用git log或IDE的内置Git工具查找修改文件之前的提交的哈希ID。接下来，用于从有问题的提交中仅git checkout hash_id – /path/to/file检出该文件。请注意，路径应相对于项目的根目录。这会将文件的较早版本放置在项目的暂存区域中。
如果您只想返回n次提交，则不需要哈希ID。您只需发出命令git checkout HEAD~ – /path/to/file，这是您要返回的提交次数。
如果要检出文件的整个目录，请对文件路径使用Git的通配符格式。例如，输入 git checkout HEAD~1 – ./src/**将使您退回一次提交，并/src从项目的根目录恢复目录中的所有内容。

Git错误＃4：您不小心删除了一个分支

这是大家都害怕的情况：不小心从存储库中删除了整个分支。根据情况的不同，这可能很容易恢复，也可能比较棘手。
首先，使用git reflog来查找对分支所做的最后一次提交。然后使用哈希ID创建一个新分支：
git checkout -b restored-branch <hash_id>
请注意，只有在相关分支已合并的情况下，这才可以炸培根。如果您强制删除了一个未合并的分支，则可以在没有运行git gc存储库的情况下找到它：
git fsck --full --no-reflogs --unreachable --lost-found
这将转储不再可访问的对象（包括已删除的分支）的所有提交哈希值的列表。从列表底部查找“无法到达的提交”条目，然后尝试将该哈希ID还原到新分支中，以查看它是否是您破坏的那个ID。如果不是，请按顺序向上移动到下一个列表，然后查看可以恢复的内容。
通常，切勿默认情况下强制删除分支，因为您很容易最终将浪费浪费在尚未合并的分支中，该分支中仍包含有价值的东西。如果您习惯性地强行删除分支机构，则这表明您使用分支机构的工作习惯需要减少混乱。

Git错误＃5：您破坏了远程分支 git push

一旦我在GitHub存储库的本地副本上工作，并错误地使用该–force选项将我的master分支推送到了远程副本。最后，我得到了当时不可用的回购的公共副本。哎呀
如果您犯了这样的错误，并且您的存储库最近与远程存储库已同步，则可以使用自己的远程存储库分支副本进行修复。假设您还不存在，请切换到需要重新同步的分支，然后发出以下命令：
git reset --hard <remote_repo>/@{1}
这会将您的副本重置为的最后同步版本<remote_repo>。就我而言，分支是master，远程仓库是origin，所以我可以使用git reset --hard origin/master@{1}。
然后用于git push -f <remote_repo> 将远程存储库还原到其早期状态。
防止这种情况再次发生的一种方法是禁止强制推动。您可以使用以下命令在远程Git存储库上进行配置：
git config --system receive.denyNonFastForwards true
有时候您需要进行推力操作，但是最好在需要时将其打开，而在不需要时将其关闭。

Git错误＃6：您将私人信息提交给了公共仓库

这可能是最糟糕，最困难的Git问题。您错误地将敏感数据提交到公共存储库，并且您想通过手术从存储库中删除文件。您需要确保即使返回到较早的提交也无法找到敏感数据，但是您需要做到这一点 而不要碰其他任何事情。
如果有问题的文件在六个星期前提交了，这将变得非常困难，同时，其他重要工作也已经完成了。您不能只回滚到添加文件之前的状态。您会破坏过程中的其他所有内容。
好消息：一些勇敢的Git专家创建了BFG Repo-Cleaner工具，专门用于从Git 仓库中删除不良数据。BFG Repo-Cleaner允许您对存储库快速执行常规任务，例如删除所有匹配特定通配符或包含某些文本的文件。您甚至可以传入一个列出所有不需要的文本的文件。
[ 通过InfoWorld的App Dev Report新闻通讯了解软件开发中的热门话题 ]
BFG Repo-Cleaner本质上是使用的多步骤过程自动化git filter-branch。如果您想手动处理，GitHub上有详细的流程介绍。但是BFG工具涵盖了绝大多数常见用例，其中许多都包含在该工具的命令行选项中。此外，该过程很长且很复杂，如果您用手做的话，很容易在沿途某个地方用脚砸自己。
请注意，如果从必须在其他地方同步的本地分支中清除数据，则除非通过强制推送到远程分支，否则将无法同步。整个提交树都必须重写，因此您实质上是在向远程写一个全新的历史记录。您还需要确保更改后其他所有人都提取了新的重写存储库副本，因为他们的存储库也将不再有效。
最后，开发这么多年我也总结了一套学习Java的资料与面试题，如果你在技术上面想提升自己的话，可以关注我，私信发送领取资料或者在评论区留下自己的联系方式，有时间记得帮我点下转发让跟多的人看到哦。