Gitbase 是一个由 Go 驱动的开源项目，它使得我们可以在 Git 仓库上运行 SQL 查询。

Git 已经成为了代码版本控制的事实标准。虽然 Git 已经很流行了，但想用它来对源代码仓库的历史和内容进行深度分析，仍然是一件复杂的事情。

另一方面，SQL 则是一个经过实际检验、适合查询大型代码库的的语言，毕竟 Spark 和 BigQuery 等项目都采用了 SQL 作为查询语言。

因此，在 source{d} 公司，我们顺理成章地结合了这两种技术来创建了 Gitbase：这是一个用 SQL 对 Git 仓库进行大规模分析的“代码即数据”解决方案。

Gitbase 是一个完全开源的项目，它站在一系列巨人的肩膀上，是它们使 Gitbase 的发展成为可能。本文旨在指出其中的主要部分。

Gitbase 试验场 提供了一种使用 Gitbase 的可视化方式。

使用 Vitess 解析 SQL

Gitbase 将 SQL 作为用户接口。这意味着我们需要解析基于 MySQL 协议传输的 SQL 请求，并理解它们。幸运的是，我们在 YouTube 的朋友和他们的 Vitess 项目已经实现了这一点。Vitess 是一个数据库集群系统，用于 MySQL 的水平扩展。

我们直接截取一些重要的代码片段，并把它做成了一个 开源项目。这个项目允许任何人在几分钟内编写一个 MySQL 服务器（正如我在 justforfunc 的专题：CSVQL - 用 SQL 处理 CSV 中所展示的那样）。

用 go-git 读取 Git 储存库

当成功解析了一个请求，我们还需要读取数据集里的 Git 仓库，才能够知道该如何回复它。为此，我们集成了 source{d} 最成功的仓库 go-git。go-git 是一个高度可扩展的纯 Go 语言的 Git 实现。

这使得我们能够轻松地分析以 siva 文件格式存储在磁盘上的源代码仓库（siva 也是一个 source{d} 的开源项目），或是直接使用 git clone 克隆的仓库。

使用 Enry 检测编程语言，使用 Babelfish 解析文件

Gitbase 并没有将其分析能力局限于 Git 历史记录上。它还使用（显然也是）我们的开源项目 Enry 集成了语言检测功能，并使用 Babelfish 实现了程序解析的功能。Babelfish 是一个用于通用源代码解析的自托管服务器，它可以将代码文件转化为 通用抽象语法树 Universal Abstract Syntax Trees （UAST）。

这两个功能在 Gitbase 中呈现为用户函数 LANGUAGE 和 UAST。结合使用两个函数，许多查询请求都成为了可能，比如“找到上个月修改次数最多的函数名称”。

让它快速运行

Gitbase 经常要分析非常大的数据集，比如公共 Git 档案，其中有来自 GitHub 的 3TB 源代码（见 公告）。为了做到这一点，每份 CPU 处理能力都很重要。

这就是为什么我们又集成了另外两个项目：Rubex 和 Pilosa。

使用 Rubex 和 Oniguruma 加快正则表达式的速度

Rubex 是 Go 的 regexp 标准库包的一个准替代品。之所以还不能完成替代，是因为他们没有在 regexp.Regexp 类型上实现 LiteralPrefix 方法，不过我也是直到现在才听说这个方法。

Rubex 的高性能得归功于高度优化的 C 语言库 Oniguruma，它使用 cgo 来调用这个库。

使用 Pilosa 索引加快查询速度

索引基本上是每个关系型数据库的众所周知的特性，但 Vitess 却没有实现索引，因为它不是真正需要。

还好开源的 Pilosa 再一次拯救了我们，它是一个用 Go 实现的分布式位图索引，使得 Gitbase 可以用于大规模的数据集。Pilosa 是开源的，它极大地加快了对多个海量数据集的查询。

总结

我想通过这篇博文，亲自感谢开源社区，是他们让我们在如此短的时间内创建了 Gitbase，这是谁也没想到的。在 source{d} 公司，我们是开源的坚定信仰者，github.com/src-d 下的每一行代码（包括我们的 OKR 和投资者委员会）都可以证明这一点。

你想尝试一下 Gitbase 吗？最快、最简单的方法就是使用 source{d} 引擎。从 sourced.tech/engine 下载它，只需一个命令就能让 Gitbase 运行起来。

想了解更多吗？请查看我在 Go SF meetup 的演讲录音。

这篇文章 最初发表在 Medium 上，经授权后在此重新发布。

