标签 Git 下的文章

使用 Emoji-Log 为你的提交添加上下文。

我是一名全职的开源开发人员，我喜欢称自己为“开源者”。我从事开源软件工作已经超过十年，并构建了数以百计的开源软件应用程序。

同时我也是“ 避免重复工作 Don’t Repeat Yourself ”（DRY）哲学的忠实粉丝，并且我相信编写更好的 Git 提交消息是 DRY 的一个重要组成部分。它们具有足够的上下文关联，可以作为你开源软件的变更日志。我编写的众多工作流之一是 Emoji-Log，它是一个简单易用的开源 Git 提交日志标准。它通过使用表情符号来创建更好的 Git 提交消息，从而改善了开发人员的体验（DX）。

我使用 Emoji-Log 构建了 VSCode Tips & Tricks 仓库 和我的 ? 紫色 VSCode 主题仓库，以及一个看起来很漂亮的自动变更日志。

Emoji-Log 的哲学

我喜欢（很多）表情符号，我很喜欢它们。编程、代码、极客/书呆子、开源……所有这一切本质上都很枯燥，有时甚至很无聊。表情符号帮助我添加颜色和情感。想要将感受添加到这个 2D 的、平板的、基于文本的代码世界并没有错。

相比于数百个表情符号，我学会的更好办法是让类别较小和普遍性。以下是指导使用 Emoji-Log 编写提交信息的原则：

  • 必要的

    • Git 提交信息是必要的。

    • 像下订单一样编写提交信息。

      • 例如，使用 ✅ Add 而不是 ❌ Added
      • 例如，使用 ✅ Create 而不是 ❌ Creating

  • 规则

    • 少数类别易于记忆。

    • 不多也不少

      • 例如 ? NEW 、 ? IMPROVE 、 ? FIX 、 ? DOC 、 ? RELEASE 、 ✅ TEST

  • 行为

    • 让 Git 的提交基于你所采取的操作
    • 使用像 VSCode 这样的编辑器来提交带有提交信息的正确文件。

编写提交信息

仅使用以下 Git 提交信息。简单而小巧的占地面积是 Emoji-Log 的核心。

  • ? NEW: 必要的信息

    • 当你添加一些全新的东西时使用。

      • 例如 ? NEW: 添加 Git 忽略的文件

  • ? IMPROVE: 必要的信息

    • 用于改进/增强代码段，如重构等。

      • 例如 ? IMPROVE: 远程 IP API 函数

  • ? FIX: 必要的信息

    • 修复 bug 时使用，不用解释了吧？

      • 例如 ? FIX: Case converter

  • ? DOC: 必要的信息

    • 添加文档时使用，比如 README.md 甚至是内联文档。

      • 例如 ? DOC: API 接口教程

  • ? RELEASE: 必要的信息

    • 发布新版本时使用。例如， ? RELEASE: Version 2.0.0

  • ✅ TEST: 必要的信息

    • 发布新版本时使用。

      • 例如 ✅ TEST: 模拟用户登录/注销

就这些了，不多不少。

Emoji-Log 函数

为了快速构建原型，我写了以下函数，你可以将它们添加到 .bashrc 或者 .zshrc 文件中以快速使用 Emoji-Log。

#.# Better Git Logs.

### Using EMOJI-LOG (https://github.com/ahmadawais/Emoji-Log).

# Git Commit, Add all and Push — in one step.

function gcap() {
    git add . && git commit -m "$*" && git push
}

# NEW.
function gnew() {
    gcap "? NEW: $@"
}

# IMPROVE.
function gimp() {
    gcap "? IMPROVE: $@"
}

# FIX.
function gfix() {
    gcap "? FIX: $@"
}

# RELEASE.
function grlz() {
    gcap "? RELEASE: $@"
}

# DOC.
function gdoc() {
    gcap "? DOC: $@"
}

# TEST.
function gtst() {
    gcap "✅ TEST: $@"
}

要为 fish shell 安装这些函数，运行以下命令：

function gcap; git add .; and git commit -m "$argv"; and git push; end;
function gnew; gcap "? NEW: $argv"; end
function gimp; gcap "? IMPROVE: $argv"; end;
function gfix; gcap "? FIX: $argv"; end;
function grlz; gcap "? RELEASE: $argv"; end;
function gdoc; gcap "? DOC: $argv"; end;
function gtst; gcap "✅ TEST: $argv"; end;
funcsave gcap
funcsave gnew
funcsave gimp
funcsave gfix
funcsave grlz
funcsave gdoc
funcsave gtst

如果你愿意，可以将这些别名直接粘贴到 ~/.gitconfig 文件：

# Git Commit, Add all and Push — in one step.
cap = "!f() { git add .; git commit -m \"$@\"; git push; }; f"

# NEW.
new = "!f() { git cap \"? NEW: $@\"; }; f"
# IMPROVE.
imp = "!f() { git cap \"? IMPROVE: $@\"; }; f"
# FIX.
fix = "!f() { git cap \"? FIX: $@\"; }; f"
# RELEASE.
rlz = "!f() { git cap \"? RELEASE: $@\"; }; f"
# DOC.
doc = "!f() { git cap \"? DOC: $@\"; }; f"
# TEST.
tst = "!f() { git cap \"✅ TEST: $@\"; }; f"

Emoji-Log 例子

这里列出了一些使用 Emoji-Log 的仓库：

你呢？如果你的仓库使用 Emoji-Log，请将这个 Emoji-Log 徽章放到你的 README 中，并给我发送一个拉取请求，以让我可以将你的仓库列在这里。

via: https://opensource.com/article/19/2/emoji-log-git-commit-messages

作者：Ahmad Awais 选题：lujun9972 译者：MjSeven 校对：wxy

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

Emacs 的 Magit 扩展插件使得使用 Git 进行版本控制变得简单起来。

Git 是一个很棒的用于项目管理的 版本控制 工具，就是新人学习起来太难。Git 的命令行工具很难用，你不仅需要熟悉它的标志和选项，还需要知道什么环境下使用它们。这使人望而生畏，因此不少人只会非常有限的几个用法。

