我觉得前几天的 curl 练习进展顺利，所以今天我醒来后，想尝试编写一些 Git 练习。Git 是一大块需要学习的技能，可能要花几个小时才能学会，所以我分解练习的第一个思路是从“导航”一个存储库开始的。

我本来打算使用一个玩具测试库，但后来我想，为什么不使用真正的存储库呢？这样更有趣！因此，我们将浏览 Ruby 编程语言的存储库。你无需了解任何 C 即可完成此练习，只需熟悉一下存储库中的文件随时间变化的方式即可。

克隆存储库

开始之前，需要克隆存储库：

git clone https://github.com/ruby/ruby

与实际使用的大多数存储库相比，该存储库的最大不同之处在于它没有分支，但是它有很多标签，它们与分支相似，因为它们都只是指向一个提交的指针而已。因此，我们将使用标签而不是分支进行练习。改变标签的方式和分支非常不同，但查看标签和分支的方式完全相同。

Git SHA 总是引用同一个代码

执行这些练习时要记住的最重要的一点是，如本页面所述，像9e3d9a2a009d2a0281802a84e1c5cc1c887edc71 这样的 Git SHA 始终引用同一个的代码。下图摘自我与凯蒂·西勒·米勒撰写的一本杂志，名为《Oh shit, git!》。（她还有一个名为 https://ohshitgit.com/ 的很棒的网站，启发了该杂志。）

我们将在练习中大量使用 Git SHA，以使你习惯于使用它们，并帮助你了解它们与标签和分支的对应关系。

我们将要使用的 Git 子命令

所有这些练习仅使用这 5 个 Git 子命令：

git checkout
git log (--oneline, --author, and -S will be useful)
git diff (--stat will be useful)
git show
git status

练习

1. 查看 matz 从 1998 年开始的 Ruby 提交。提交 ID 为 3db12e8b236ac8f88db8eb4690d10e4a3b8dbcd4。找出当时 Ruby 的代码行数。
2. 检出当前的 master 分支。
3. 查看文件 hash.c 的历史记录。更改该文件的最后一个提交 ID 是什么？
4. 了解最近 20 年来 hash.c 的变化：将 master 分支上的文件与提交 3db12e8b236ac8f88db8eb4690d10e4a3b8dbcd4 的文件进行比较。
5. 查找最近更改了 hash.c 的提交，并查看该提交的差异。
6. 对于每个 Ruby 版本，该存储库都有一堆标签。获取所有标签的列表。
7. 找出在标签 v1_8_6_187 和标签 v1_8_6_188 之间更改了多少文件。
8. 查找 2015 年的提交（任何一个提交）并将其检出，简单地查看一下文件，然后返回 master 分支。
9. 找出标签 v1_8_6_187 对应的提交。
10. 列出目录 .git/refs/tags。运行 cat .git/refs/tags/v1_8_6_187 来查看其中一个文件的内容。
11. 找出当前 HEAD 对应的提交 ID。
12. 找出已经对 test/ 目录进行了多少次提交。
13. 提交 65a5162550f58047974793cdc8067a970b2435c0 和 9e3d9a2a009d2a0281802a84e1c5cc1c887edc71 之间的 lib/telnet.rb 的差异。该文件更改了几行？
14. 在 Ruby 2.5.1 和 2.5.2 之间进行了多少次提交（标记为 v2_5_1 和 v2_5_3）（这一步有点棘手，步骤不只一步）
15. “matz”（Ruby 的创建者）作了多少提交？
16. 最近包含 “tkutil” 一词的提交是什么？
17. 检出提交 e51dca2596db9567bd4d698b18b4d300575d3881 并创建一个指向该提交的新分支。
18. 运行 git reflog 以查看你到目前为止完成的所有存储库导航操作。 ——————————————————————————–

via: https://jvns.ca/blog/2019/08/30/git-exercises–navigate-a-repository/

作者：Julia Evans 选题：lujun9972 译者：wxy 校对：wxy

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

GIC 是一个聊天应用程序的原型，展示了一种使用 Git 的新方法。

Git 是一个少有的能将如此多的现代计算封装到一个程序之中的应用程序，它可以用作许多其他应用程序的计算引擎。虽然它以跟踪软件开发中的源代码更改而闻名，但它还有许多其他用途，可以让你的生活更轻松、更有条理。在这个 Git 系列中，我们将分享七种鲜为人知的使用 Git 的方法。

今天我们来看看 GIC，它是一个基于 Git 的聊天应用。

初识 GIC

虽然 Git 的作者们可能期望会为 Git 创建前端，但毫无疑问他们从未预料到 Git 会成为某种后端，如聊天客户端的后端。然而，这正是开发人员 Ephi Gabay 用他的实验性的概念验证应用 GIC 所做的事情：用 Node.js 编写的聊天客户端，使用 Git 作为其后端数据库。