via: https://opensource.com/article/18/11/gitbase

作者：Francesc Campoy 选题：lkxed 译者：lkxed 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

将这些命令加入到你的工作流中，使 Git 发挥更大的作用。

如果你经常使用 Git，你可能会知道它非常有名。它可能是最受欢迎的版本控制方案，它被一些 最大的软件项目 用来 跟踪文件变更。Git 提供了 健壮的界面 来审阅代码、把实验性的变更合并到已经存在的文件中。得益于 Git 钩子，它以灵活性而闻名。同时，也因为它的强大，它给人们留下了一个“复杂”的印象。

Git 有诸多特性，你不必全部使用，但是如果你正在深入研究 Git 的 子命令 subcommands ，我这里倒是有几个，或许你会觉得有用。

1、找到变更

如果你已经熟悉 Git 的基本指令（fetch、add、commit、push、log 等等），但是希望学习更多，那么从 Git 的检索子命令开始是一个简单安全的选择。检索你的 Git 仓库（你的 工作树）并不会做出任何更改，它只是一个报告机制。你不会像使用 git checkout 一样承担数据完整性的风险，你只是在向 Git 请求仓库的当前状态和历史记录而已。

git whatchanged 命令（几乎本身就是一个助记符）可以查看哪些文件在某个 提交 commit 中有变更、分别做了什么变更。它是一个简单的、用户友好的命令，因为它把 show、diff-tree 和 log 这三个命令的最佳功能整合到了一个好记的命令中。

2、使用 git stash 管理变更

你越多地使用 Git，你就会使用 Git 越多。这就是说，一旦你习惯了 Git 的强大功能，你就会更频繁地使用它。有时，你正在处理一大堆文件，忽然意识到了有更紧急的任务要做。这时，在 git stash 的帮助下，你就可以把所有正在进行的工作收集起来，然后安全地 暂存 stash 它们。当你的工作空间变得整洁有序，你就可以把注意力放到别的任务上，晚些时候再把暂存的文件重新加载到工作树里，继续之前的工作。

3、使用 git worktree 来得到链接的副本

当 git stash 不够用的时候，Git 还提供了强大的 git worktree 命令。有了它，你可以新建一个 链接的 仓库 副本 clone ，组成一个新分支，把 HEAD 设置到任意一个提交上，然后基于这个分支开始你的新工作。在这个链接的副本里，你可以进行和主副本完全不同的任务。这是一个避免意外的变更影响当前工作的好办法。当你完成了你的新工作，你可以把新分支推送到远程仓库；也可以把当前的变更归档，晚些时候再处理；还可以从别的工作树中获取它们的变更。无论选择哪一种，你的工作空间之间都会保持相互隔离，任一空间中的变更都不会影响其他空间中的变更，直到你准备好了要合并它们。

4、使用 git cherry-pick 来选择合并

这可能听起来很反直觉，但是，你的 Git 水平越高，你可能遇到的合并冲突就会越多。这是因为合并冲突不一定是错误的标志，而是活跃的标志。在学习 Git 中，适应合并时的冲突，并学会如何解决它们是非常重要的。通常的方式或许够用，但是有时候你会需要更加灵活地进行合并，这时候就该 git cherry-pick 出场了。遴选操作允许你选择部分合并提交，这样一来你就不需要因为一些细微的不协调而拒绝整个合并请求了。

5、使用 Git 来管理 $HOME

使用 Git 来管理你的主目录从来没有这么简单过，这都要归功于 Git 可以自由选择管理对象的能力，这是一个在多台计算机之间保持同步的现实可行的选项。但是，想要让它工作顺利，你必须非常明智且谨慎才行。如果你想要了解更多，点击阅读我写的关于 使用 Git 来管理 $HOME 的小技巧。

更好地使用 Git

Git 是一个强大的版本控制系统，你使用得越熟练，就可以越轻松地借助它来完成复杂的任务。今天就尝试一些新的 Git 命令吧，欢迎在评论区分享你最喜欢的 Git 命令。

via: https://opensource.com/article/21/4/git-commands

作者：Seth Kenlon 选题：lujun9972 译者：lkxed 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

这些文章包含了黑科技、鲜为人知的事实，以及在使用 Git 时可以派上用场的技巧和窍门。

Git 是代码协作开发工作流程中不可或缺的一部分。无论你是初学者还是专家，第一件事就是在使用开源代码时需要学习这个功能强大的版本控制系统。对于 Git，不需要知道所有事情，但是了解一些特殊的黑科技可以让你在 GitLab 等平台上更轻松地分享代码，因此你可以与不同地方的开发人员协作。如果有什么没把握的地方，git --help 可以帮助你。