好在，现今大多数的集成开发环境 (IDE) 都包含了 Git 扩展，大大地简化了使用使用的难度。Emacs 中就有这么一款 Git 扩展名叫 Magit。

Magit 项目成立有差不多 10 年了，它将自己定义为 “一件 Emacs 内的 Git 瓷器”。也就是说，它是一个操作界面，每个操作都能一键完成。本文会带你领略一下 Magit 的操作界面并告诉你如何使用它来管理 Git 项目。

若你还没有做，请在开始本教程之前先 安装 Emacs，再 安装 Magit。

Magit 的界面

首先用 Emacs 的 Dired 模式 访问一个项目的目录。比如我所有的 Emacs 配置存储在 ~/.emacs.d/ 目录中，就是用 Git 来进行管理的。

若你在命令行下工作，则你需要输入 git status 来查看项目的当前状态。Magit 也有类似的功能：magit-status。你可以通过 M-x magit-status （快捷方式是 Alt+x magit-status ）来调用该功能。结果看起来像下面这样：

Magit 显示的信息比 git status 命令的要多得多。它分别列出了未追踪文件列表、未暂存文件列表以及已暂存文件列表。它还列出了 储藏 stash 列表以及最近几次的提交 —— 所有这些信息都在一个窗口中展示。

如果你想查看修改了哪些内容，按下 Tab 键。比如，我移动光标到未暂存的文件 custom_functions.org 上，然后按下 Tab 键，Magit 会显示修改了哪些内容：

这跟运行命令 git diff custom_functions.org 类似。储藏文件更简单。只需要移动光标到文件上然后按下 s 键。该文件就会迅速移动到已储藏文件列表中：

要 反储藏 unstage 某个文件，使用 u 键。按下 s 和 u 键要比在命令行输入 git add -u <file> 和 git reset HEAD <file> 快的多也更有趣的多。

提交更改

在同一个 Magit 窗口中，按下 c 键会显示一个提交窗口，其中提供了许多标志，比如 --all 用来暂存所有文件或者 --signoff 来往提交信息中添加签名行。

将光标移动到想要启用签名标志的行，然后按下回车。--signoff 文本会变成高亮，这说明该标志已经被启用。

再次按下 c 键会显示一个窗口供你输入提交信息。

最后，使用 C-c C-c(按键 Ctrl+cc 的缩写形式) 来提交更改。

推送更改

更改提交后，提交行将会显示在 Recent commits 区域中显示。

将光标放到该提交处然后按下 p 来推送该变更。

若你想感受一下使用 Magit 的感觉，我已经在 YouTube 上传了一段 演示。本文只涉及到 Magit 的一点皮毛。它有许多超酷的功能可以帮你使用 Git 分支、变基等功能。你可以在 Magit 的主页上找到 文档、支持，以及更多 的链接。

via: https://opensource.com/article/19/1/how-use-magit

作者：Sachin Patil 选题：lujun9972 译者：lujun9972 校对：wxy

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

要是你的 Git 有了人工智能，会不会嫌弃你的提交？

当你想修复一个游戏防沉迷的时间验证 bug 时，却被 Git 鄙视了——你确认你的老板还需要你吗，而不是一个 Git？

就算是你恼羞成怒想要删除 Git 怕是也会被智能的 Yum 拒绝吧——它们肯定是一伙的。

via: http://turnoff.us/geek/when-ai-meets-git/

作者：Daniel Stori 译者 & 点评：wxy 校对 & 合成：wxy

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

我们继续我们的 PGP 实践系列，来看看签名标签的标签和提交，这可以帮你确保你的仓库没有被篡改。

在本系列教程中，我们提供了一个使用 PGP 的实用指南，包括基本概念和工具、生成和保护你的密钥。如果你错过了前面的文章，你可以查看下面的链接。在这篇文章中，我们谈一谈在 Git 中如何集成 PGP、使用签名的标签，然后介绍签名提交，最后添加签名推送的支持。

Git 的核心特性之一就是它的去中心化本质 —— 一旦仓库克隆到你的本地系统，你就拥有了项目的完整历史，包括所有的标签、提交和分支。然而由于存在着成百上千的克隆仓库，如何才能验证你下载的仓库没有被恶意的第三方做过篡改？你可以从 GitHub 或一些貌似官方的位置来克隆它们，但是如果有些人故意欺骗了你怎么办？

或者在你参与的一些项目上发现了后门，而 “Author” 行显示是你干的，然而你很确定 不是你干的，会发生什么情况？

为解决上述问题，Git 添加了 PGP 集成。签名的标签通过确认它的内容与创建这个标签的开发者的工作站上的内容完全一致来证明仓库的完整性，而签名的提交几乎是不可能在不访问你的 PGP 密钥的情况下能够假冒你。

清单

  • 了解签名的标签、提交和推送（必要）
  • 配置 git 使用你的密钥（必要）
  • 学习标签如何签名和验证（必要）
  • 配置 git 总是签名带注释标签（推荐）
  • 学习提交如何签名和验证工作（必要）
  • 配置 git 总是签名提交（推荐）
  • 配置 gpg-agent 选项（必要）

考虑事项

git 实现了 PGP 的多级集成，首先从签名标签开始，接着介绍签名提交，最后添加签名推送的支持。

了解 Git 哈希

git 是一个复杂的东西，为了你能够更好地掌握它如何集成 PGP，你需要了解什么是”哈希“。我们将它归纳为两种类型的哈希：树哈希和提交哈希。

树哈希

每次你向仓库提交一个变更，对于仓库中的每个子目录，git 都会记录它里面所有对象的校验和哈希 —— 内容（blobs）、目录（trees）、文件名和许可等等。它只对每次提交中发生变更的树和内容做此操作，这样在只变更树的一小部分时就不必去重新计算整个树的校验和。

