您将要犯的6个Git错误-以及如何解决

开发人员使用诸如Git之类的源代码控制系统的一个重要原因是避免灾难。 如果您执行错误删除文件这样的简单操作，或者发现对十二个文件所做的更改都是不明智的，那么您可以轻松撤消所做的事情。

即使对于有经验的Git用户，某些Git错误也更令人生畏且难以逆转。 但是，只要稍加注意（在您不惊慌的情况下），您就可以从程序员所知的一些最严重的Git灾难中退缩。

[ 同样在InfoWorld上：Git和GitHub用户的27个基本技巧 ]

这是一些更大的Git boo-boos的列表，以及一些退出和阻止其中一些的提示。 您走得越远，灾难就越大。

这是最容易恢复的Git错误之一。 假设您将一些工作提交给本地分支，然后意识到您没有暂存许多所需的文件。 或者您忘记在提交消息中添加某些详细信息。

不怕。 首先，如果您要上演新的更改，请执行此操作。 然后输入git commit --amend编辑提交消息。 完成后，按Esc键，然后输入:xq保存并退出编辑器。 （最后一步是经常让Git新手感到沮丧的步骤，他们并不总是意识到内置的Git编辑器本身就是动物。）

如果您只是在更改文件，而无需修改提交消息，则可以使用git commit --amend --no-edit添加文件并跳过消息编辑过程。

避免这种错误的一种方法是调整您在Git中进行提交的方式。 如果您正在进行一些不断提交少量修订以跟踪增量修订的工作，请在一次性分支中进行。 在执行此操作时，请记录您在某处所做的主要更改-不要等到遇到git commit命令行将其全部写下来时，再进行记录。 然后，当您达到一个重要的里程碑时，使用一次性分支中的git merge --squash将结果作为一个干净的提交保存到进行中的分支中，并使用您为提交消息记下的注释。

另一个常见的愚蠢现象：您已经尽责地进行了许多更改……但是错误地将代码存储到了仓库的主分支中。 您真正想要做的是将它们提交到新分支，或专门用于打破变更的那个dev分支。

一切都不会丢失。 此错误可以通过以下三个命令解决：

git branch new-branch
git reset HEAD~ --hard
git checkout new-branch

第一个命令创建我们要使用的新分支。 第二条命令将主分支重置为上一次提交之前的状态，但将您刚进行的更改保留在新分支中。 最后，我们切换到新分支，等待您的更改。

如果进行了多次提交，请使用git reset HEAD~<n> --hard ，其中<n>是要返回的提交数。 或者，您可以使用git reset <nnnn> ，如果方便的话，其中<nnnn>是目标提交的哈希ID。

为避免此错误，无论何时开始使用代码进行任何会话，都要养成建立新分支并切换到它们的习惯，即使只是要丢弃它们。

[ 同样在InfoWorld上：为什么C编程语言仍会统治 ]

另一种常见的灾害被错误地捣毁一个文件的内容......只有在事后找出很多关于它提交到分支。 幸运的是，有一个简单的解决方法。

首先，使用git log或IDE的内置Git工具查找修改文件之前的提交的哈希ID。 接下来，使用git checkout hash_id -- /path/to/file file从有问题的提交中仅检出该文件。 请注意，路径应相对于项目的根目录。 这会将文件的较早版本放置在项目的暂存区域中。

如果您只想返回n次提交，则不需要哈希ID。 您只需发出命令git checkout HEAD~<n> -- /path/to/file ，其中<n>是您要返回的提交数。

如果要检出文件的整个目录 ，请对文件路径使用Git的通配符格式。 例如，输入git checkout HEAD~1 -- ./src/** . /src git checkout HEAD~1 -- ./src/**将使您退回一次提交，并从项目的根目录恢复/src目录中的所有内容。

这是大家都害怕的情况：不小心从存储库中删除了整个分支。 根据情况的不同，这可能很容易恢复，也可能比较棘手。

首先，使用git reflog查找对分支的最后一次提交。 然后使用哈希ID创建一个新分支：

git checkout -b restored-branch <hash_id>

请注意，只有在相关分支已合并的情况下，这才可以炸培根。 如果您强制删除了一个未合并的分支，那么您还可以找到另一种方法，前提是您尚未在存储库上运行git gc ：

git fsck --full --no-reflogs --unreachable --lost-found

这将转储不再可访问的对象（包括已删除的分支）的所有提交哈希值的列表。 从列表底部查找“无法到达的提交”条目，然后尝试将该哈希ID还原到新分支中，以查看它是否是您破坏的那个ID。 如果不是，请按顺序向上移动到下一个列表，然后查看可以恢复的内容。

通常，切勿默认情况下强制删除分支，因为您很容易最终将浪费浪费在尚未合并的分支中，该分支中仍包含有价值的东西。 如果您习惯性地强行删除分支机构，则这表明您使用分支机构的工作习惯需要减少混乱。

[ 同样在InfoWorld上：如何停止讨厌吉拉 ]

一旦我处理了GitHub存储库的本地副本，并错误地使用--force选项将我的master分支推送到了远程副本。 最后，我得到了当时不可用的回购的公共副本。 哎呀

如果您犯了这样的错误，并且您的存储库最近与远程存储库已同步，则可以使用自己的远程存储库分支副本进行修复。 假设您还不存在，请切换到需要重新同步的分支，然后发出以下命令：

git reset --hard <remote_repo>/<branch>@{1}

这会将您的<branch>副本重置为<remote_repo>的上一个同步版本。 在我的情况下，分支是master ，远程仓库是origin ，所以我可以使用git reset --hard origin/master@{1} 。

然后使用git push -f <remote_repo> <branch>将远程存储库恢复到其早期状态。

防止这种情况再次发生的一种方法是禁止强制推动。 您可以使用以下命令在远程Git存储库上进行配置：

git config --system receive.denyNonFastForwards true

有时候您需要进行推力操作，但最好在需要时将其打开，而在不需要时将其关闭。

这可能是最糟糕，最困难的Git问题。 您错误地将敏感数据提交到公共存储库，并且您想通过手术从存储库中删除文件。 您需要确保即使返回到较早的提交也无法找到敏感数据，但是您需要做到这一点而不要碰其他任何事情。

如果有问题的文件在六个星期前提交了，这将变得非常困难，同时，其他重要工作也已经完成了。 您不能只回滚到添加文件之前的状态。 您会破坏过程中的其他所有内容。

好消息：一些勇敢的Git专家创建了BFG Repo-Cleaner工具，专门用于从Git 仓库中删除不良数据。 BFG Repo-Cleaner允许您对存储库快速执行常规任务，例如删除所有匹配特定通配符或包含某些文本的文件。 您甚至可以传入一个列出所有不需要的文本的文件。

[ 通过InfoWorld的App Dev Report新闻通讯了解软件开发中的热门话题 ]

BFG Repo-Cleaner本质上是使用git filter-branch的多步过程自动化。 如果您想手动处理，GitHub上有详细的流程介绍。 但是BFG工具涵盖了绝大多数常见用例，其中许多都包含在该工具的命令行选项中。 此外，该过程很长且很复杂，如果您用手做的话，很容易在沿途某个地方用脚砸自己。

请注意，如果从必须在其他地方同步的本地分支中清除数据，则除非通过强制推送到远程分支，否则将无法同步。 整个提交树都必须重写，因此您实质上是在向远程写一个全新的历史记录。 您还需要确保更改后其他所有人都提取了新的重写存储库副本，因为他们的存储库也将不再有效。

From: https://www.infoworld.com/article/3512975/6-git-mistakes-you-will-make-and-how-to-fix-them.html