我每天都为了解 Git 所提供的控制能力而感到惊讶。没有哪种情况是你无法恢复到早期版本的，无论你所处的情况是多么不可能或棘手。

在 2021 年我们发布了大量 Git 的文章；我只汇总了其中前 10 篇，这些文章包含了各种黑科技、鲜为人知的事实，以及在使用 Git 时可以派上用场的技巧和窍门。

使用 git stash 命令的实用指南

Ramakrishna Pattnaik 解释了 git stash 命令 的功能。这篇文章重点介绍 git stash 如何帮助你列出、检查、保存和恢复更改，以确保切换分支时的无忧体验。它还可以帮助你跟踪在本地无需提交的更改，而同时保持干净的工作目录。

5 个让你的 Git 技能更上一层楼的 Git 命令

Seth Kenlon 详细介绍了 五个鲜为人知的 Git 命令，它们可以让你的生活更轻松。开发人员可以使用 git whatchanged、git stash、git worktree 和 git cherry-pick 等命令来节省时间。

Git cherry-pick 简介

Rajeev Bera 教程将引导你了解 git cherry-pick 命令 是什么，为什么和如何使用它，并列出 git cherry-pick 可以帮助你避免棘手的情况所有用例。

3 个使用 git cherry-pick 命令的原因

我分享了 利用 git cherry-pick 如何帮助你避免冗余，一次性处理多个提交并恢复丢失的更改。

使用 git worktree 自由地尝试你的代码

git stash 命令负责将更改保存到工作目录。Seth Kenlon 向我们介绍了 git worktree 和几个 git worktree 用例，它们可以帮助你将存储库恢复到已知状态。

Git 上下文切换的 4 个技巧

Olaf Alders 的这篇文章讨论了使用 Git 时 切换分支的四种不同方式 的利弊。这些选项将帮助你简化工作流程，并保持干净的工作目录，而不会丢失你的更改。

查找 Git 提交中的更改

Seth Kenlon 解释了如何利用如 git log 和 git whatchanged 等简单命令来提取有关 Git 提交内容中更改的特定信息。这是一个有用的快捷方式，而且名字很容易记住。

管理主目录的 7 个 Git 技巧

Seth Kenlon 分享了 使用 Git 管理和组织 $HOME 变量 的注意事项，并解释了它如何让他的跨设备生活更实用。更好的是，这让他可以自由地尝试新想法，因为他知道他可以轻松地将它们回滚。

GitOps 与 DevOps：有什么区别？

Bryant Son 向你介绍了 GitOps，他将其描述为 DevOps 的进化版本，它使用 Git 作为单一事实来源。这篇文章还列出了其它有用资源，可用于学习 DevOps 并在开源领域找到工作。

开始使用 Argo CD

Ayush Sharma 详细介绍了 Argo CD 的优势，这是一种基于拉取式的 GitOps 开发工具。Argo CD 通过在 Git 中管理 Kubernetes 清单并将它们同步到集群中，为你提供两全其美的体验。

你能想到其他让你的生活更轻松的 Git 技巧吗？请在评论中告诉我们。

via: https://opensource.com/article/22/1/git-tutorials

作者：Manaswini Das 选题：lujun9972 译者：stevenzdg988 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

基本的 Git 命令 对于通常的克隆、添加、提交推送已经足够好了。

但如果你在一个有多个贡献者的大型项目上工作，你可能需要将事情可视化。GUI 工具可以让你更好地了解 diff、stash 和 blame 的情况。

但是，如果你常用终端，又想要 Git 的舒适性，我为你准备了一个好工具。

它叫 GitUI，它提供了类似于 Git GUI 的用户体验和舒适度，但就在你的终端中。它是可移植的、快速的、自由而开源的。

GitUI：一个基于终端的 Git 工具

GitUI 并不是第一个用于 Linux 终端的 Git 客户端。那么，是什么让 GitUI 与其他类似项目如 lazygit 或 tig 不同？

GitUI 的开发者在项目的 README 文件中分享了一些基准数据。

GitUI、LazyGit 和 Tig 之间的比较。

这种优化大部分来自于 Rust 语言的使用。

注意：该程序处于早期开发阶段，还没有为生产做好准备。

在 Linux 上安装 GitUI

不用说，你应该已经 在你的系统上安装了 Git。