然后再计算和存储处于顶级的树的校验和，这样如果仓库的任何一部分发生变化，校验和将不可避免地发生变化。

提交哈希

一旦创建了树哈希，git 将计算提交哈希，它将包含有关仓库和变更的下列信息：

  • 树哈希的校验和
  • 变更前树哈希的校验和（父级）
  • 有关作者的信息（名字、email、创作时间）
  • 有关提交者的信息（名字、email、提交时间）
  • 提交信息
哈希函数

在写这篇文章时，虽然研究一种更强大的、抗碰撞的算法的工作正在进行，但 git 仍然使用的是 SHA1 哈希机制去计算校验和。注意，git 已经包含了碰撞防范程序，因此认为对 git 成功进行碰撞攻击仍然是不可行的。

带注释标签和标签签名

在每个 Git 仓库中，标签允许开发者标记特定的提交。标签可以是 “轻量级的” —— 几乎只是一个特定提交上的指针，或者它们可以是 “带注释的”，它自己将成为 git 树中的项目。一个带注释标签对象包含所有下列的信息：

  • 成为标签的提交的哈希的校验和
  • 标签名字
  • 关于打标签的人的信息（名字、email、打标签时间）
  • 标签信息

一个 PGP 签名的标签是一个带有将所有这些条目封装进一个 PGP 签名的带注释标签。当开发者签名他们的 git 标签时，他们实际上是向你保证了如下的信息：

  • 他们是谁（以及他们为什么应该被信任）

  • 他们在签名时的仓库状态是什么样：

    • 标签包含的提交的哈希

      • 提交的哈希包含了顶级树的哈希
      • 顶级树哈希包含了所有文件、内容和子树的哈希
      • 它也包含有关作者的所有信息
      • 包含变更发生时的精确时间

当你克隆一个仓库并验证一个签名的标签时，就是向你以密码方式保证：仓库中的所有内容、包括所有它的历史，与开发者签名时在它的计算机上的仓库完全一致。

签名的提交

签名的提交与签名的标签非常类似 —— PGP 签名的是提交对象的内容，而不是标签对象的内容。一个提交签名也给你提供了开发者签名时开发者树上的全部可验证信息。标签签名和提交的 PGP 签名提供了有关仓库和它的完整历史的完全一致的安全保证。

签名的推送

为了完整起见，在这里包含了签名的推送这一功能，因为在你使用这个功能之前，需要在接收推送的服务器上先启用它。正如我们在上面所说过的，PGP 签名一个 git 对象就是提供了开发者的 git 树当时的可验证信息，但不提供开发者对那个树意图相关的信息。

比如，你可以在你自己复刻的 git 仓库的一个实验分支上尝试一个很酷的特性，为了评估它，你提交了你的工作，但是有人在你的代码中发现了一个恶意的 bug。由于你的提交是经过正确签名的，因此有人可能将包含有恶意 bug 的分支推入到 master 分支中，从而在生产系统中引入一个漏洞。由于提交是经过你的密钥正确签名的，所以一切看起来都是合理合法的，而当 bug 被发现时，你的声誉就会因此而受到影响。

在 git push 时，为了验证提交的意图而不仅仅是验证它的内容，添加了要求 PGP 推送签名的功能。

配置 git 使用你的 PGP 密钥

如果在你的钥匙环上只有一个密钥，那么你就不需要再做额外的事了，因为它是你的默认密钥。

然而，如果你有多个密钥，那么你必须要告诉 git 去使用哪一个密钥。（[fpr] 是你的密钥的指纹）：

$ git config --global user.signingKey [fpr]

注意：如果你有一个不同的 gpg2 命令，那么你应该告诉 git 总是去使用它，而不是传统的版本 1 的 gpg：

$ git config --global gpg.program gpg2

如何使用签名标签

创建一个签名的标签，只要传递一个简单地 -s 开关给 tag 命令即可：

$ git tag -s [tagname]

我们建议始终对 git 标签签名，这样让其它的开发者确信他们使用的 git 仓库没有被恶意地修改过（比如，引入后门）：

如何验证签名的标签

验证一个签名的标签，只需要简单地使用 verify-tag 命令即可：

$ git verify-tag [tagname]

如果你要验证其他人的 git 标签，那么就需要你导入他的 PGP 公钥。请参考 “可信任的团队沟通” 一文中关于此主题的指导。

在拉取时验证

如果你从项目仓库的其它复刻中拉取一个标签，git 将自动验证签名，并在合并操作时显示结果：

$ git pull [url] tags/sometag

合并信息将包含类似下面的内容：

Merge tag 'sometag' of [url]

[Tag message]

# gpg: Signature made [...]
# gpg: Good signature from [...]

配置 git 始终签名带注释标签

很可能的是，你正在创建一个带注释标签，你应该去签名它。强制 git 始终签名带注释的标签，你可以设置一个全局配置选项：

$ git config --global tag.forceSignAnnotated true

或者，你始终记得每次都传递一个 -s 开关：

$ git tag -asm "Tag message" tagname

如何使用签名的提交

创建一个签名的提交很容易，但是将它纳入到你的工作流中却很困难。许多项目使用签名的提交作为一种 “Committed-by:” 的等价行，它记录了代码来源 —— 除了跟踪项目历史外，签名很少有人去验证。在某种意义上，签名的提交用于 “篡改证据”，而不是 git 工作流的 “篡改证明”。

为创建一个签名的提交，你只需要 git commit 命令传递一个 -S 标志即可（由于它与另一个标志冲突，所以改为大写的 -S）：

$ git commit -S

我们建议始终使用签名提交，并要求项目所有成员都这样做，这样其它人就可以验证它们（下面就讲到如何验证）。

如何去验证签名的提交

验证签名的提交需要使用 verify-commit 命令：

$ git verify-commit [hash]

你也可以查看仓库日志，要求所有提交签名是被验证和显示的：

$ git log --pretty=short --show-signature
在 git 合并时验证提交