GIC 并没有打算用于生产用途。这纯粹是一种编程练习，但它证明了开源技术的灵活性。令人惊讶的是，除了 Node 库和 Git 本身，该客户端只包含 300 行代码。这是这个聊天客户端和开源所反映出来的最好的地方之一：建立在现有工作基础上的能力。眼见为实，你应该自己亲自来了解一下 GIC。

架设起来

GIC 使用 Git 作为引擎，因此你需要一个空的 Git 存储库为聊天室和记录器提供服务。存储库可以托管在任何地方，只要你和需要访问聊天服务的人可以访问该存储库就行。例如，你可以在 GitLab 等免费 Git 托管服务上设置 Git 存储库，并授予聊天用户对该 Git 存储库的贡献者访问权限。（他们必须能够提交到存储库，因为每个聊天消息都是一个文本的提交。）

如果你自己托管，请创建一个中心化的裸存储库。聊天中的每个用户必须在裸存储库所在的服务器上拥有一个帐户。你可以使用如 Gitolite 或 Gitea 这样的 Git 托管软件创建特定于 Git 的帐户，或者你可以在服务器上为他们提供个人用户帐户，可以使用 git-shell 来限制他们只能访问 Git。

自托管实例的性能最好。无论你是自己托管还是使用托管服务，你创建的 Git 存储库都必须具有一个活跃分支，否则 GIC 将无法在用户聊天时进行提交，因为没有 Git HEAD。确保分支初始化和活跃的最简单方法是在创建存储库时提交 README 或许可证文件。如果你没有这样做，你可以在事后创建并提交一个：

$ echo "chat logs" > README
$ git add README
$ git commit -m 'just creating a HEAD ref'
$ git push -u origin HEAD

安装 GIC

由于 GIC 基于 Git 并使用 Node.js 编写，因此必须首先安装 Git、Node.js 和 Node 包管理器npm（它应该与 Node 捆绑在一起）。安装它们的命令因 Linux 或 BSD 发行版而异，这是 Fedora 上的一个示例命令：

$ sudo dnf install git nodejs

如果你没有运行 Linux 或 BSD，请按照 git-scm.com 和 nodejs.org 上的安装说明进行操作。

因此，GIC 没有安装过程。每个用户（在此示例中为 Alice 和 Bob）必须将存储库克隆到其硬盘驱动器：

$ git clone https://github.com/ephigabay/GIC GIC

将目录更改为 GIC 目录并使用 npm 安装 Node.js 依赖项：

$ cd GIC
$ npm install

等待 Node 模块下载并安装。

配置 GIC

GIC 唯一需要的配置是 Git 聊天存储库的位置。编辑 config.js 文件：

module.exports = {
  gitRepo: '[email protected]:/home/gitchat/chatdemo.git',
  messageCheckInterval: 500,
  branchesCheckInterval: 5000
};

在尝试 GIC 之前测试你与 Git 存储库的连接，以确保你的配置是正确的：

$ git clone --quiet [email protected]:/home/gitchat/chatdemo.git > /dev/null

假设你没有收到任何错误，就可以开始聊天了。

用 Git 聊天

在 GIC 目录中启动聊天客户端：

$ npm start

客户端首次启动时，必须克隆聊天存储库。由于它几乎是一个空的存储库，因此不会花费很长时间。输入你的消息，然后按回车键发送消息。

基于 Git 的聊天客户端。 他们接下来会怎么想？

正如问候消息所说，Git 中的分支在 GIC 中就是聊天室或频道。无法在 GIC 的 UI 中创建新分支，但如果你在另一个终端会话或 Web UI 中创建一个分支，它将立即显示在 GIC 中。将一些 IRC 式的命令加到 GIC 中并不需要太多工作。

聊了一会儿之后，可以看看你的 Git 存储库。由于聊天发生在 Git 中，因此存储库本身也是聊天日志：

$ git log --pretty=format:"%p %cn %s"
4387984 Seth Kenlon Hey Chani, did you submit a talk for All Things Open this year?
36369bb Chani No I didn't get a chance. Did you?
[...]

退出 GIC

Vim 以来，还没有一个应用程序像 GIC 那么难以退出。你看，没有办法停止 GIC。它会一直运行，直到它被杀死。当你准备停止 GIC 时，打开另一个终端选项卡或窗口并发出以下命令：

$ kill `pgrep npm`

GIC 是一个新奇的事物。这是一个很好的例子，说明开源生态系统如何鼓励和促进创造力和探索，并挑战我们从不同角度审视应用程序。尝试下 GIC，也许它会给你一些思路。至少，它可以让你与 Git 度过一个下午。

via: https://opensource.com/article/19/4/git-based-chat

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

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

像源代码一样对待时间并在 Git 的帮助下维护你的日历。

Git 是一个少有的能将如此多的现代计算封装到一个程序之中的应用程序，它可以用作许多其他应用程序的计算引擎。虽然它以跟踪软件开发中的源代码更改而闻名，但它还有许多其他用途，可以让你的生活更轻松、更有条理。在这个 Git 系列中，我们将分享七种鲜为人知的使用 Git 的方法。

今天，我们将使用 Git 来跟踪你的日历。