要使用 GitUI，首先需要 为你的 Linux 发行版安装 Rust 支持。

在终端中，使用以下命令：

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

当你被要求选择时，请选择选项 1。当脚本完成安装后，用这个命令正确设置配置：

source $HOME/.cargo/env

现在你已经安装了 Rust 和它的包管理器 Cargo，使用 Cargo 命令来安装 GitUI：

cargo install gitui

然后你就可以使用 GitUI了，只需在终端输入 gitui 就可以运行了。我做了一些示例文件来测试 Git 和 GitUI。

值得一提的是，这个界面有一个快速而直观的纯键盘控制。一切都很简单，只需输入正确的字母即可将文件暂存、提交、分支或推送到 git 仓库中。

真正让我兴奋的是，你不仅可以做之前的四个动作，还可以编辑每个文件，拉取它，追溯 它，在其中导航等等，这一切都无需退出界面。 很棒，不是吗？

祝贺你! 现在你知道了如何安装 GitUI 以及它在你的终端中的样子。

如果你喜欢这个项目，请在 GitHub 上点赞它的仓库。如果你使用其他工具来管理 Git，请在评论区提出你的建议。

via: https://itsfoss.com/gitui/

作者：Marco Carmona 选题：lujun9972 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

我使用 Vim 和 Git 来写小说。是的，你也可以用 Git 来完成非编码任务。

我相信当代的写作者们应该开始思考他们的工作流程了。

在一个注意力高度分散的世界里，作为写作者，我们必须对每天执行的任务链拥有控制权。传统上，作家们会把他们的写作放在分散注意力的事较少、注意力高度集中的时间段。不幸的是，海明威、阿特伍德们的这些建议不再真正适用于我们了。我们所生活的世界联系得更紧密了，因此对作家来说就有了更多的陷阱。这首先要求我们要有足够的自制力，不要让社交媒体或小狗和小猫的可爱视频在我们写作的时候分散我们的注意力。

但是，如果你的写作需要快速地检查事实、拼写不常见和技术性的词汇等，断开与互联网连接并不是一个现实的选项 —— 这正是我写作时的场景。另一个问题是你用于写作的应用程序本身的干扰；作为一个长期使用 MS Word 的人，我发现它越来越漂亮，但速度越来越慢，也越来越让人分心。作为当初我 迁移到 Vim 的主要原因 之一，我曾详细地谈到了这一点，所以我不打算再在这个问题上大谈特谈。重点是，在现代世界中，在现代设备上进行写作，可能远非理想状态。

因为我已经详细介绍过了 我为什么转向 Vim 和开源版本控制，在这篇文章中，我更想谈谈该 怎么做，特别是如何使用开源的版本控制技术，比如 Git（和 GitHub）。

什么是版本控制？再来一次？

上图是我们如何进行传统版本控制的一个说明。这个图中假设你有一台设备，而且你只在那台设备上写作。但对我而言，我在许多机器上写作，包括我的安卓手机和一些不同年代的笔记本电脑，我会在特定的任务、特定的位置使用到它们。我在所有这些设备上进行的一个共同任务就是写作 —— 因此，我的设备必须以合理的方式捕捉变化并控制文件的版本。不要再让我将 file1V1_device1_date.doc 作为文件名了。

上图也没有考虑到我们用来写作的工具。像 LibreOffice Write 这样的文字处理器可以在 Linux、Mac 和 Windows 系统上使用，但在手机上使用文字处理器将会是一段不愉快的经历。我们中的一些写作者还使用其他文本工具（包括 Gmail 或我们的电子邮件客户端）来为我们的写作打草稿。但按逻辑顺序跟踪所有这些文件和电子邮件是相当折磨人的，我就用这样的流程写过一本书，相信我：我花在弄清文件名、版本变化、评论、给自己的注释以及带有附加注释的电子邮件上的时间，足以让我精神错乱。

读到这里，你们中的一些人可能会正确地指出，有云备份技术呀。虽然云存储的好处是巨大的，而且我也在继续使用它们，但其版本控制几乎不存在，或者说并不强大。

一个更好的工作流程

就像地球上的其它地方一样，大流行病的开始引发了一些焦虑和一些反思。我利用这段时间在 The Odin Project（强烈推荐给那些想学习 html、CSS、JavaScript/Ruby 的人）上自学了网络开发。

在课程的第一个模块中，有一个关于 Git 的介绍：什么是版本控制，以及它试图解决什么问题。读了这一章后，我豁然开朗。我立即意识到，这个 Git 正是我作为一个写作者所要寻找的东西。