如果项目的所有成员都签名了他们的提交，你可以在合并时强制进行签名检查（然后使用 -S 标志对合并操作本身进行签名）：

$ git merge --verify-signatures -S merged-branch

注意，如果有一个提交没有签名或验证失败，将导致合并操作失败。通常情况下，技术是最容易的部分 —— 而人的因素使得项目中很难采用严格的提交验证。

如果你的项目在补丁管理上采用邮件列表

如果你的项目在提交和处理补丁时使用一个邮件列表，那么一般很少使用签名提交，因为通过那种方式发送时，签名信息将会丢失。对提交进行签名仍然是非常有用的，这样其他人就能引用你托管在公开 git 树作为参考，但是上游项目接收你的补丁时，仍然不能直接使用 git 去验证它们。

尽管，你仍然可以签名包含补丁的电子邮件。

配置 git 始终签名提交

你可以告诉 git 总是签名提交：

git config --global commit.gpgSign true

或者你每次都记得给 git commit 操作传递一个 -S 标志（包括 —amend）。

配置 gpg-agent 选项

GnuPG agent 是一个守护工具，它能在你使用 gpg 命令时随时自动启动，并运行在后台来缓存私钥的密码。这种方式让你只需要解锁一次密钥就可以重复地使用它（如果你需要在一个自动脚本中签署一组 git 操作，而不想重复输入密钥，这种方式就很方便）。

为了调整缓存中的密钥过期时间，你应该知道这两个选项：

  • default-cache-ttl（秒）：如果在 TTL 过期之前再次使用同一个密钥，这个倒计时将重置成另一个倒计时周期。缺省值是 600（10 分钟）。
  • max-cache-ttl（秒）：自首次密钥输入以后，不论最近一次使用密钥是什么时间，只要最大值的 TTL 倒计时过期，你将被要求再次输入密码。它的缺省值是 30 分钟。

如果你认为这些缺省值过短（或过长），你可以编辑 ~/.gnupg/gpg-agent.conf 文件去设置你自己的值：

# set to 30 minutes for regular ttl, and 2 hours for max ttl
default-cache-ttl 1800
max-cache-ttl 7200
补充：与 ssh 一起使用 gpg-agent

如果你创建了一个 A（验证）密钥，并将它移到了智能卡，你可以将它用到 ssh 上，为你的 ssh 会话添加一个双因子验证。为了与 agent 沟通你只需要告诉你的环境去使用正确的套接字文件即可。

首先，添加下列行到你的 ~/.gnupg/gpg-agent.conf 文件中：

enable-ssh-support

接着，添加下列行到你的 .bashrc 文件中：

export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)

为了让改变生效，你需要杀掉正在运行的 gpg-agent 进程，并重新启动一个新的登入会话：

$ killall gpg-agent
$ bash
$ ssh-add -L

最后的命令将列出代表你的 PGP Auth 密钥的 SSH（注释应该会在结束的位置显示： cardno:XXXXXXXX，表示它来自智能卡）。

为了启用 ssh 的基于密钥的登入，只需要在你要登入的远程系统上添加 ssh-add -L 的输出到 ~/.ssh/authorized_keys 中。祝贺你，这将使你的 SSH 登入凭据更难以窃取。

此外，你可以从公共密钥服务器上下载其它人的基于 PGP 的 ssh 公钥，这样就可以赋予他登入 ssh 的权利：

$ gpg --export-ssh-key [keyid]

如果你有让开发人员通过 ssh 来访问 git 仓库的需要，这将让你非常方便。下一篇文章，我们将提供像保护你的密钥那样保护电子邮件帐户的小技巧。

via: https://www.linux.com/blog/learn/pgp/2018/3/protecting-code-integrity-pgp-part-6-using-pgp-git

作者：KONSTANTIN RYABITSEV 译者：qhwdw 校对：wxy

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

GitHub 网站发布于 2008 年。如果你的软件工程师职业生涯跟我一样，也是晚于此时间的话，Git 可能是你用过的唯一版本控制软件。虽然其陡峭的学习曲线和不直观地用户界面时常会遭人抱怨，但不可否认的是，Git 已经成为学习版本控制的每个人的选择。Stack Overflow 2015 年进行的开发者调查显示，69.3% 的被调查者在使用 Git，几乎是排名第二的 Subversion 版本控制系统使用者数量的两倍。 1 2015 年之后，也许是因为 Git 太受欢迎了，大家对此话题不再感兴趣，所以 Stack Overflow 停止了关于开发人员使用的版本控制系统的问卷调查。

GitHub 的发布时间距离 Git 自身发布时间很近。2005 年，Linus Torvalds 发布了 Git 的首个版本。现在的年经一代开发者可能很难想象“版本控制软件”一词所代表的世界并不仅仅只有 Git，虽然这样的世界诞生的时间并不长。除了 Git 外，还有很多可供选择。那时，开源开发者较喜欢 Subversion，企业和视频游戏公司使用 Perforce （到如今有些仍在用），而 Linux 内核项目依赖于名为 BitKeeper 的版本控制系统。

其中一些系统，特别是 BitKeeper，会让年经一代的 Git 用户感觉很熟悉，上手也很快，但大多数相差很大。除了 BitKeeper，Git 之前的版本控制系统都是以不同的架构模型为基础运行的。《Version Control By Example》一书的作者 Eric Sink 在他的书中对版本控制进行了分类，按其说法，Git 属于第三代版本控制系统，而大多数 Git 的前身，即流行于二十世纪九零年代和二十一世纪早期的系统，都属于第二代版本控制系统。 2 第三代版本控制系统是分布式的，第二代是集中式。你们以前大概都听过 Git 被描述为一款“分布式”版本控制系统。我一直都不明白分布式/集中式之间的区别，随后自己亲自安装了一款第二代的集中式版本控件系统，并做了相关实验，至少明白了一些。