使用 Git 跟踪你的日程安排

如果时间本身只是可以管理和版本控制的源代码呢？虽然证明或反驳这种理论可能超出了本文的范围，但在 Git 的帮助下，你可以将时间视为源代码并管理你的日程安排。

日历的卫冕冠军是 CalDAV 协议，它支撑了如 NextCloud 这样的流行的开源及闭源的日历应用程序。CalDAV 没什么问题（评论者，请注意），但它并不适合所有人，除此之外，它还有一种不同于单一文化的鼓舞人心的东西。

因为我对大量使用 GUI 的 CalDAV 客户端没有兴趣（如果你正在寻找一个好的终端 CalDAV 查看器，请参阅 khal），我开始研究基于文本的替代方案。基于文本的日历具有在明文中工作的所有常见好处。它很轻巧，非常便携，只要它结构化，就很容易解析和美化（无论美丽对你意味着什么）。

最重要的是，它正是 Git 旨在管理的内容。

Org 模式不是一种可怕的方式

如果你没有对你的明文添加结构，它很快就会陷入一种天马行空般的混乱，变成恶魔才能懂的符号。幸运的是，有一种用于日历的标记语法，它包含在令人尊敬的生产力 Emacs 模式 —— Org 模式 中（承认吧，你其实一直想开始使用它）。

许多人没有意识到 Org 模式的惊人之处在于你不需要知道甚至不需要使用 Emacs来利用 Org 模式建立的约定。如果你使用 Emacs，你会得到许多很棒的功能，但是如果 Emacs 对你来说太难了，那么你可以实现一个基于 Git 的 Org 模式的日历系统，而不需要安装 Emacs。

关于 Org 模式你唯一需要知道的部分是它的语法。Org 模式的语法维护成本低、直观。使用 Org 模式而不是 GUI 日历应用程序进行日历记录的最大区别在于工作流程：你可以创建一个任务列表，然后每天分配一个任务，而不是转到日历并查找要安排任务的日期。

组织模式中的列表使用星号（*）作为项目符号。这是我的游戏任务列表：

* Gaming
** Build Stardrifter character
** Read Stardrifter rules
** Stardrifter playtest

** Blue Planet @ Mike's

** Run Rappan Athuk
*** Purchase hard copy
*** Skim Rappan Athuk
*** Build Rappan Athuk maps in maptool
*** Sort Rappan Athuk tokens

如果你熟悉 CommonMark 或 Markdown，你会注意到，Org 模式不是使用空格来创建子任务，而是更明确地使用了其它项目符号。无论你的使用背景和列表是什么，这都是一种构建列表的直观且简单的方法，它显然与 Emacs 没有内在联系（尽管使用 Emacs 为你提供了快捷方式，因此你可以快速地重新排列列表）。

要将列表转换为日历中的计划任务或事件，请返回并添加关键字 SCHEDULED 和（可选）:CATEGORY:。

* Gaming
:CATEGORY: Game
** Build Stardrifter character
SCHEDULED: <2019-03-22 18:00-19:00>
** Read Stardrifter rules
SCHEDULED: <2019-03-22 19:00-21:00>
** Stardrifter playtest
SCHEDULED: <2019-03-25 0900-1300>
** Blue Planet @ Mike's
SCHEDULED: <2019-03-18 18:00-23:00 +1w>

and so on...

SCHEDULED 关键字将该条目标记为你希望收到通知的事件，并且可选的 :CATEGORY: 关键字是一个可供你自己使用的任意标记系统（在 Emacs 中，你可以根据类别对条目使用颜色代码）。

对于重复事件，你可以使用符号（如+1w）创建每周事件或 +2w 以进行每两周一次的事件，依此类推。

所有可用于 Org 模式的花哨标记都记录于文档，所以不要犹豫，找到更多技巧来让它满足你的需求。

放进 Git

如果没有 Git，你的 Org 模式的日程安排只不过是本地计算机上的文件。这是 21 世纪，所以你至少需要可以在手机上使用你的日历，即便不是在你所有的个人电脑上。你可以使用 Git 为自己和他人发布日历。

首先，为 .org 文件创建一个目录。我将我的存储在 ~/cal 中。

$ mkdir ~/cal

转到你的目录并使其成为 Git 存储库：

$ cd cal
$ git init

将 .org 文件移动到你本地的 Git 存储库。在实践中，我为每个类别维护一个 .org 文件。