是的，更好的方法不是本地化的版本控制，而是 分布式 的版本控制。“分布式”描述的是设备的分布，而我在这些设备上访问文件，以及之后进行编辑修改。下图是分布式版本控制的一个直观说明。

我的方法

我为写作建立一个版本控制系统的目标如下：

• 使我的稿件库可以从任何地方、任何设备上访问
• 易于使用
• 减少或消除因在写作、学习和编码各工作流程之间的场景切换而产生的摩擦 —— 尽可能使用同一工具（即 Vim）。
• 可扩展性
• 易于维护

基于以上需求，下图是我进行写作的分布式版本控制系统。

如你所见，我的版本控制系统是分布式版本控制的一个简单的适配。在我的例子中，通过将 Git 版本控制应用到云存储（pCloud）的一个文件夹上，我可以同时利用这两种技术的优点。因此，我的工作流程可以用下图描述：

优势

1. 我用一个写作（和编码）工具
2. 我可以对我的手稿进行版本控制，无论我是从什么设备上访问文件的
3. 超级简单，几乎没有任何不便之处
4. 易于维护

缺点

你们中的写作者一定想知道这个系统存在什么缺点。以下是我在持续使用和完善这一工作流程时预计到的几个问题。

• 对草稿的评论：文字处理器的一个更有用的功能是具有评论的功能。当我希望以后再回到文本的某一部分时，我经常在这部分为自己留下一个评论。我仍然没有想出一个解决这个问题的办法。
• 协作：文字处理程序允许写作者之间进行协作。在我以前做广告相关工作的时候，我会用 Google Docs 来写文案，然后分享链接给我的设计师，从而他可以为广告和网站对文案进行摘录。现在，我的解决方法是用 Markdown 写文案，并通过 Pandoc 将 Markdown 文件导出为 .doc 文件。更关键的是，当我的手稿完成后，我仍然需要将文件以 .doc 格式发送给我的编辑。一旦我的编辑做了一些修改并把它发回来，我再尝试用 Vim 打开它就没有意义了。在这一点上，该系统的局限性变得更加明显。

我并不是说这是最好的方法，但在我职业生涯的这个阶段，这是对我来说最好的方法。我想，随着我对我的新的 用于写作的开源工具 和版本控制越来越熟悉和适应，我将进一步完善这个方法。

我希望这篇文章能为那些想使用 Git 进行文档版本控制的写作者提供一个很好的介绍。这肯定不是一篇详尽的文章，但我将分享一些有用的链接，使你的旅程更容易。

1. The Odin Project 介绍的 Git 基础知识
2. 开始使用 Git
3. GitHub 的 Git 基础知识教程

via: https://news.itsfoss.com/version-control-writers/

作者：Theena 选题：lujun9972 译者：piaoshi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

这些有用的小技巧将改变你在当前最流行的版本控制系统下的工作方式。

Git 是当前最流行最普遍的版本控制系统之一，它被应用于私有系统和公开网站上各种各样的开发工作。不论我变得对 Git 有多熟悉，似乎总有些功能等待着被发掘。下面分享下和 Git 相关的改变我工作方式的一些小技巧。

1、Git 中的自动纠错

我们每个人都不时在输入时犯拼写错误，但是如果你使能了 Git 的自动纠错功能，你就能让 Git 自动纠正一些输入错误的子命令。

假如你想用命令 git status 来检查状态，但是你恰巧错误地输入了 git stats。通常情况下，Git 会告诉你 ‘stats’ 不是个有效的命令：

$ git stats
git: ‘stats’ is not a git command. See ‘git --help’.

The most similar command is
status

为了避免类似情形，只需要在你的 Git 配置中使能自动纠错功能。

$ git config --global help.autocorrect 1

如果你只想对当前的仓库生效，就省略掉选项 --global。

这个命令会使能自动纠错功能。在相应的 Git 官方文档 中可以看到这个命令的详细说明，但是试着敲一下上面的错误命令会使你对这个设置干了什么有个直观的了解：

$ git stats
git: ‘stats’ is not a git command. See ‘git --help’.
On branch master
Your branch is up to date with ‘origin/master’.

nothing to commit, working tree clean

在上面的例子中，Git 直接运行了它建议命令的第一个，也就是 git status，而不是给你展示它所建议的子命令。

2、对提交进行计数

需要对提交进行计数的原因有很多。例如，一些开发人员利用提交计数来判断什么时候递增工程构建序号，也有一些开发人员用提交计数来对项目进展取得一个整体上的感观。