我安装的版本系统是 CVS。CVS，即 “ 并发版本系统 Concurrent Versions System ” 的缩写，是最初的第二代版本控制系统。大约十年间，它是最为流行的版本控制系统，直到 2000 年被 Subversion 所取代。即便如此，Subversion 被认为是 “更好的 CVS”，这更进一步突出了 CVS 在二十世纪九零年代的主导地位。

CVS 最早是由一位名叫 Dick Grune 的荷兰科学家在 1986 年开发的，当时有一个编译器项目，他正在寻找一种能与其学生合作的方法。 3 CVS 最初仅仅只是一个包装了 RCS（ 修订控制系统 Revision Control System ) 的 Shell 脚本集合，Grune 想改进这个第一代的版本控制系统。 RCS 是按悲观锁模式工作的，这意味着两个程序员不可以同时处理同一个文件。需要编辑一个文件话，首先得向 RCS 系统请求一个排它锁，锁定此文件直到完成编辑，如果你想编辑的文件有人正在编辑，你就必须等待。CVS 在 RCS 基础上改进，并把悲观锁模型替换成乐观锁模型，迎来了第二代版本控制系统的时代。现在，程序员可以同时编辑同一个文件、合并编辑部分，随后解决合并冲突问题。（后来接管 CVS 项目的工程师 Brian Berliner 于 1990 年撰写了一篇非常易读的关于 CVS 创新的 论文。）

从这个意义上来讲，CVS 与 Git 并无差异，因为 Git 也是运行于乐观锁模式的，但也仅仅只有此点相似。实际上，Linus Torvalds 开发 Git 时，他的一个指导原则是 WWCVSND，即 “ CVS 不能做的 What Would CVS Not Do ”。每当他做决策时，他都会力争选择那些在 CVS 设计里没有使用的功能选项。 4 所以即使 CVS 要早于 Git 十多年，但它对 Git 的影响是反面的。

我非常喜欢折腾 CVS。我认为要弄明白为什么 Git 的分布式特性是对以前的版本控制系统的极大改善的话，除了折腾 CVS 外，没有更好的办法。因此，我邀请你跟我一起来一段激动人心的旅程，并在接下来的十分钟内了解下这个近十年来无人使用的软件。（可以看看文末“修正”部分）

CVS 入门

CVS 的安装教程可以在其 项目主页 上找到。MacOS 系统的话，可以使用 Homebrew 安装。

由于 CVS 是集中式的，所以它有客户端和服务端之区分，这种模式 Git 是没有的。两端分别有不同的可执行文件，其区别不太明显。但要开始使用 CVS 的话，即使只在你的本地机器上使用，也必须设置 CVS 的服务后端。

CVS 的后端，即所有代码的中央存储区，被叫做 存储库 repository 。在 Git 中每一个项目都有一个存储库，而 CVS 中一个存储库就包含所有的项目。尽管有办法保证一次只能访问一个项目，但一个中央存储库包含所有东西是改变不了的。

要在本地创建存储库的话，请运行 init 命令。你可以像如下所示在家目录创建，也可以在你本地的任何地方创建。

$ cvs -d ~/sandbox init

CVS 允许你将选项传递给 cvs 命令本身或 init 子命令。出现在 cvs 命令之后的选项默认是全局的，而出现在子命令之后的是子命令特有选项。上面所示例子中，-d 标志是全局选项。在这儿是告诉 CVS 我们想要创建存储库路径在哪里，但一般 -d 标志指的是我们想要使用的且已经存在的存储库位置。一直使用 -d 标志很单调乏味，所以可以设置 CVSROOT 环境变量来代替。

因为我们只是在本地操作，所以仅仅使用 -d 参考来传递路径就可以，但也可以包含个主机名。

此命令在你的家目录创建了一个名叫 sandbox 的目录。 如果你列出 sandbox 内容，会发现下面包含有名为 CVSROOT 的目录。请不要把此目录与我们的环境变量混淆，它保存存储库的管理文件。

恭喜！ 你刚刚创建了第一个 CVS 存储库。

检入代码

假设你决定留存下自己喜欢的颜色清单。因为你是一个有艺术倾向但很健忘的人，所以你键入颜色列表清单，并保存到一个叫 favorites.txt 的文件中：

blue
orange
green

definitely not yellow

我们也假设你把文件保存到一个叫 colors 的目录中。现在你想要把喜欢的颜色列表清单置于版本控制之下，因为从现在起的五十年间你会回顾下，随着时间的推移自己的品味怎么变化，这件事很有意思。

为此，你必须将你的目录导入为新的 CVS 项目。可以使用 import 命令：

$ cvs -d ~/sandbox import -m "" colors colors initial
N colors/favorites.txt

No conflicts created by this import

这里我们再次使用 -d 标志来指定存储库的位置，其余的参数是传输给 import 子命令的。必须要提供一条消息，但这儿没必要，所以留空。下一个参数 colors，指定了存储库中新目录的名字，这儿给的名字跟检入的目录名称一致。最后的两个参数分别指定了 “vendor” 标签和 “release” 标签。我们稍后就会谈论标签。

我们刚将 colors 项目拉入 CVS 存储库。将代码引入 CVS 有很多种不同的方法，但这是 《Pragmatic Version Control Using CVS》 一书所推荐方法，这是一本关于 CVS 的程序员实用指导书籍。使用这种方法有点尴尬的就是你得重新 检出 check out 工作项目，即使已经存在有 colors 此项目了。不要使用该目录，首先删除它，然后从 CVS 中检出刚才的版本，如下示：

$ cvs -d ~/sandbox co colors
cvs checkout: Updating colors
U colors/favorites.txt

这个过程会创建一个新的目录，也叫做 colors。此目录里会发现你的源文件 favorites.txt，还有一个叫 CVS 的目录。这个 CVS 目录基本上与每个 Git 存储库的 .git 目录等价。

做出改动

准备旅行。

和 Git 一样，CVS 也有 status 命令：