$ mv ~/*.org ~/cal
$ ls
Game.org Meal.org Seth.org Work.org

暂存并提交你的文件：

$ git add *.org
$ git commit -m 'cal init'

创建一个 Git 远程源

要在任何地方提供日历，你必须在互联网上拥有 Git 存储库。你的日历是纯文本，因此任何 Git 存储库都可以。你可以将日历放在 GitLab 或任何其他公共 Git 托管服务（甚至是专有服务）上，只要你的主机允许，你甚至可以将该存储库标记为私有库。如果你不想将日历发布到你无法控制的服务器，则可以自行托管 Git 存储库，或者为单个用户使用裸存储库，或者使用 Gitolite 或 Gitea 等前端服务。

为了简单起见，我将假设一个自托管的 Git 裸存储库。你可以使用 Git 命令在任何具有 SSH 访问权限的服务器上创建一个远程裸存储库：

$ ssh -p 22122 [[email protected]][14]
[remote]$ mkdir cal.git
[remote]$ cd cal.git
[remote]$ git init --bare
[remote]$ exit

这个裸存储库可以作为你日历在互联网上的家。

将其设置为本地 Git 存储库（在你的计算机上，而不是你的服务器上）的远程源：

$ git remote add origin [email protected]:/home/seth/cal.git

然后推送你的日历到该服务器：

$ git push -u origin HEAD

将你的日历放在 Git 存储库中，就可以在任何运行 Git 的设备上使用它。这意味着你可以对计划进行更新和更改，并将更改推送到上游，以便在任何地方进行更新。

我使用这种方法使我的日历在我的工作笔记本电脑和家庭工作站之间保持同步。由于我每天大部分时间都在使用 Emacs，因此能够在 Emacs 中查看和编辑我的日历是一个很大的便利。对于大多数使用移动设备的人来说也是如此，因此下一步是在移动设备上设置 Org 模式的日历系统。

移动设备上的 Git

由于你的日历数据是纯文本的，严格来说，你可以在任何可以读取文本文件的设备上“使用”它。这是这个系统之美的一部分；你永远不会缺少原始数据。但是，要按照你希望的现代日历的工作方式将日历集成到移动设备上，你需要两个组件：移动设备上的 Git 客户端和 Org 模式查看器。

移动设备上的 Git 客户端

MGit 是 Android 上的优秀 Git 客户端。同样，iOS 也有 Git 客户端。

一旦安装了 MGit（或类似的 Git 客户端），你必须克隆日历存储库，以便在你的手机上有副本。要从移动设备访问服务器，必须设置 SSH 密钥进行身份验证。MGit 可以为你生成和存储密钥，你必须将其添加到服务器的 ~/.ssh/authorized_keys 文件或托管的 Git 的帐户设置中的 SSH 密钥中。

你必须手动执行此操作。MGit 没有登录你的服务器或托管的 Git 帐户的界面。如果你不这样做，你的移动设备将无法访问你的服务器以访问你的日历数据。

我是通过将我在 MGit 中生成的密钥文件通过 KDE Connect 复制到我的笔记本电脑来实现的（但你可以通过蓝牙、SD 卡读卡器或 USB 电缆进行相同操作，具体取决于你访问手机上的数据的首选方法）。 我用这个命令将密钥（一个名为 calkey 的文件）复制到我的服务器：

$ cat calkey | ssh [email protected] "cat >> /home/seth/.ssh/authorized_keys"

你可能有不同的方法，但如果你曾经将服务器设置为无密码登录，这是完全相同的过程。如果你使用的是 GitLab 等托管的 Git 服务，则必须将密钥文件的内容复制并粘贴到用户帐户的 SSH 密钥面板中。

完成后，你的移动设备可以向你的服务器授权，但仍需要知道在哪里查找你的日历数据。不同的应用程序可能使用不同的表示法，但 MGit 使用普通的旧式 Git-over-SSH。这意味着如果你使用的是非标准 SSH 端口，则必须指定要使用的 SSH 端口：

$ git clone ssh://[email protected]:22122//home/seth/git/cal.git

如果你使用其他应用程序，它可能会使用不同的语法，允许你在特殊字段中提供端口，或删除 ssh:// 前缀。如果遇到问题，请参阅应用程序文档。

将存储库克隆到手机。

很少有 Git 应用程序设置为自动更新存储库。有一些应用程序可以用来自动拉取，或者你可以设置 Git 钩子来推送服务器的更新 —— 但我不会在这里讨论这些。目前，在对日历进行更新后，请务必在 MGit 中手动提取新更改（或者如果在手机上更改了事件，请将更改推送到服务器）。

移动设备上的日历

有一些应用程序可以为移动设备上的 Org 模式提供前端。Orgzly 是一个很棒的开源 Android 应用程序，它为 Org 模式的从 Agenda 模式到 TODO 列表的大多数功能提供了一个界面。安装并启动它。

从主菜单中，选择“设置同步存储库”，然后选择包含日历文件的目录（即，从服务器克隆的 Git 存储库）。

给 Orgzly 一点时间来导入数据，然后使用 Orgzly 的汉堡包菜单选择日程视图。

在 Orgzly 的“设置提醒”菜单中，你可以选择在手机上触发通知的事件类型。你可以获得 SCHEDULED 任务，DEADLINE 任务或任何分配了事件时间的任何通知。如果你将手机用作任务管理器，那么你将永远不会错过 Org 模式和 Orgzly 的活动。

Orgzly 不仅仅是一个解析器。你可以编辑和更新事件，甚至标记事件为 DONE。

专为你而设计

关于使用 Org 模式和 Git 的重要一点是，这两个应用程序都非常灵活，并且你可以自定义它们的工作方式和内容，以便它们能够适应你的需求。如果本文中的内容是对你如何组织生活或管理每周时间表的冒犯，但你喜欢此提案提供的其他部分，那么请丢弃你不喜欢的部分。如果需要，你可以在 Emacs 中使用 Org 模式，或者你可以将其用作日历标记。你可以将手机设置为在一天结束时从计算机上拉取 Git 数据，而不是从互联网上的服务器上，或者你可以将计算机配置为在手机插入时同步日历，或者你可以每天管理它，就像你把你工作日所需的所有东西都装到你的手机上一样。这取决于你，而这是关于 Git、Org 模式和开源的最重要的事情。

via: https://opensource.com/article/19/4/calendar-git

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

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

你可以让 Git 帮助你轻松发布你的网站。在我们《鲜为人知的 Git 用法》系列的第一篇文章中学习如何做到。

Git 是一个少有的能将如此多的现代计算封装到一个程序之中的应用程序，它可以用作许多其他应用程序的计算引擎。虽然它以跟踪软件开发中的源代码更改而闻名，但它还有许多其他用途，可以让你的生活更轻松、更有条理。在这个 Git 系列中，我们将分享七种鲜为人知的使用 Git 的方法。

创建一个网站曾经是极其简单的，而同时它又是一种黑魔法。回到 Web 1.0 的旧时代（不是每个人都会这样称呼它），你可以打开任何网站，查看其源代码，并对 HTML 及其内联样式和基于表格的布局进行反向工程，在这样的一两个下午之后，你就会感觉自己像一个程序员一样。不过要让你创建的页面放到互联网上，仍然有一些问题，因为这意味着你需要处理服务器、FTP 以及 webroot 目录和文件权限。虽然从那时起，现代网站变得愈加复杂，但如果你让 Git 帮助你，自出版可以同样容易（或更容易！）。

用 Hugo 创建一个网站

Hugo 是一个开源的静态站点生成器。静态网站是过去的 Web 的基础（如果你回溯到很久以前，那就是 Web 的全部了）。静态站点有几个优点：它们相对容易编写，因为你不必编写代码；它们相对安全，因为页面上没有执行代码；并且它们可以非常快，因为除了在页面上传输的任何内容之外没有任何处理。

Hugo 并不是唯一一个静态站点生成器。Grav、Pico、Jekyll、Podwrite 以及许多其他的同类软件都提供了一种创建一个功能最少的、只需要很少维护的网站的简单方法。Hugo 恰好是内置集成了 GitLab 集成的一个静态站点生成器，这意味着你可以使用免费的 GitLab 帐户生成和托管你的网站。

Hugo 也有一些非常大的用户。例如，如果你曾经去过 Let’s Encrypt 网站，那么你已经用过了一个用 Hugo 构建的网站。

安装 Hugo

Hugo 是跨平台的，你可以在 Hugo 的入门资源中找到适用于 MacOS、Windows、Linux、OpenBSD 和 FreeBSD 的安装说明。

如果你使用的是 Linux 或 BSD，最简单的方法是从软件存储库或 ports 树安装 Hugo。确切的命令取决于你的发行版，但在 Fedora 上，你应该输入：

$ sudo dnf install hugo

通过打开终端并键入以下内容确认你已正确安装：

$ hugo help

这将打印 hugo 命令的所有可用选项。如果你没有看到，你可能没有正确安装 Hugo 或需要将该命令添加到你的路径。

创建你的站点

要构建 Hugo 站点，你必须有个特定的目录结构，通过输入以下命令 Hugo 将为你生成它：

$ hugo new site mysite

你现在有了一个名为 mysite 的目录，它包含构建 Hugo 网站所需的默认目录。

Git 是你将网站放到互联网上的接口，因此切换到你新的 mysite 文件夹，并将其初始化为 Git 存储库：

$ cd mysite
$ git init .

Hugo 与 Git 配合的很好，所以你甚至可以使用 Git 为你的网站安装主题。除非你计划开发你正在安装的主题，否则可以使用 --depth 选项克隆该主题的源的最新状态：

$ git clone --depth 1 https://github.com/darshanbaral/mero.git themes/mero

现在为你的网站创建一些内容：

$ hugo new posts/hello.md

使用你喜欢的文本编辑器编辑 content/posts 目录中的 hello.md 文件。Hugo 接受 Markdown 文件，并会在发布时将它们转换为经过主题化的 HTML 文件，因此你的内容必须采用 Markdown 格式。

如果要在帖子中包含图像，请在 static 目录中创建一个名为 images 的文件夹。将图像放入此文件夹，并使用以 /images 开头的绝对路径在标记中引用它们。例如：

![A picture of a thing](/images/thing.jpeg)

选择主题

你可以在 themes.gohugo.io 找到更多主题，但最好在测试时保持一个基本主题。标准的 Hugo 测试主题是 Ananke。某些主题具有复杂的依赖关系，而另外一些主题如果没有复杂的配置的话，也许不会以你预期的方式呈现页面。本例中使用的 Mero 主题捆绑了一个详细的 config.toml 配置文件，但是（为了简单起见）我将在这里只提供基本的配置。在文本编辑器中打开名为 config.toml 的文件，并添加三个配置参数：

languageCode = "en-us"
title = "My website on the web"
theme = "mero"

[params]
  author = "Seth Kenlon"
  description = "My hugo demo"

预览

在你准备发布之前不必（预先）在互联网上放置任何内容。在你开发网站时，你可以通过启动 Hugo 附带的仅限本地访问的 Web 服务器来预览你的站点。

$ hugo server --buildDrafts --disableFastRender

打开 Web 浏览器并导航到 http://localhost:1313 以查看正在进行的工作。

用 Git 发布到 GitLab

要在 GitLab 上发布和托管你的站点，请为你的站点内容创建一个存储库。

要在 GitLab 中创建存储库，请单击 GitLab 的 “Projects” 页面中的 “New Project” 按钮。创建一个名为 yourGitLabUsername.gitlab.io 的空存储库，用你的 GitLab 用户名或组名替换 yourGitLabUsername。你必须使用此命名方式作为该项目的名称。你也可以稍后为其添加自定义域。

不要在 GitLab 上包含许可证或 README 文件（因为你已经在本地启动了一个项目，现在添加这些文件会使将你的数据推向 GitLab 时更加复杂，以后你可以随时添加它们）。

在 GitLab 上创建空存储库后，将其添加为 Hugo 站点的本地副本的远程位置，该站点已经是一个 Git 存储库：

$ git remote add origin [email protected]:skenlon/mysite.git

创建名为 .gitlab-ci.yml 的 GitLab 站点配置文件并输入以下选项：

image: monachus/hugo

variables:
  GIT_SUBMODULE_STRATEGY: recursive

pages:
  script:
  - hugo
  artifacts:
    paths:
    - public
  only:
  - master

image 参数定义了一个为你的站点提供服务的容器化图像。其他参数是告诉 GitLab 服务器在将新代码推送到远程存储库时要执行的操作的说明。有关 GitLab 的 CI/CD（持续集成和交付）选项的更多信息，请参阅 GitLab 文档的 CI/CD 部分。

设置排除的内容

你的 Git 存储库已配置好，在 GitLab 服务器上构建站点的命令也已设置，你的站点已准备好发布了。对于你的第一个 Git 提交，你必须采取一些额外的预防措施，以便你不会对你不打算进行版本控制的文件进行版本控制。

首先，将构建你的站点时 Hugo 创建的 /public 目录添加到 .gitignore 文件。你无需在 Git 中管理已完成发布的站点；你需要跟踪的是你的 Hugo 源文件。

$ echo "/public" >> .gitignore

如果不创建 Git 子模块，则无法在 Git 存储库中维护另一个 Git 存储库。为了简单起见，请移除嵌入的存储库的 .git 目录，以使主题（存储库）只是一个主题（目录）。

请注意，你必须将你的主题文件添加到你的 Git 存储库，以便 GitLab 可以访问该主题。如果不提交主题文件，你的网站将无法成功构建。

$ mv themes/mero/.git ~/.local/share/Trash/files/

你也可以像使用回收站一样使用 trash：

$ trash themes/mero/.git

现在，你可以将本地项目目录的所有内容添加到 Git 并将其推送到 GitLab：

$ git add .
$ git commit -m 'hugo init'
$ git push -u origin HEAD

用 GitLab 上线

将代码推送到 GitLab 后，请查看你的项目页面。有个图标表示 GitLab 正在处理你的构建。第一次推送代码可能需要几分钟，所以请耐心等待。但是，请不要一直等待，因为该图标并不总是可靠地更新。

当你在等待 GitLab 组装你的站点时，请转到你的项目设置并找到 “Pages” 面板。你的网站准备就绪后，它的 URL 就可以用了。该 URL 是 yourGitLabUsername.gitlab.io/yourProjectName。导航到该地址以查看你的劳动成果。

如果你的站点无法正确组装，GitLab 提供了可以深入了解 CI/CD 管道的日志。查看错误消息以找出发生了什么问题。

Git 和 Web

Hugo（或 Jekyll 等类似工具）只是利用 Git 作为 Web 发布工具的一种方式。使用服务器端 Git 挂钩，你可以使用最少的脚本设计你自己的 Git-to-web 工作流。使用 GitLab 的社区版，你可以自行托管你自己的 GitLab 实例；或者你可以使用 Gitolite 或 Gitea 等替代方案，并使用本文作为自定义解决方案的灵感来源。祝你玩得开心！

via: https://opensource.com/article/19/4/building-hosting-website-git

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

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

Tig 可不仅仅是 Git 的文本界面。以下是它如何增强你的日常工作流程。

如果你使用 Git 作为你的版本控制系统，你可能已经让自己接受了 Git 是一个复杂的野兽的事实。它是一个很棒的工具，但浏览 Git 仓库可能很麻烦。因此像 Tig 这样的工具出现了。

来自 Tig 手册页：

Tig 是 git(1) 的基于 ncurses 的文本界面。它主要用作 Git 仓库浏览器，但也有助于在块级别暂存提交更改，并作为各种 Git 命令的输出分页器。

这基本上意味着 Tig 提供了一个可以在终端中运行的基于文本的用户界面。Tig 可以让你轻松浏览你的 Git 日志，但它可以做的远不止让你从最后的提交跳到前一个提交。

这篇快速入门的 Tig 中的许多例子都是直接从其出色的手册页中拿出来的。我强烈建议你阅读它以了解更多信息。

安装 Tig

• Fedora 和 RHEL： sudo dnf install tig
• Ubuntu 和 Debian： sudo apt install tig
• MacOS： ：brew install tig

有关更多方式，请参阅官方安装说明。

浏览当前分支中的提交

如果要浏览分支中的最新提交，请输入：

tig

就是这样。这个三字符命令将启动一个浏览器，你可以在其中浏览当前分支中的提交。你可以将其视为 git log 的封装器。

要浏览这些输出，可以使用向上和向下箭头键从一个提交移动到另一个提交。按回车键将会垂直分割窗口，右侧包含所选提交的内容。你可以继续在左侧的提交历史记录中上下浏览，你的更改将显示在右侧。使用 k 和 j 可以逐行上下浏览，- 和空格键可以在右侧上下翻页。使用 q 退出右侧窗格。

搜索 tig 输出也很简单。使用 / （向前）或 ? （向后）在左右窗格中搜索。

这些就足以让你浏览你的提交信息了。这里有很多的键绑定，但单击 h 将显示“帮助”菜单，你可以在其中发现其导航和命令选项。你还可以使用 / 和 ? 来搜索“帮助”菜单。使用 q 退出帮助。

浏览单个文件的修改

由于 Tig 是 git log 的封装器，它可以方便地接受可以传递给 git log 的相同参数。例如，要浏览单个文件的提交历史记录，请输入：

tig README.md

将其与被封装的 Git 命令的输出进行比较，以便更清楚地了解 Tig 如何增强输出。

git log README.md

要在原始 Git 输出中包含补丁，你可以添加 -p 选项：

git log -p README.md

如果要将提交范围缩小到特定日期范围，请尝试以下操作：

tig --after="2017-01-01" --before="2018-05-16" -- README.md

再一次，你可以将其与原始的 Git 版本进行比较：

git log --after="2017-01-01" --before="2018-05-16" -- README.md

浏览谁更改了文件

有时你想知道谁对文件进行了更改以及原因。命令：

tig blame README.md

器本质上是 git blame 的封装。正如你所期望的那样，它允许你查看谁是编辑指定行的最后一人，它还允许你查看到引入该行的提交。这有点像 vim 的 vim-fugitive 插件提供的 :Gblame 命令。

浏览你的暂存区

如果你像我一样，你可能会在你的暂存区做了许多修改。你很容易忘记它们。你可以通过以下方式查看暂存处中的最新项目：

git stash show -p stash@{0}

你可以通过以下方式找到第二个最新项目：

git stash show -p stash@{1}

以此类推。如果你在需要它们时调用这些命令，那么你会有比我更清晰的记忆。

与上面的 Git 命令一样，Tig 可以通过简单的调用轻松增强你的 Git 输出：

tig stash

尝试在有暂存的仓库中执行此命令。你将能够浏览并搜索你的暂存项，快速浏览你的那些修改。

浏览你的引用

Git ref 是指你提交的东西的哈希值。这包括文件和分支。使用 tig refs 命令可以浏览所有的 ref 并深入查看特定提交。

tig refs

完成后，使用 q 回到前面的菜单。

浏览 git 状态

如果要查看哪些文件已被暂存，哪些文件未被跟踪，请使用 tig status，它是 git status 的封装。

浏览 git grep

你可以使用 grep 命令在文本文件中搜索表达式。命令 tig grep 允许你浏览 git grep 的输出。例如：

tig grep -i foo lib/Bar

它会让你浏览 lib/Bar 目录中以大小写敏感的方式搜索 foo 的输出。

通过标准输入管道输出给 Tig

如果要将提交 ID 列表传递给 Tig，那么必须使用 --stdin 标志，以便 tig show 从标准输入读取。否则，tig show 会在没有输入的情况下启动（出现空白屏幕）。

git rev-list --author=olaf HEAD | tig show --stdin

添加自定义绑定

你可以使用 rc 文件自定义 Tig。以下是如何根据自己的喜好添加一些有用的自定义键绑定的示例。

在主目录中创建一个名为 .tigrc 的文件。在你喜欢的编辑器中打开 ~/.tigrc 并添加：

# 应用选定的暂存内容
bind stash a !?git stash apply %(stash)

# 丢弃选定的暂存内容
bind stash x !?git stash drop %(stash)

如上所述，运行 tig stash 以浏览你的暂存。但是，通过这些绑定，你可以按 a 将暂存中的项目应用到仓库，并按 x 从暂存中删除项目。请记住，你要在浏览暂存列表时，才能执行这些命令。如果你正在浏览暂存项，请输入 q 退出该视图，然后按 a 或 x 以获得所需效果。

有关更多信息，你可以阅读有关 Tig 键绑定。

总结

我希望这有助于演示 Tig 如何增强你的日常工作流程。Tig 可以做更强大的事情（比如暂存代码行），但这超出了这篇介绍性文章的范围。这里有足够的让你置身于危险的信息，但还有更多值得探索的地方。

via: https://opensource.com/article/19/6/what-tig

作者：Olaf Alders 选题：lujun9972 译者：geekpi 校对：wxy

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

Git 为软件开发所带来的巨大影响是其它工具难以企及的。

在 Linus Torvalds 开发 Git 后的十四年间，它为软件开发所带来的影响是其它工具难以企及的：在 StackOverflow 的 2018 年开发者调查 中，87% 的受访者都表示他们使用 Git 来作为他们项目的版本控制工具。显然，没有其它工具能撼动 Git 版本控制管理工具（SCM）之王的地位。

为了在 4 月 7 日 Git 的十四周年这一天向 Git 表示敬意，我问了一些爱好者他们最喜欢 Git 的哪一点。以下便是他们所告诉我的：

（为了便于理解，部分回答已经进行了小幅修改）

“我无法忍受 Git。无论是难以理解的术语还是它的分布式。使用 Gerrit 这样的插件才能使它像 Subversion 或 Perforce 这样的集中式仓库管理器使用的工具的一半好用。不过既然这次的问题是‘你喜欢 Git 的什么？’，我还是希望回答：Git 使得对复杂的源代码树操作成为可能，并且它的回滚功能使得实现一个要 20 次修改才能更正的问题变得简单起来。”

— Sweet Tea Dorminy

“我喜欢 Git 是因为它不会强制我执行特定的工作流程，并且开发团队可以自由地以适合自己的方式来进行团队开发，无论是拉取请求、以电子邮件递送差异文件或是给予所有人推送的权限。”

— Andy Price

“我从 2006、2007 年的样子就开始使用 Git 了。我喜欢 Git 是因为，它既适用于那种从未离开过我电脑的小项目，也适用于大型的团队合作的分布式项目。Git 使你可以从（几乎）所有的错误提交中回滚到先前版本，这个功能显著地减轻了我在软件版本管理方面的压力。”

— Jonathan S. Katz

“我很欣赏 Git 那种 底层命令和高层命令 的理念。用户可以使用 Git 有效率地分享任何形式的信息，而不需要知道其内部工作原理。而好奇的人可以透过其表层的命令，而发现其为许多代码分享平台提供了支持的可以定位内容的文件系统。”

— Matthew Broberg

“我喜欢 Git 是因为浏览、开发、构建、测试和向我的 Git 仓库中提交代码的工作几乎都能用它来完成。它经常会调动起我参与开源项目的积极性。”

— Daniel Oh

“Git 是我用过的首个版本控制工具。数年间，它从一个可怕的工具变成了一个友好的工具。我喜欢它使你在修改代码的时候更加自信，因为它能保证你主分支的安全（除非你强制提交了一段考虑不周的代码到主分支）。你可以检出先前的提交来撤销更改，这一点也是很棒的。”

— Kedar Vijay Kulkarni

“我之所以喜欢 Git 是因为它淘汰了一些其它的版本控制工具。没人使用 VSS，而 Subversion 可以和 git-svn 一起使用（如果必要），BitKeeper 则和 Monotone 一样只为老一辈所知。当然，我们还有 Mercurial，不过在我几年之前用它来为 Firefox 添加 AArch64 支持时，我觉得它仍是那种还未完善的工具。部分人可能还会提到 Perforce、SourceSafe 或是其它企业级的解决方案，我只想说它们在开源世界里并不流行。”

— Marcin Juszkiewicz

“我喜欢内置的 SHA1 化对象模型（commit → tree → blob）的简易性。我也喜欢它的高层命令。同时我也将它作为对 JBoss/Red Hat Fuse 的补丁机制。并且这种机制确实有效。我还喜欢 Git 的 三棵树的故事。”

— Grzegorz Grzybek

“我喜欢 自动生成的 Git 说明页（这个页面虽然听起来是有关 Git 的，但是事实上这是一个没有实际意义的页面，不过它总是会给人一种像是真的 Git 页面的感觉…），这使得我对 Git 的敬意油然而生。”

— Marko Myllynen

“Git 改变了我作为开发者的生活。它使得 SCM 问题从世界上消失得无影无踪。”

— Joel Takvorian

看完这十个爱好者的回答之后，就轮到你了：你最欣赏 Git 的什么？请在评论区分享你的看法！

via: https://opensource.com/article/19/4/what-do-you-love-about-git

作者：Jen Wike Huger 选题：lujun9972 译者：zhs852 校对：wxy

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