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

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

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

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

这是一些更大的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。

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

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

Git错误#3:您垃圾了文件或目录

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

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

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

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

Git错误#4:您不小心删除了一个分支

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

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

git checkout -b restored-branch

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

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

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

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

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

Git错误#5:您使用git push破坏了远程分支

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

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

git reset --hard /@{1}

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

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

防止这种情况再次发生的一种方法是禁止强制推动。 您可以使用以下命令在远程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工具涵盖了绝大多数常见用例,其中许多都包含在该工具的命令行选项中。 此外,该过程很长且很复杂,如果您用手做的话,很容易在沿途某个地方用脚砸自己。

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

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

你可能感兴趣的:(git)