$ cvs status
cvs status: Examining .
===================================================================
File: favorites.txt     Status: Up-to-date

   Working revision:    1.1.1.1 2018-07-06 19:27:54 -0400
   Repository revision: 1.1.1.1 /Users/sinclairtarget/sandbox/colors/favorites.txt,v
   Commit Identifier:   fD7GYxt035GNg8JA
   Sticky Tag:      (none)
   Sticky Date:     (none)
   Sticky Options:  (none)

到这儿事情开始陌生起来了。CVS 没有提交对象这一概念。如上示，有一个叫 “ 提交标识符 Commit Identifier ” 的东西，但这可能是一个较新版本的标识，在 2003 年出版的《Pragmatic Version Control Using CVS》一书中并没有提到 “提交标识符” 这个概念。 （CVS 的最新版本于 2008 年发布的。 5 ）

在 Git 中，我们所谈论某文件版本其实是在谈论如 commit 45de392 相关的东西，而 CVS 中文件是独立版本化的。文件的第一个版本为 1.1 版本，下一个是 1.2 版本，依此类推。涉及分支时，会在后面添加扩展数字。因此你会看到如上所示的 1.1.1.1 的内容，这就是示例的版本号，即使我们没有创建分支，似乎默认的会给加上。

一个项目中会有很多的文件和很多次的提交，如果你运行 cvs log 命令（等同于 git log），会看到每个文件提交历史信息。同一个项目中，有可能一个文件处于 1.2 版本，一个文件处于 1.14 版本。

继续，我们对 1.1 版本的 favorites.txt 文件做些修改（LCTT 译注：原文此处示例有误）：

blue
orange
green
cyan

definitely not yellow

修改完成，就可以运行 cvs diff 来看看 CVS 发生了什么：

$ cvs diff
cvs diff: Diffing .
Index: favorites.txt
===================================================================
RCS file: /Users/sinclairtarget/sandbox/colors/favorites.txt,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 favorites.txt
3a4
> cyan

CVS 识别出我们我在文件中添加了一个包含颜色 “cyan” 的新行。（实际上，它说我们已经对 “RCS” 文件进行了更改；你可以看到，CVS 底层使用的还是 RCS。） 此差异指的是当前工作目录中的 favorites.txt 副本与存储库中 1.1.1.1 版本的文件之间的差异。

为了更新存储库中的版本，我们必须提交更改。Git 中，这个操作要好几个步骤。首先，暂存此修改，使其在索引中出现，然后提交此修改，最后，为了使此修改让其他人可见，我们必须把此提交推送到源存储库中。

而 CVS 中，只需要运行 cvs commit 命令就搞定一切。CVS 会汇集它所找到的变化，然后把它们放到存储库中：

$ cvs commit -m "Add cyan to favorites."
cvs commit: Examining .
/Users/sinclairtarget/sandbox/colors/favorites.txt,v <-- favorites.txt
new revision: 1.2; previous revision: 1.1

我已经习惯了 Git，所以这种操作会让我感到十分恐惧。因为没有变更暂存区的机制，工作目录下任何你动过的东西都会一股脑给提交到公共存储库中。你有过因为不爽，私下里重写了某个同事不佳的函数实现，但仅仅只是自我宣泄一下并不想让他知道的时候吗？如果不小心提交上去了，就太糟糕了，他会认为你是个混蛋。在推送它们之前，你也不能对提交进行编辑，因为提交就是推送。还是你愿意花费 40 分钟的时间来反复运行 git rebase -i 命令，以使得本地提交历史记录跟数学证明一样清晰严谨？很遗憾，CVS 里不支持，结果就是，大家都会看到你没有先写测试用例。

不过，到现在我终于理解了为什么那么多人都觉得 Git 没必要搞那么复杂。对那些早已经习惯直接 cvs commit 的人来说，进行暂存变更和推送变更操作确实是毫无意义的差事。

人们常谈论 Git 是一个 “分布式” 系统，其中分布式与非分布式的主要区别为：在 CVS 中，无法进行本地提交。提交操作就是向中央存储库提交代码，所以没有网络连接，就无法执行操作，你本地的那些只是你的工作目录而已；在 Git 中，会有一个完完全全的本地存储库，所以即使断网了也可以无间断执行提交操作。你还可以编辑那些提交、回退、分支，并选择你所要的东西，没有任何人会知道他们必须知道的之外的东西。

因为提交是个大事，所以 CVS 用户很少做提交。提交会包含很多的内容修改，就像如今我们能在一个含有十次提交的拉取请求中看到的一样多。特别是在提交触发了 CI 构建和自动测试程序时如此。

现在我们运行 cvs status，会看到产生了文件的新版本：

$ cvs status
cvs status: Examining .
===================================================================
File: favorites.txt     Status: Up-to-date

   Working revision:    1.2 2018-07-06 21:18:59 -0400
   Repository revision: 1.2 /Users/sinclairtarget/sandbox/colors/favorites.txt,v
   Commit Identifier:   pQx5ooyNk90wW8JA
   Sticky Tag:      (none)
   Sticky Date:     (none)
   Sticky Options:  (none)

合并

如上所述，在 CVS 中，你可以同时编辑其他人正在编辑的文件。这是 CVS 对 RCS 的重大改进。当需要将更改的部分重新组合在一起时会发生什么？

假设你邀请了一些朋友来将他们喜欢的颜色添加到你的列表中。在他们添加的时候，你确定了不再喜欢绿色，然后把它从列表中删除。

当你提交更新的时候，会发现 CVS 报出了个问题：