对提交进行计数相当简单而且直接，下面就是相应的 Git 命令：

$ git rev-list --count branch-name

在上述命令中，参数 branch-name 必须是一个你当前仓库里的有效分支名。

$ git rev-list –count master
32
$ git rev-list –count dev
34

3、仓库优化

你的代码仓库不仅对你来说很宝贵，对你所在的组织也一样。通过少数几个惯例你就能使自己的仓库整洁并且保持最新。使用 .gitignore 文件 就是这些最好的惯例之一。通过使用这个文件你可以告诉 Git 不要保存一些不需要记录的文件，如二进制文件、临时文件等等。

当然，你还可以使用 Git 的垃圾回收来进一步优化你的仓库。

$ git gc --prune=now --aggressive

这个命令在你和你的团队经常使用 pull 或者 push 操作的时候很有帮助。

它是一个内部工具，能清理掉你的仓库里没法访问或者说“空悬”的 Git 对象。

4、给未追踪的文件来个备份

大多数时候，删除所有未追踪的文件是安全的。但很多时候也有这么一种场景，你想删掉这些未追踪的文件同时也想做个备份防止以后需要用到。

Git 组合一些 Bash 命令和管道操作，可以让你可以很容易地给那些未追踪的文件创建 zip 压缩包。

$ git ls-files --others --exclude-standard -z |\
  xargs -0 tar rvf ~/backup-untracked.zip

上面的命令就生成了一个名字为 backup-untracked.zip 的压缩包文件（当然，在 .gitignore 里面忽略了的文件不会包含在内）。

5、了解你的 .git 文件夹

每个仓库都有一个 .git 文件夹，它是一个特殊的隐藏文件夹。

$ ls -a
. … .git

Git 主要通过两个东西来工作：

1. 当前工作树（你当前检出的文件状态）
2. 你的 Git 仓库的文件夹（准确地说，包含版本信息的 .git 文件夹的位置）

这个文件夹存储了所有参考信息和一些其他的如配置、仓库数据、HEAD 状态、日志等更多诸如此类的重要细节。

一旦你删除了这个文件夹，尽管你的源码没被删，但是类似你的工程历史记录等远程信息就没有了。删除这个文件夹意味着你的工程（至少本地的复制）不再在版本控制的范畴之内了。这也就意味着你没法追踪你的修改；你没法从远程仓拉取或推送到远程仓了。

通常而言，你需要或者应当对你的 .git 文件夹的操作并不多。它是被 Git 管理的，而且大多数时候是一个禁区。然而，在这个文件夹内还是有一些有趣的工件，比如说当前的 HEAD 状态在内的就在其中。

$ cat .git/HEAD
ref: refs/heads/master

它也隐含着对你仓库地描述：

$ cat .git/description

这是一个未命名的仓库；通过编辑文件 ‘description’ 可以给这个仓库命名。

Git 钩子文件夹连同一些钩子文件例子也在这里。参考这些例子你就能知道 Git 钩子能干什么了。当然，你也可以 参考这个 Seth Kenlon 写的 Git 钩子介绍。

6、浏览另一个分支的文件

有时，你会想要浏览另一个分支下某个文件的内容。这其实用一个简单的 Git 命令就可以实现，甚至都不用切换分支。

设想你有一个命名为 README.md 的文件，并且它在 main 分支上。当前你正工作在一个名为 dev 的分支。

用下面的 Git 命令，在终端上就行。

$ git show main:README.md

一旦你执行这个命令，你就能在你的终端上看到 main 分支上该文件的内容。

7、Git 中的搜索

用一个简单的命令你就能在 Git 中像专业人士一样搜索了。更有甚者，尽管你不确定你的修改在哪次提交或者哪个分支上，你依然能搜索。

$ git rev-list --all | xargs git grep -F ''

例如，假设你想在你的仓库中搜索字符串 “font-size: 52 px;" ：

$ git rev-list –all | xargs git grep -F ‘font-size: 52 px;’
F3022…9e12:HtmlTemplate/style.css: font-size: 52 px;
E9211…8244:RR.Web/Content/style/style.css: font-size: 52 px;

试试这些小技巧

我希望这些小技巧对你是有用的，或者增加你的生产力或者节省你的大量时间。

你也有一些喜欢的 Git 技巧 吗？在评论区分享吧。

via: https://opensource.com/article/20/10/advanced-git-tips

作者：Rajeev Bera 选题：lujun9972 译者：BoosterY 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出