git --git-dir
开发人员使用诸如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~<n> --hard
,其中<n>
是您要返回的提交数。 或者,您可以使用git reset <nnnn>
,如果方便的话,其中<nnnn>
是目标提交的哈希ID。
为了避免这种错误,进入制作新的分支机构,并切换到他们,即使他们只是要被丢弃,只要您与您的代码开头的所有会话的习惯。
[ 同样在InfoWorld上:为什么C编程语言仍会统治 ]
Git错误#3:您垃圾了文件或目录
另一种常见的灾害被错误地捣毁一个文件的内容......只有在事后找出很多关于它提交到分支。 幸运的是,有一个简单的解决方法。
首先,使用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错误#4:您不小心删除了一个分支
这是大家都害怕的情况:不小心从存储库中删除了整个分支。 根据情况的不同,这可能很容易恢复,也可能比较棘手。
首先,使用git reflog
查找对分支的最后一次提交。 然后使用哈希ID创建一个新分支:
git checkout -b restored-branch <hash_id>
请注意,只有在相关分支已合并的情况下,这才可以炸培根。 如果您强制删除了一个未合并的分支,则可以在没有运行git gc
情况下找到它:
git fsck --full --no-reflogs --unreachable --lost-found
这将转储不再可访问的对象(包括已删除的分支)的所有提交哈希的列表。 从列表底部查找“无法到达的提交”条目,然后尝试将该哈希ID还原到新分支中,以查看它是否是您丢弃的那个。 如果不是,请按顺序向上移动到下一个列表,然后查看可以恢复的内容。
通常,切勿默认情况下强制删除分支,因为您很容易最终将浪费浪费在尚未合并的分支中,该分支中仍包含有价值的东西。 如果您习惯性地强行删除分支机构,则这表明您使用分支机构的工作习惯需要减少混乱。
[ 也在InfoWorld上:如何停止讨厌吉拉 ]
Git错误#5:您使用git push
破坏了远程分支
一旦我处理了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错误#6:您将私人信息提交给了公共仓库
这可能是最糟糕,最困难的Git问题。 您错误地将敏感数据提交到公共存储库,并且您想通过外科手段从存储库中删除文件。 您需要确保即使返回到较早的提交也无法找到敏感数据,但是您需要做到这一点而不触及其他任何东西。
如果有问题的文件在六个星期前提交了,这将变得非常困难,同时,其他重要工作也已经完成了。 您不能只是回滚到文件添加之前的状态。 您会破坏过程中的其他所有内容。
好消息:一些勇敢的Git专家创建了一个工具BFG Repo-Cleaner ,专门用于从Git 仓库中删除不良数据。 BFG Repo-Cleaner允许您对存储库快速执行常规任务,例如删除所有与特定通配符匹配或包含某些文本的文件。 您甚至可以传入一个列出所有不需要的文本的文件。
[ 通过InfoWorld的App Dev Report新闻通讯了解软件开发中的热门话题 ]
BFG Repo-Cleaner本质上是使用git filter-branch
的多步过程自动化。 如果您愿意手动处理,GitHub上有详细的流程介绍。 但是BFG工具涵盖了绝大多数常见用例,其中许多都包含在该工具的命令行选项中。 此外,该过程很长且很复杂,如果您用手做的话,很容易在沿途某个地方用脚砸自己。
请注意,如果您从必须在其他地方同步的本地分支中清除数据,则除非通过强制推送到远程分支,否则将无法同步。 整个提交树都必须重写,因此您实质上是在向远程写一个全新的历史记录。 您还需要确保更改后其他所有人都提取了新的重写存储库副本,因为他们的存储库也将不再有效。
翻译自: https://www.infoworld.com/article/3512975/6-git-mistakes-you-will-make-and-how-to-fix-them.html
git --git-dir