$ cvs commit -m "Remove green"
cvs commit: Examining .
cvs commit: Up-to-date check failed for `favorites.txt'
cvs [commit aborted]: correct above errors first!

这看起来像是朋友们首先提交了他们的变化。所以你的 favorites.txt 文件版本没有更新到存储库中的最新版本。此时运行 cvs status 就可以看到，本地的 favorites.txt 文件副本有一些本地变更且是 1.2 版本的，而存储库上的版本号是 1.3，如下示：

$ cvs status
cvs status: Examining .
===================================================================
File: favorites.txt     Status: Needs Merge

   Working revision:    1.2 2018-07-07 10:42:43 -0400
   Repository revision: 1.3 /Users/sinclairtarget/sandbox/colors/favorites.txt,v
   Commit Identifier:   2oZ6n0G13bDaldJA
   Sticky Tag:      (none)
   Sticky Date:     (none)
   Sticky Options:  (none)

你可以运行 cvs diff 来了解 1.2 版本与 1.3 版本的确切差异：

$ cvs diff -r HEAD favorites.txt
Index: favorites.txt
===================================================================
RCS file: /Users/sinclairtarget/sandbox/colors/favorites.txt,v
retrieving revision 1.3
diff -r1.3 favorites.txt
3d2
< green
7,10d5
<
< pink
< hot pink
< bubblegum pink

看来我们的朋友是真的喜欢粉红色，但好在他们编辑的是此文件的不同部分，所以很容易地合并此修改。跟 git pull 类似，只要运行 cvs update 命令，CVS 就可以为我们做合并操作，如下示：

$ cvs update
cvs update: Updating .
RCS file: /Users/sinclairtarget/sandbox/colors/favorites.txt,v
retrieving revision 1.2
retrieving revision 1.3
Merging differences between 1.2 and 1.3 into favorites.txt
M favorites.txt

此时查看 favorites.txt 文件内容的话，你会发现你的朋友对文件所做的更改已经包含进去了，你的修改也在里面。现在你可以自由的提交文件了，如下示：

$ cvs commit
cvs commit: Examining .
/Users/sinclairtarget/sandbox/colors/favorites.txt,v <-- favorites.txt
new revision: 1.4; previous revision: 1.3

最终的结果就跟在 Git 中运行 git pull --rebase 一样。你的修改是添加在你朋友的修改之后的，所以没有 “合并提交” 这操作。

某些时候，对同一文件的修改可能导致冲突。例如，如果你的朋友把 “green” 修改成 “olive”，同时你完全删除 “green”，就会出现冲突。CVS 早期的时候，正是这种情况导致人们担心 CVS 不安全，而 RCS 的悲观锁机制可以确保此情况永不会发生。但 CVS 提供了一个安全保障机制，可以确保不会自动的覆盖任何人的修改。因此，当运行 cvs update 的时候，你必须告诉 CVS 想要保留哪些修改才能继续下一步操作。CVS 会标记文件的所有变更，这跟 Git 检测到合并冲突时所做的方式一样，然后，你必须手工编辑文件，选择需要保留的变更进行合并。

这儿需要注意的有趣事情就是在进行提交之前必须修复并合并冲突。这是 CVS 集中式特性的另一个结果。而在 Git 里，在推送本地的提交内容之前，你都不用担心合并冲突问题。

标记与分支

由于 CVS 没有易于寻址的提交对象，因此对变更集合进行分组的唯一方法就是对于特定的工作目录状态打个标记。

创建一个标记是很容易的：

$ cvs tag VERSION_1_0
cvs tag: Tagging .
T favorites.txt

稍后，运行 cvs update 命令并把标签传输给 -r 标志就可以把文件恢复到此状态，如下示：

$ cvs update -r VERSION_1_0
cvs update: Updating .
U favorites.txt

因为你需要一个标记来回退到早期的工作目录状态，所以 CVS 鼓励创建大量的抢先标记。例如，在重大的重构之前，你可以创建一个 BEFORE_REFACTOR_01 标记，如果重构出错，就可以使用此标记回退。你如果想生成整个项目的差异文件的话，也可以使用标记。基本上，如今我们惯常使用提交的哈希值完成的事情都必须在 CVS 中提前计划，因为你必须首先有个标签才行。

可以在 CVS 中创建分支。分支只是一种特殊的标记，如下示：

$ cvs rtag -b TRY_EXPERIMENTAL_THING colors
cvs rtag: Tagging colors

这命令仅仅只是创建了分支（每个人都这样觉得吧），所以还需要使用 cvs update 命令来切换分支，如下示：

$ cvs update -r TRY_EXPERIMENTAL_THING

上面的命令就会把你的当前工作目录切换到新的分支，但《Pragmatic Version Control Using CVS》一书实际上是建议创建一个新的目录来房子你的新分支。估计，其作者发现在 CVS 里切换目录要比切换分支来得更简单吧。

此书也建议不要从现有分支创建分支，而只在主线分支（Git 中被叫做 master）上创建分支。一般来说，分支在 CVS 中主认为是 “高级” 技能。而在 Git 中，你几乎可以任性创建新分支，但 CVS 中要在真正需要的时候才能创建，比如发布项目。

稍后可以使用 cvs update 和 -j 标志将分支合并回主线：

$ cvs update -j TRY_EXPERIMENTAL_THING

感谢历史上的贡献者

2007 年，Linus Torvalds 在 Google 进行了一场关于 Git 的 演讲。当时 Git 是很新的东西，整场演讲基本上都是在说服满屋子都持有怀疑态度的程序员们：尽管 Git 是如此的与众不同，也应该使用 Git。如果没有看过这个视频的话，我强烈建议你去看看。Linus 是个有趣的演讲者，即使他有些傲慢。他非常出色地解释了为什么分布式的版本控制系统要比集中式的优秀。他的很多评论是直接针对 CVS 的。

Git 是一个 相当复杂的工具。学习起来是一个令人沮丧的经历，但也不断的给我惊喜：Git 还能做这样的事情。相比之下，CVS 简单明了，但是，许多我们认为理所当然的操作都做不了。想要对 Git 的强大功能和灵活性有全新的认识的话，就回过头来用用 CVS 吧，这是种很好的学习方式。这很好的诠释了为什么理解软件的开发历史可以让人受益匪浅。重拾过期淘汰的工具可以让我们理解今天所使用的工具后面所隐藏的哲理。

如果你喜欢此博文的话，每两周会有一次更新！请在 Twitter 上关注 @TwoBitHistory 或都通过 RSS feed 订阅，新博文出来会有通知。

修正

有人告诉我，有很多组织企业，特别是像做医疗设备软件等这种规避风险类的企业，仍在使用 CVS。这些企业中的程序员通过使用一些小技巧来解决 CVS 的限制，例如为几乎每个更改创建一个新分支以避免直接提交给 HEAD。 （感谢 Michael Kohne 指出这一点。）

（题图：plasticscm）

via: https://twobithistory.org/2018/07/07/cvs.html

作者：Two-Bit History 选题：lujun9972 译者：runningwater 校对：wxy

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

  1. “2015 Developer Survey,” Stack Overflow, accessed July 7, 2018, https://insights.stackoverflow.com/survey/2015#tech-sourcecontrol. ↩
  2. Eric Sink, “A History of Version Control,” Version Control By Example, 2011, accessed July 7, 2018, https://ericsink.com/vcbe/html/history_of_version_control.html. ↩
  3. Dick Grune, “Concurrent Versions System CVS,” dickgrune.com, accessed July 7, 2018, https://dickgrune.com/Programs/CVS.orig/#History. ↩
  4. “Tech Talk: Linus Torvalds on Git,” YouTube, May 14, 2007, accessed July 7, 2018, https://www.youtube.com/watch?v=4XpnKHJAok8. ↩
  5. “Concurrent Versions System - News,” Savannah, accessed July 7, 2018, http://savannah.nongnu.org/news/?group=cvs. ↩

gitbase 是一个使用 go 开发的的开源项目，它实现了在 Git 仓库上执行 SQL 查询。

Git 已经成为了代码版本控制的事实标准，但尽管 Git 相当普及，对代码仓库的深入分析的工作难度却没有因此而下降；而 SQL 在大型代码库的查询方面则已经是一种久经考验的语言，因此诸如 Spark 和 BigQuery 这样的项目都采用了它。

所以，source{d} 很顺理成章地将这两种技术结合起来，就产生了 gitbase（LCTT 译注：source{d} 是一家开源公司，本文作者是该公司开发者关系副总裁）。gitbase 是一个 代码即数据 code-as-data 的解决方案，可以使用 SQL 对 git 仓库进行大规模分析。

gitbase 是一个完全开源的项目。它站在了很多巨人的肩上，因此得到了足够的发展竞争力。下面就来介绍一下其中的一些“巨人”。

gitbase playground 为 gitbase 提供了一个可视化的操作环境。

用 Vitess 解析 SQL

gitbase 通过 SQL 与用户进行交互，因此需要能够遵循 MySQL 协议来对通过网络传入的 SQL 请求作出解析和理解，万幸由 YouTube 建立的 Vitess 项目已经在这一方面给出了解决方案。Vitess 是一个横向扩展的 MySQL 数据库集群系统。

我们只是使用了这个项目中的部分重要代码，并将其转化为一个可以让任何人在数分钟以内编写出一个 MySQL 服务器的开源程序，就像我在 justforfunc 视频系列中展示的 CSVQL 一样，它可以使用 SQL 操作 CSV 文件。

用 go-git 读取 git 仓库

在成功解析 SQL 请求之后，还需要对数据集中的 git 仓库进行查询才能返回结果。因此，我们还结合使用了 source{d} 最成功的 go-git 仓库。go-git 是使用纯 go 语言编写的具有高度可扩展性的 git 实现。

借此我们就可以很方便地将存储在磁盘上的代码仓库保存为 siva 文件格式（这同样是 source{d} 的一个开源项目），也可以通过 git clone 来对代码仓库进行复制。

使用 enry 检测语言、使用 babelfish 解析文件

gitbase 集成了我们开源的语言检测项目 enry 以及代码解析项目 babelfish，因此在分析 git 仓库历史代码的能力也相当强大。babelfish 是一个自托管服务，普适于各种源代码解析，并将代码文件转换为 通用抽象语法树 Universal Abstract Syntax Tree （UAST）。

这两个功能在 gitbase 中可以被用户以函数 LANGUAGE 和 UAST 调用，诸如“查找上个月最常被修改的函数的名称”这样的请求就需要通过这两个功能实现。

提高性能

gitbase 可以对非常大的数据集进行分析，例如来自 GitHub 高达 3 TB 源代码的 Public Git Archive（公告）。面临的工作量如此巨大，因此每一点性能都必须运用到极致。于是，我们也使用到了 Rubex 和 Pilosa 这两个项目。

使用 Rubex 和 Oniguruma 优化正则表达式速度

Rubex 是 go 的正则表达式标准库包的一个准替代品。之所以说它是准替代品，是因为它没有在 regexp.Regexp 类中实现 LiteralPrefix 方法，直到现在都还没有。

Rubex 的高性能是由于使用 cgo 调用了 Oniguruma，它是一个高度优化的 C 代码库。

使用 Pilosa 索引优化查询速度

索引几乎是每个关系型数据库都拥有的特性，但 Vitess 由于不需要用到索引，因此并没有进行实现。

于是我们引入了 Pilosa 这个开源项目。Pilosa 是一个使用 go 实现的分布式位图索引，可以显著提升跨多个大型数据集的查询的速度。通过 Pilosa，gitbase 才得以在巨大的数据集中进行查询。

总结

我想用这一篇文章来对开源社区表达我衷心的感谢，让我们能够不负众望的在短时间内完成 gitbase 的开发。我们 source{d} 的每一位成员都是开源的拥护者，github.com/src-d 下的每一行代码都是见证。

你想使用 gitbase 吗？最简单快捷的方式是从 sourced.tech/engine 下载 source{d} 引擎，就可以通过单个命令运行 gitbase 了。

想要了解更多，可以听听我在 Go SF 大会上的演讲录音。

本文在 Medium 首发，并经许可在此发布。

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

作者：Francesc Campoy 选题：lujun9972 译者：HankChow 校对：wxy

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

  1. 1
  2. ...
  3. 8
  4. 9
  5. 10
  6. 11
  7. 12
  8. 13
  9. 14
  10. ...
  11. 19