最近,我们发布了一些教程促使你了解 Git 基础知识和在团队环境中使用 Git。谈论的指令已经足够帮助一个开发者在 Git 世界中生存。在这次教程中,我们尝试如何在有效的时间内充分掌握提供的 Git 特性。
说明:文中一些指令包含指令的部分在方括号中(如:git add -p [file_name])。在这些案例中,你可以不用方括号,选择插入一些必要的数字,标识符等等,
如果你通过命令行运行 Git 命令,每一次通过手动敲来完成是令人烦恼的。为了帮助你做到这点,你可以使 Git 命令在几分钟内自动完成。
将下列脚本运行在 Unix 系统中。
cd ~
curl https://raw.github.com/git/git/master/contrib/completion/git-completion.bash -o ~/.git-completion.bash
接下来,在你的 ~/.bash_profile 文件中添加下面几行:
if [ -f ~/.git-completion.bash ]; then
. ~/.git-completion.bash
fi
尽管之前提到过,我仍然不能强调其重要性:如果你想充分运用 Git 的特性,你应该明确地转变对命令行的交互!
你是否对出现在你 Git 源中编译文件(如 .pyc)感到疲倦?或者对添加这些文件至 Git 上忍无可忍?不用舍近求远,这里有一种方式可以告诉 Git 忽视特定的文件和目录。只要创建一个名字为 .gitignore 的文件,并列出你不想让 Git 处理的文件和文件夹。你可以使用感叹号(!)来特殊处理。).
*.pyc
*.exe
my_db_config/
!main.pyc
当某些事出现问题时,责备其他人是人类的本性。如果你的产品服务器坏掉了,很容易查明真凶 —— 只需执行下 git blame指令。这个命令会显示每一个文件中每一行代码的作者,提交会看到当前行的最后一次变化,同时也提交时间戳。
`git blame [file_name]`
在屏幕截图下,你会看到这个命令就像一个巨大的源:
我们已经在以前的教程中了解过 git log 的运用了,但是这里仍然有你需要知道的三个选项。
-- online -- 将每次提交展示的信息压缩至精简的提交哈希和提交信息中,所有的展示在一行中。
-- graph -- 这个选项绘制了一个在输出左侧基于文本的图形展示的历史信息。如果你想看到每个分支的历史信息是无用的。
-- all -- 展示所有分支的历史信息。
下面是这些选项的组合:
让我们谈论那些你不想提交的,最后经过了一个艰难的重置回到你之前的状态。后面,你意识到这个过程丢失了一些其他的信息并想返回去,或者至少可以再次看下。这就是 git reflog 作用。
一个简单的 git log 命令可以显示最新的提交,上一次的提交,上上次的提交等等。然而,git reflog是一个被指向提交的列表。记住:这是你系统的局部,不是源的部分,不包含推送的和合并的。
如果执行 git log,我获取的提交信息是源的一部分。
然而,当你执行硬重置时,git reflog 展示了提交信息(b1b0ee9–HEAD@{4})是丢失的。
基于特性的提交通常是一个好的实践,也就是,每次提交都要展现出一个特性或修改的bug。想想如果你修复了两个bug会发生什么,或者添加多个特征却没有提交改变。在这种情况下,你可以将这些改变放在一个简单的提交中。但是,这里还有一个更好的方式,将文件单独地分段并分别提交他们。
让我们看看你做的几个改变至单个文件中,并想让他们出现在分离的提交中。在这种情况下,我们可以通过添加前缀 -p 来添加文件。
`git add -p [file_name]`
让我们来证明一致性。我已经添加了三个新行至 file_name,而且我仅想第一和第三行出现在提交信息中。让我们看看 git diff 展示给我们的信息。
让我们看看当我们添加一个前缀 -p 至 add 命令上发生了什么。
似乎 Git 假设所有的改变都是同样的,因此,将它们分成一个大块。你有下列选择:
输入 y 分成块
输入 n 不分块
输入 e 手动编辑块
输入 d 退出或者进入下一个文件
输入 s 分离块
在我们的案例中,我们当然想将它分离成小块,可以有选择地添加一部分并忽略其余的。
正如你所看到的,我们已经添加第一行和第三行的信息并忽略了第二行的信息。你可以查看源的状态并提交。
当你提交你的代码是为了查看和创建一个新的推送请求(在开源项目中经常出现),在接受前,你可以要求改变的你的代码。你做出改变,仅仅是要求改变它以便下次查看。在你知道前,你可以做一些额外的提交。理想地,你可以使用 rabase 指令压缩它们。
`git rebase -i HEAD~[number_of_commits]`
如果你想压缩上面两次的提交,你要执行的指令在下面。
`git rebase -i HEAD~2`
在运行这条指令时,会带你来到一个交互的界面中,列出提交的信息,并要求你压缩哪一个。理想地,你会选择最新的提交并压缩上一次的。
要求你为新提交的准备提交信息。这个处理基本上会覆盖你的提交历史。
让我们探讨你正在致力于某个 bug 和特征时,要求验证你的工作。你当前的工作不足够提交,并且你并不能在这个阶段给出一个证明(没有回复改变值)。在这种情况下,git stash 可以帮助你。Stash 基本上具有你所有的改变并保存它们以便你后期使用。为了保存这些变化,你需要运行以下命令:
`git stash`
为了核对保存的列表,你需要执行下面的命令:
`git stash list`
如果你想不保存和恢复未提交的变化,你可以应用下面的保存:
`git stash apply`
在最后一个截图中,你可以看到每次保存都有个标识符,一个唯一的数字(尽管我们仅仅在这种情况下保存)。如果你想只选择有选择性的保存,你可以添加特殊的标识符到 apply 命令中。
`git stash apply stash@{2}`
尽管 reflog 是核对上次丢失的提交信息的一种方法,但在大量的源中,不是可行的。这就是 fsck(文件系统核对) 命令要做的。
`git fsck --lost-found`
在这里,你可以看到丢失的提交信息。那你可以通过运行 git show [commit_hash] 来核对改变的提交信息,或者通过执行 git merge [commit_hash] 来回复它。
git fsck 相比 reflog 有一种优势。让我们看看你删除了一个远程的分支,然后克隆源。使用 fsck,你可以查询和恢复删除的远程分支。
在之前,我保存了很多简洁的 Git 指令。cherry-pick 指令是迄今为止我最喜欢的 Git 命令,是由于它的字面意义和它的功能!
用最简单的术语来说,cherry-pick 是从不同的分支中选择单个提交和将它和当前分支的合并。如果你在两个或更多的分支中工作,你可能会注意到 bug 会出现所有的分支。如果你在其中一个分支解决了这个 bug,你可以使用 cherry pick 提交至其他分支,不干扰其他文件或提交。
让我们想想可以运用的场景。我有两个分支,并且我想 cherry-pick 提交 b20fd14:清理垃圾:至另外一个分支。
切换分支至我想 cherry-pick 的提交,并执行以下指令:
`git cherry-pick [commit_hash]`
尽管我们已经清除了 cherry-pick 的时间,但是你应该知道这个命令可能经常导致冲突,因此要慎用。
以上,总结下小技巧清单,我认为可以帮你的 Git 技能达到一个新的台阶。Git 是最好的,可以实现任何你想象的。因此,要总是尝试挑战自己使用 Git。你很有可能会学到一些新的东西!
会见作者
Shaumik 是一个乐观主义者,但是一直都是一个人。他是印度 Roorkee 理工学院的一名本科生,也是博客的创始人之一,他喜欢写作,当他不忙时,总是保持写作的习惯。
原文来自:众成翻译
声明:所有来源为“聚合数据”的内容信息,未经本网许可,不得转载!如对内容有异议或投诉,请与我们联系。邮箱:marketing@think-land.com
通过企业关键词查询企业涉讼详情,如裁判文书、开庭公告、执行公告、失信公告、案件流程等等。
IP反查域名是通过IP查询相关联的域名信息的功能,它提供IP地址历史上绑定过的域名信息。
结合权威身份认证的精准人脸风险查询服务,提升人脸应用及身份认证生态的安全性。人脸风险情报库,覆盖范围广、准确性高,数据权威可靠。
全国城市和站点空气质量查询,污染物浓度及空气质量分指数、空气质量指数、首要污染物及空气质量级别、健康指引及建议采取的措施等。
输入手机号和拦截等级,查看是否是风险号码