在本文中，我们的目的是让你了解如何设置属于自己的Git服务器。

Git 是由 Linux Torvalds 开发的一个版本控制系统，现如今正在被全世界大量开发者使用。许多公司喜欢使用基于 Git 版本控制的 GitHub 代码托管。根据报道，GitHub 是现如今全世界最大的代码托管网站。GitHub 宣称已经有 920 万用户和 2180 万个仓库。许多大型公司现如今也将代码迁移到 GitHub 上。甚至于谷歌，一家搜索引擎公司，也正将代码迁移到 GitHub 上。

运行你自己的 Git 服务器

GitHub 能提供极佳的服务，但却有一些限制，尤其是你是单人或是一名 coding 爱好者。GitHub 其中之一的限制就是其中免费的服务没有提供代码私有托管业务。你不得不支付每月 7 美金购买 5 个私有仓库，并且想要更多的私有仓库则要交更多的钱。

万一你想要私有仓库或需要更多权限控制，最好的方法就是在你的服务器上运行 Git。不仅你能够省去一笔钱，你还能够在你的服务器有更多的操作。在大多数情况下，大多数高级 Linux 用户已经拥有自己的服务器，并且在这些服务器上方式 Git 就像“啤酒一样免费”（LCTT 译注：指免费软件）。

在这篇教程中，我们主要讲在你的服务器上，使用两种代码管理的方法。一种是运行一个纯 Git 服务器，另一个是使用名为 GitLab 的 GUI 工具。在本教程中，我在 VPS 上运行的操作系统是 Ubuntu 14.04 LTS。

在你的服务器上安装 Git

在本篇教程中，我们考虑一个简单案例，我们有一个远程服务器和一台本地服务器，现在我们需要使用这两台机器来工作。为了简单起见，我们就分别叫它们为远程服务器和本地服务器。

首先，在两边的机器上安装 Git。你可以从依赖包中安装 Git，在本文中，我们将使用更简单的方法：

sudo apt-get install git-core

为 Git 创建一个用户。

sudo useradd git
passwd git

为了容易的访问服务器，我们设置一个免密 ssh 登录。首先在你本地电脑上创建一个 ssh 密钥：

ssh-keygen -t rsa

这时会要求你输入保存密钥的路径，这时只需要点击回车保存在默认路径。第二个问题是输入访问远程服务器所需的密码。它生成两个密钥——公钥和私钥。记下您在下一步中需要使用的公钥的位置。

现在您必须将这些密钥复制到服务器上，以便两台机器可以相互通信。在本地机器上运行以下命令：

cat ~/.ssh/id_rsa.pub | ssh git@remote-server "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

现在，用 ssh 登录进服务器并为 Git 创建一个项目路径。你可以为你的仓库设置一个你想要的目录。

现在跳转到该目录中：

cd /home/swapnil/project-1.git

现在新建一个空仓库：

git init --bare
Initialized empty Git repository in /home/swapnil/project-1.git

现在我们需要在本地机器上新建一个基于 Git 版本控制仓库：

mkdir -p /home/swapnil/git/project

进入我们创建仓库的目录：

cd /home/swapnil/git/project

现在在该目录中创建项目所需的文件。留在这个目录并启动 git：

git init
Initialized empty Git repository in /home/swapnil/git/project

把所有文件添加到仓库中：

git add .

现在，每次添加文件或进行更改时，都必须运行上面的 add 命令。 您还需要为每个文件更改都写入提交消息。提交消息基本上说明了我们所做的更改。

git commit -m "message" -a
[master (root-commit) 57331ee] message
 2 files changed, 2 insertions(+)
 create mode 100644 GoT.txt
 create mode 100644 writing.txt

在这种情况下，我有一个名为 GoT（《权力的游戏》的点评）的文件，并且我做了一些更改，所以当我运行命令时，它指定对文件进行更改。 在上面的命令中 -a 选项意味着提交仓库中的所有文件。 如果您只更改了一个，则可以指定该文件的名称而不是使用 -a。

举一个例子：

git commit -m "message" GoT.txt
[master e517b10] message
 1 file changed, 1 insertion(+)

到现在为止，我们一直在本地服务器上工作。现在我们必须将这些更改推送到远程服务器上，以便通过互联网访问，并且可以与其他团队成员进行协作。

git remote add origin ssh://git@remote-server/repo-<wbr< a="">>path-on-server..git

现在，您可以使用 pull 或 push 选项在服务器和本地计算机之间推送或拉取：

git push origin master

如果有其他团队成员想要使用该项目，则需要将远程服务器上的仓库克隆到其本地计算机上：

git clone git@remote-server:/home/swapnil/project.git

这里 /home/swapnil/project.git 是远程服务器上的项目路径，在你本机上则会改变。

然后进入本地计算机上的目录（使用服务器上的项目名称）：

cd /project

现在他们可以编辑文件，写入提交更改信息，然后将它们推送到服务器：

git commit -m 'corrections in GoT.txt story' -a

然后推送改变：

git push origin master

我认为这足以让一个新用户开始在他们自己的服务器上使用 Git。 如果您正在寻找一些 GUI 工具来管理本地计算机上的更改，则可以使用 GUI 工具，例如 QGit 或 GitK for Linux。

使用 GitLab

这是项目所有者和协作者的纯命令行解决方案。这当然不像使用 GitHub 那么简单。不幸的是，尽管 GitHub 是全球最大的代码托管商，但是它自己的软件别人却无法使用。因为它不是开源的，所以你不能获取源代码并编译你自己的 GitHub。这与 WordPress 或 Drupal 不同，您无法下载 GitHub 并在您自己的服务器上运行它。

像往常一样，在开源世界中，是没有终结的尽头。GitLab 是一个非常优秀的项目。这是一个开源项目，允许用户在自己的服务器上运行类似于 GitHub 的项目管理系统。

您可以使用 GitLab 为团队成员或公司运行类似于 GitHub 的服务。您可以使用 GitLab 在公开发布之前开发私有项目。

GitLab 采用传统的开源商业模式。他们有两种产品：免费的开源软件，用户可以在自己的服务器上安装，以及类似于 GitHub 的托管服务。

可下载版本有两个版本，免费的社区版和付费企业版。企业版基于社区版，但附带针对企业客户的其他功能。它或多或少与 WordPress.org 或 Wordpress.com 提供的服务类似。

社区版具有高度可扩展性，可以在单个服务器或群集上支持 25000 个用户。GitLab 的一些功能包括：Git 仓库管理，代码评论，问题跟踪，活动源和维基。它配备了 GitLab CI，用于持续集成和交付。

Digital Ocean 等许多 VPS 提供商会为用户提供 GitLab 服务。 如果你想在你自己的服务器上运行它，你可以手动安装它。GitLab 为不同的操作系统提供了软件包。 在我们安装 GitLab 之前，您可能需要配置 SMTP 电子邮件服务器，以便 GitLab 可以在需要时随时推送电子邮件。官方推荐使用 Postfix。所以，先在你的服务器上安装 Postfix：

sudo apt-get install postfix

在安装 Postfix 期间，它会问你一些问题，不要跳过它们。 如果你一不小心跳过，你可以使用这个命令来重新配置它：

sudo dpkg-reconfigure postfix

运行此命令时，请选择 “Internet Site”并为使用 Gitlab 的域名提供电子邮件 ID。

我是这样输入的：

[email protected]

用 Tab 键并为 postfix 创建一个用户名。接下来将会要求你输入一个目标邮箱。

在剩下的步骤中，都选择默认选项。当我们安装且配置完成后，我们继续安装 GitLab。

我们使用 wget 来下载软件包(用 最新包 替换下载链接)：

wget https://downloads-packages.s3.amazonaws.com/ubuntu-14.04/gitlab_7.9.4-omnibus.1-1_amd64.deb

然后安装这个包：

sudo dpkg -i gitlab_7.9.4-omnibus.1-1_amd64.deb

现在是时候配置并启动 GitLab 了。

sudo gitlab-ctl reconfigure

您现在需要在配置文件中配置域名，以便您可以访问 GitLab。打开文件。

nano /etc/gitlab/gitlab.rb

在这个文件中编辑 external_url 并输入服务器域名。保存文件，然后从 Web 浏览器中打开新建的一个 GitLab 站点。

默认情况下，它会以系统管理员的身份创建 root，并使用 5iveL!fe 作为密码。 登录到 GitLab 站点，然后更改密码。

密码更改后，登录该网站并开始管理您的项目。

GitLab 有很多选项和功能。最后，我借用电影“黑客帝国”中的经典台词：“不幸的是，没有人知道 GitLab 可以做什么。你必须亲自尝试一下。”

via: https://www.linux.com/learn/how-run-your-own-git-server

作者：Swapnil Bhartiya 选题：lujun9972 译者：wyxplus 校对：wxy

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

在这个 Git 入门系列的第三篇中，我们来学习一下如何添加和删除 Git 分支。

在本系列的前两篇文章中，我们开始使用 Git，学会如何克隆项目，修改、增加和删除内容。在这第三篇文章中，我将介绍 Git 分支，为何以及如何使用分支。

不妨用树来描绘 Git 仓库。图中的树有很多分支，或长或短，或从树干延伸或从其它分支延伸。在这里，我们用树干比作仓库的 master 分支，其中 master 代指 ”master 分支”，是 Git 仓库的中心分支或第一个分支。为简单起见，我们假设 master 是树干，其它分支都是从该分支分出的。

为何在 Git 仓库中使用分支

使用分支的主要理由为：

• 如果你希望为项目增加新特性，但很可能会影响当前可正常工作的代码。对于该项目的活跃用户而言，这是很糟糕的事情。与其将特性加入到其它人正在使用的 master 分支，更好的方法是在仓库的其它分支中变更代码，下面会给出具体的工作方式。
• 更重要的是，Git 其设计用于协作。如果所有人都在你代码仓库的 master 分支上操作，会引发很多混乱。对编程语言或项目的知识和阅历因人而异；有些人可能会编写有错误或缺陷的代码，也可能会编写你觉得不适合该项目的代码。使用分支可以让你核验他人的贡献并选择适合的加入到项目中。（这里假设你是代码库唯一的所有者，希望对增加到项目中的代码有完全的控制。在真实的项目中，代码库有多个具有合并代码权限的所有者）

创建分支

让我们回顾本系列上一篇文章，看一下在我们的 Demo 目录中分支是怎样的。如果你没有完成上述操作，请按照文章中的指示从 GitHub 克隆代码并进入 Demo 目录。运行如下命令：

pwd
git branch
ls -la

pwd 命令（是当前工作目录的英文缩写）返回当前你所处的目录（以便确认你在 Demo 目录中），git branch 列出该项目在你主机上的全部分支，ls -la 列出当前目录下的所有文件。你的终端输出类似于：

在 master 分支中，只有一个文件 README.md。（Git 会友好地忽略掉其它目录和文件。）

接下来，运行如下命令：

git status
git checkout -b myBranch
git status

第一条命令 git status 告知你当前位于 branch master，（就像在终端中看到的那样）它与 origin/master 处于同步状态，这意味着 master 分支的本地副本中的全部文件也出现在 GitHub 中。两份副本没有差异，所有的提交也是一致的。

下一条命令 git checkout -b myBranch 中的 -b 告知 Git 创建一个名为 myBranch 的新分支，然后 checkout 命令将我们切换到新创建的分支。运行第三条命令 git status 确保你已经位于刚创建的分支下。

如你所见，git status 告知你当前处于 myBranch 分支，没有变更需要提交。这是因为我们既没有增加新文件，也没有修改已有文件。

如果希望以可视化的方式查看分支，可以运行 gitk 命令。如果遇到报错 bash: gitk: command not found...，请先安装 gitk 软件包（找到你操作系统对应的安装文档，以获得安装方式）。

（LCTT 译注：需要在有 X 服务器的终端运行 gitk，否则会报错）

下图展示了我们在 Demo 项目中的所作所为：你最后一次提交（的对应信息）是 Delete file.txt，在此之前有三次提交。当前的提交用黄点标注，之前的提交用蓝点标注，黄点和 Delete file.txt 之间的三个方块展示每个分支所在的位置（或者说每个分支中的最后一次提交的位置）。由于 myBranch 刚创建，提交状态与 master 分支及其对应的记为 remotes/origin/master 的远程 master 分支保持一致。（非常感谢来自 Red Hat 的 Peter Savage 让我知道 gitk 这个工具）

下面让我们在 myBranch 分支下创建一个新文件并观察终端输出。运行如下命令：

echo "Creating a newFile on myBranch" > newFile
cat newFile
git status

第一条命令中的 echo 创建了名为 newFile 的文件，接着 cat newFile 打印出文件内容，最后 git status 告知你我们 myBranch 分支的当前状态。在下面的终端输出中，Git 告知 myBranch 分支下有一个名为 newFile 的文件当前处于 untracked 状态。这表明我们没有让 Git 追踪发生在文件 newFile 上的变更。

下一步是增加文件，提交变更并将 newFile 文件推送至 myBranch 分支（请回顾本系列上一篇文章获得更多细节）。

git add newFile
git commit -m "Adding newFile to myBranch"
git push origin myBranch

在上述命令中，push 命令使用的分支参数为 myBranch 而不是 master。Git 添加 newFile 并将变更推送到你 GitHub 账号下的 Demo 仓库中，告知你在 GitHub 上创建了一个与你本地副本分支 myBranch 一样的新分支。终端输出截图给出了运行命令的细节及命令输出。

当你访问 GitHub 时，在分支选择的下拉列表中可以发现两个可供选择的分支。

点击 myBranch 切换到 myBranch 分支，你可以看到在此分支上新增的文件。

截至目前，我们有两个分支：一个是 master 分支，只有一个 README.md 文件；另一个是 myBranch 分支，有两个文件。

你已经知道如何创建分支了，下面我们再创建一个分支。输入如下命令：

git checkout master
git checkout -b myBranch2
touch newFile2
git add newFile2
git commit -m "Adding newFile2 to myBranch2"
git push origin myBranch2

我不再给出终端输出，需要你自己尝试，但你可以在 GitHub 代码库 中验证你的结果。

删除分支

由于我们增加了两个分支，下面删除其中的一个（myBranch），包括两步：

1. 删除本地分支 你不能删除正在操作的分支，故切换到 master 分支 （或其它你希望保留的分支），命令及终端输出如下：

git branch 可以列出可用的分支，使用 checkout 切换到 master 分支，然后使用 git branch -D myBranch 删除该分支。再次运行 git branch 检查是否只剩下两个分支（而不是三个）。

2. 删除 GitHub 上的分支 使用如下命令删除 myBranch 的远程分支：

git push origin :myBranch

上面 push 命令中分支名称前面的冒号（:）告知 GitHub 删除分支。另一种写法为：

git push -d origin myBranch

其中 -d (也可以用 --delete) 也用于告知 GitHub 删除你的分支。

我们学习了 Git 分支的使用，在本系列的下一篇文章中，我们将介绍如何执行 fetch 和 rebase 操作，对于多人同时的贡献的项目而言，这是很必须学会的。

via: https://opensource.com/article/18/5/git-branching

作者：Kedar Vijay Kulkarni 选题：lujun9972 译者：pinewall 校对：wxy

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

这 13 个 Git 技巧将使你的版本控制技能 +1、+1、+1……

Git 是一个分布式版本控制系统，它已经成为开源世界中源代码控制的默认工具，在 4 月 7 日这天，它 13 岁了。使用 Git 令人沮丧的事情之一是你需要知道更多才能有效地使用 Git。但这也可能是使用 Git 比较美妙的一件事，因为没有什么比发现一个新技巧来简化或提高你的工作流的效率更令人快乐了。

为了纪念 Git 的 13 岁生日，这里有 13 条技巧和诀窍来让你的 Git 经验更加有用和强大。从你可能忽略的一些基本知识开始，并扩展到一些真正的高级用户技巧！

1、 你的 ~/.gitconfig 文件

当你第一次尝试使用 git 命令向仓库提交一个更改时，你可能会收到这样的欢迎信息：

*** Please tell me who you are.

Run

  git config --global user.email "[email protected]"

  git config --global user.name "Your Name"

to set your account's default identity.

你可能没有意识到正是这些命令在修改 ~/.gitconfig 的内容，这是 Git 存储全局配置选项的地方。你可以通过 ~/.gitconfig 文件来做大量的事，包括定义别名、永久性打开（或关闭）特定命令选项，以及修改 Git 工作方式（例如，git diff 使用哪个 diff 算法，或者默认使用什么类型的合并策略）。你甚至可以根据仓库的路径有条件地包含其他配置文件！所有细节请参阅 man git-config。

2、 你仓库中的 .git/config 文件

在之前的技巧中，你可能想知道 git config 命令中 --global 标志是干什么的。它告诉 Git 更新 ~/.gitconfig 中的“全局”配置。当然，有全局配置也意味着会有本地配置，显然，如果你省略 --global 标志，git config 将改为更新仓库特有的配置，该配置存储在 .git/config 中。

在 .git/config 文件中设置的选项将覆盖 ~/.gitconfig 文件中的所有设置。因此，例如，如果你需要为特定仓库使用不同的电子邮件地址，则可以运行 git config user.email "[email protected]"。然后，该仓库中的任何提交都将使用你单独配置的电子邮件地址。如果你在开源项目中工作，而且希望它们显示自己的电子邮件地址，同时仍然使用自己工作邮箱作为主 Git 配置，这非常有用。

几乎任何你可以在 ~/.gitconfig 中设置的东西，你也可以在 .git/config 中进行设置，以使其作用于特定的仓库。在下面的技巧中，当我提到将某些内容添加到 ~/.gitconfig 时，只需记住你也可以在特定仓库的 .git/config 中添加来设置那个选项。

3、 别名

别名是你可以在 ~/.gitconfig 中做的另一件事。它的工作原理就像命令行中的 shell —— 它们设定一个新的命令名称，可以调用一个或多个其他命令，通常使用一组特定的选项或标志。它们对于那些你经常使用的又长又复杂的命令来说非常有效。

你可以使用 git config 命令来定义别名 —— 例如，运行 git config --global --add alias.st status 将使运行 git st 与运行 git status 做同样的事情 —— 但是我在定义别名时发现，直接编辑 ~/.gitconfig 文件通常更容易。

如果你选择使用这种方法，你会发现 ~/.gitconfig 文件是一个 INI 文件。INI 是一种带有特定段落的键值对文件格式。当添加一个别名时，你将改变 [alias] 段落。例如，定义上面相同的 git st 别名时，添加如下到文件：

[alias]
st = status

（如果已经有 [alias] 段落，只需将第二行添加到现有部分。）

4、 shell 命令中的别名

别名不仅仅限于运行其他 Git 子命令 —— 你还可以定义运行其他 shell 命令的别名。这是一个用来处理一个反复发生的、罕见和复杂的任务的很好方式：一旦你确定了如何完成它，就可以在别名下保存该命令。例如，我有一些 复刻 fork 的开源项目的仓库，并进行了一些本地修改。我想跟上项目正在进行的开发工作，并保存我本地的变化。为了实现这个目标，我需要定期将来自上游仓库的更改合并到我复刻的项目中 —— 我通过使用我称之为 upstream-merge 的别名来完成。它是这样定义的：

upstream-merge = !"git fetch origin -v && git fetch upstream -v && git merge upstream/master && git push"

别名定义开头的 ! 告诉 Git 通过 shell 运行这个命令。这个例子涉及到运行一些 git 命令，但是以这种方式定义的别名可以运行任何 shell 命令。

（注意，如果你想复制我的 upstream-merge 别名，你需要确保你有一个名为 upstream 的 Git 远程仓库，指向你已经分配的上游仓库，你可以通过运行 git remote add upstream <URL to repo> 来添加一个。）

5、 可视化提交图

如果你在一个有很多分支活动的项目上开发，有时可能很难掌握所有正在发生的工作以及它们之间的相关性。各种图形用户界面工具可让你获取不同分支的图片并在所谓的“提交图表”中提交。例如，以下是我使用 GitLab 提交图表查看器可视化的我的一个仓库的一部分：

如果你是一个专注于命令行的用户或者发现分支切换工具让人分心，那么可以从命令行获得类似的提交视图。这就是 git log 命令的 --graph 参数出现的地方：

以下命令可视化相同仓库可达到相同效果：

git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative

--graph 选项将图添加到日志的左侧，--abbrev-commit 缩短提交的 SHA 值，--date=relative 以相对方式表示日期，以及 --pretty 来处理所有其他自定义格式。我有个 git lg 别名用于这个功能，它是我最常用的 10 个命令之一。

6、 更优雅的强制推送

有时，你越是想避开越避不开，你会发现你需要运行 git push --force 来覆盖仓库远程副本上的历史记录。你可能得到了一些反馈，需要你进行交互式 变基 rebase ，或者你可能已经搞砸了，并希望隐藏“罪证”。

当其他人在仓库的远程副本的同一分支上进行更改时，会发生强制推送的危险。当你强制推送已重写的历史记录时，这些提交将会丢失。这就是 git push --force-with-lease 出现的原因 -- 如果远程分支已经更新，它不会允许你强制推送，这确保你不会丢掉别人的工作。

7、 git add -N

你是否使用过 git commit -a 在一次行动中提交所有未完成的修改，但在你推送完提交后才发现 git commit -a 忽略了新添加的文件？你可以使用 git add -N (想想 “notify”) 来解决这个问题，告诉 Git 在第一次实际提交它们之前，你希望在提交中包含新增文件。

8、 git add -p

使用 Git 时的最佳做法是确保每次提交都只包含一个逻辑修改 —— 无论这是修复错误还是添加新功能。然而，有时当你在工作时，你的仓库中的修改最终应该使用多个提交。你怎样才能设法把事情分开，使每个提交只包含适当的修改呢？git add --patch 来拯救你了！

这个标志会让 git add 命令查看你工作副本中的所有变化，并为每个变化询问你是否想要将它提交、跳过，或者推迟决定（你可以在运行该命令后选择 ? 来查看其他更强大的选项）。git add -p 是生成结构良好的提交的绝佳工具。

9、 git checkout -p

与 git add -p 类似，git checkout 命令也接受 --patch 或 -p 选项，这会使其在本地工作副本中显示每个“大块”的改动，并允许丢弃它 —— 简单来说就是将本地工作副本恢复到更改之前的状态。

这真的很棒。例如，当你追踪一个 bug 时引入了一堆调试日志语句，修正了这个 bug 之后，你可以先使用 git checkout -p 移除所有新的调试日志，然后 git add -p 来添加 bug 修复。没有比组合一个优雅的、结构良好的提交更令人满意！

10、 变基时执行命令

有些项目有一个规则，即存储库中的每个提交都必须处于可工作状态 —— 也就是说，在每次提交时，应该可以编译该代码，或者应该运行测试套件而不会失败。 当你在分支上工作时，这并不困难，但是如果你最终因为某种原因需要 变基 rebase 时，那么需要逐步完成每个变基的提交以确保你没有意外地引入一个中断，而这个过程是乏味的。

幸运的是，git rebase 已经覆盖了 -x 或 --exec 选项。git rebase -x <cmd> 将在每个提交在变基中被应用后运行该命令。因此，举个例子，如果你有一个项目，其中使用 npm run tests 运行你的测试套件，git rebase -x npm run tests 将在变基期间每次提交之后运行测试套件。这使你可以查看测试套件是否在任何变基的提交中失败，以便你可以确认测试套件在每次提交时仍能通过。

11、 基于时间的修订引用

很多 Git 子命令都接受一个修订参数来决定命令作用于仓库的哪个部分，可以是某次特定的提交的 SHA1 值，一个分支的名称，甚至是一个符号性的名称如 HEAD（代表当前检出分支最后一次的提交），除了这些简单的形式以外，你还可以附加一个指定的日期或时间作为参数，表示“这个时间的引用”。

这个功能在某些时候会变得十分有用。当你处理最新出现的 bug，自言自语道：“这个功能昨天还是好好的，到底又改了些什么”，不用盯着满屏的 git log 的输出试图弄清楚什么时候更改了提交，你只需运行 git diff HEAD@{yesterday}，看看从昨天以来的所有修改。这也适用于更长的时间段（例如 git diff HEAD@{'2 months ago'}），以及一个确切的日期（例如 git diff HEAD@{'2010-01-01 12:00:00'}）。

你也可以将这些基于日期的修订参数与使用修订参数的任何 Git 子命令一起使用。在 gitrevisions 手册页中有关于具体使用哪种格式的详细信息。

12、 全知的 reflog

你是不是试过在变基时干掉过某次提交，然后发现你需要保留那个提交中一些东西？你可能觉得这些信息已经永远找不回来了，只能重新创建。但是如果你在本地工作副本中提交了，提交就会被添加到引用日志（reflog）中 ，你仍然可以访问到。

运行 git reflog 将在本地工作副本中显示当前分支的所有活动的列表，并为你提供每个提交的 SHA1 值。一旦发现你变基时放弃的那个提交，你可以运行 git checkout <SHA1> 跳转到该提交，复制任何你需要的信息，然后再运行 git checkout HEAD 返回到分支最近的提交去。

13、 自己清理

哎呦！ 事实证明，我的基本数学技能不如我的 Git 技能。 Git 最初是在 2005 年发布的，这意味着它今年会变成 13 岁，而不是 12 岁（LCTT 译注：本文原来是以 12 岁生日为题的）。为了弥补这个错误，这里有可以让我们变成十三岁的第 13 条技巧。

如果你使用基于分支的工作流，随着在一个长期项目上的工作，除非你在每个分支合并时清理干净，否则你最终会得到一大堆分支。这使得你难于找到想要的分支，分支的森林会让你无从找起。甚至更糟糕的是，如果你有大量活跃的分支，确定一个分支是否被合并（可以被安全删除）或仍然没有被合并而应该留下会非常繁琐。幸运的是，Git 可以帮到你：只需要运行 git branch --merged 就可以得到已经被合并到你的当前分支的分支列表，或者 git branch --no-merged 找出被合并到其它分支的分支。默认情况下这会列出你本地工作副本的分支，但是如果你在命令行包括 --remote 或 -r 参数，它也会列出仅存于远程仓库的已合并分支。

重要提示：如果你计划使用 git branch --merged 的输出来清理那些已合并的分支，你要小心它的输出也包括了当前分支（毕竟，这个当前的分支就被合并到当前分支！）。确保你在任何销毁动作之前排除了该分支（如果你忘记了，参见第 12 条技巧来学习 reflog 怎样帮你把分支找回来，希望有用……）。

以上是全部内容

希望这些技巧中至少有一个能够教给你一些关于 Git 的新东西，Git 是一个有 13 年历史的项目，并且在持续创新和增加新功能中。你最喜欢的 Git 技巧是什么？

via: https://opensource.com/article/18/4/git-tips

作者：John SJ Anderson 选题：lujun9972 译者：MjSeven 校对：wxy

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

在 本系列的第一篇文章 开始使用 Git 时，我们创建了一个简单的 Git 仓库，并用我们的计算机连接到它，向其中添加一个文件。在本文中，我们将学习一些关于 Git 的其他内容，即如何克隆（下载）、修改、添加和删除 Git 仓库中的文件。

让我们来克隆一下

假设你在 GitHub 上已经有一个 Git 仓库，并且想从它那里获取你的文件——也许你在你的计算机上丢失了本地副本，或者你正在另一台计算机上工作，但是想访问仓库中的文件，你该怎么办？从 GitHub 下载你的文件？没错！在 Git 术语中我们称之为“ 克隆 clone ”。（你也可以将仓库作为 ZIP 文件下载，但我们将在本文中探讨克隆方式。）

让我们克隆在上一篇文章中创建的名为 Demo 的仓库。（如果你还没有创建 Demo 仓库，请跳回到那篇文章并在继续之前执行那些步骤）要克隆文件，只需打开浏览器并导航到 https://github.com/<your_username>/Demo (其中 <your_username> 是你仓库的名称。例如，我的仓库是 https://github.com/kedark3/Demo)。一旦你导航到该 URL，点击“ 克隆或下载 Clone or download ”按钮，你的浏览器看起来应该是这样的：

正如你在上面看到的，“ 使用 HTTPS 克隆 Clone with HTTPS ”选项已打开。从该下拉框中复制你的仓库地址（https://github.com/<your_username>/Demo.git），打开终端并输入以下命令将 GitHub 仓库克隆到你的计算机：

git clone https://github.com/<your_username>/Demo.git

然后，要查看 Demo 目录中的文件列表，请输入以下命令：

ls Demo/

终端看起来应该是这样的：

修改文件

现在我们已经克隆了仓库，让我们修改文件并在 GitHub 上更新它们。首先，逐个输入下面的命令，将目录更改为 Demo/，检查 README.md 中的内容，添加新的（附加的）内容到 README.md，然后使用 git status 检查状态:

cd Demo/
ls
cat README.md
echo "Added another line to REAMD.md" >> README.md
cat README.md
git status

如果你逐一运行这些命令，终端看起开将会是这样：

让我们看一下 git status 的输出，并了解它的意思。不要担心这样的语句：

On branch master
Your branch is up-to-date with 'origin/master'.".

因为我们还没有学习这些。（LCTT 译注：学了你就知道了）下一行说：Changes not staged for commit（变化未筹划提交）；这是告诉你，它下面列出的文件没有被标记准备（“ 筹划 stage ”）提交。如果你运行 git add，Git 会把这些文件标记为 Ready for commit（准备提交）；换句话说就是 Changes staged for commit（变化筹划提交）。在我们这样做之前，让我们用 git diff 命令来检查我们添加了什么到 Git 中，然后运行 git add。

这里是终端输出：

我们来分析一下：

• diff --git a/README.md b/README.md 是 Git 比较的内容（在这个例子中是 README.md）。
• --- a/README.md 会显示从文件中删除的任何东西。
• +++ b/README.md 会显示从文件中添加的任何东西。
• 任何添加到文件中的内容都以绿色文本打印，并在该行的开头加上 + 号。
• 如果我们删除了任何内容，它将以红色文本打印，并在该行的开头加上 - 号。
• 现在 git status 显示 Changes to be committed:（变化将被提交），并列出文件名（即 README.md）以及该文件发生了什么（即它已经被 modified 并准备提交）。

提示：如果你已经运行了 git add，现在你想看看文件有什么不同，通常 git diff 不会输出任何东西，因为你已经添加了文件。相反，你必须使用 git diff --cached。它会告诉你 Git 添加的当前版本和以前版本文件之间的差别。你的终端输出看起来会是这样：

上传文件到你的仓库

我们用一些新内容修改了 README.md 文件，现在是时候将它上传到 GitHub。

让我们提交更改并将其推送到 GitHub。运行：

git commit -m "Updated Readme file"

这告诉 Git 你正在“提交”已经“添加”的更改，你可能还记得，从本系列的第一部分中，添加一条消息来解释你在提交中所做的操作是非常重要的，以便你在稍后回顾 Git 日志时了解当时的目的。（我们将在下一篇文章中更多地关注这个话题。）Updated Readme file 是这个提交的消息——如果你认为这没有合理解释你所做的事情，那么请根据需要写下你的提交消息。

运行 git push -u origin master，这会提示你输入用户名和密码，然后将文件上传到你的 GitHub 仓库。刷新你的 GitHub 页面，你应该会看到刚刚对 README.md 所做的更改。

终端的右下角显示我提交了更改，检查了 Git 状态，并将更改推送到了 GitHub。git status 显示：

Your branch is ahead of 'origin/master' by 1 commit
  (use "git push" to publish your local commits)

第一行表示在本地仓库中有一个提交，但不在 origin/master 中（即在 GitHub 上）。下一行指示我们将这些更改推送到 origin/master 中，这就是我们所做的。（在本例中，请参阅本系列的第一篇文章，以唤醒你对 origin 含义的记忆。我将在下一篇文章中讨论分支的时候，解释 master 的含义。）

添加新文件到 Git

现在我们修改了一个文件并在 GitHub 上更新了它，让我们创建一个新文件，将它添加到 Git，然后将其上传到 GitHub。 运行：

echo "This is a new file" >> file.txt

这将会创建一个名为 file.txt 的新文件。

如果使用 cat 查看它：

cat file.txt

你将看到文件的内容。现在继续运行：

git status

Git 报告说你的仓库中有一个未跟踪的文件（名为 file.txt）。这是 Git 告诉你说在你的计算机中的仓库目录下有一个新文件，然而你并没有告诉 Git，Git 也没有跟踪你所做的任何修改。

我们需要告诉 Git 跟踪这个文件，以便我们可以提交并上传文件到我们的仓库。以下是执行该操作的命令：

git add file.txt
git status

终端输出如下：

git status 告诉你有 file.txt 被修改，对于 Git 来说它是一个 new file，Git 在此之前并不知道。现在我们已经为 Git 添加了 file.txt，我们可以提交更改并将其推送到 origin/master。

Git 现在已经将这个新文件上传到 GitHub；如果刷新 GitHub 页面，则应该在 GitHub 上的仓库中看到新文件 file.txt。

通过这些步骤，你可以创建尽可能多的文件，将它们添加到 Git 中，然后提交并将它们推送到 GitHub。

从 Git 中删除文件

如果我们发现我们犯了一个错误，并且需要从我们的仓库中删除 file.txt，该怎么办？一种方法是使用以下命令从本地副本中删除文件：

rm file.txt

如果你现在做 git status，Git 就会说有一个文件 not staged for commit（未筹划提交），并且它已经从仓库的本地拷贝中删除了。如果我们现在运行：

git add file.txt
git status

我知道我们正在删除这个文件，但是我们仍然运行 git add，因为我们需要告诉 Git 我们正在做的更改，git add 可以用于我们添加新文件、修改一个已存在文件的内容、或者从仓库中删除文件时。实际上，git add 将所有更改考虑在内，并将这些筹划提交这些更改。如果有疑问，请仔细查看下面终端屏幕截图中每个命令的输出。

Git 会告诉我们已删除的文件正在进行提交。只要你提交此更改并将其推送到 GitHub，该文件也将从 GitHub 的仓库中删除。运行以下命令：

git commit -m "Delete file.txt"
git push -u origin master

现在你的终端看起来像这样：

你的 GitHub 看起来像这样：

现在你知道如何从你的仓库克隆、添加、修改和删除 Git 文件。本系列的下一篇文章将检查 Git 分支。

via: https://opensource.com/article/18/2/how-clone-modify-add-delete-git-files

作者：Kedar Vijay Kulkarni 译者：MjSeven 校对：wxy

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

Gogs 是由 Go 语言编写的，自由开源的 Git 服务。Gogs 是一款无痛式自托管的 Git 服务器，能在尽可能小的硬件资源开销上搭建并运行您的私有 Git 服务器。Gogs 的网页界面和 GitHub 十分相近，且提供 MySQL、PostgreSQL 和 SQLite 数据库支持。

在本教程中，我们将使用 Gogs 在 Ununtu 16.04 上按步骤指导您安装和配置您的私有 Git 服务器。这篇教程中涵盖了如何在 Ubuntu 上安装 Go 语言、PostgreSQL 和安装并且配置 Nginx 网页服务器作为 Go 应用的反向代理的细节内容。

搭建环境

• Ubuntu 16.04
• Root 权限

我们将会接触到的事物

1. 更新和升级系统
2. 安装和配置 PostgreSQL
3. 安装 Go 和 Git
4. 安装 Gogs
5. 配置 Gogs
6. 运行 Gogs 服务器
7. 安装和配置 Nginx 反向代理
8. 测试

步骤 1 - 更新和升级系统

继续之前，更新 Ubuntu 所有的库，升级所有包。

运行下面的 apt 命令：

sudo apt update
sudo apt upgrade

步骤 2 - 安装和配置 PostgreSQL

Gogs 提供 MySQL、PostgreSQL、SQLite 和 TiDB 数据库系统支持。

此步骤中，我们将使用 PostgreSQL 作为 Gogs 程序的数据库。

使用下面的 apt 命令安装 PostgreSQL。

sudo apt install -y postgresql postgresql-client libpq-dev

安装完成之后，启动 PostgreSQL 服务并设置为开机启动。

systemctl start postgresql
systemctl enable postgresql

此时 PostgreSQL 数据库在 Ubuntu 系统上完成安装了。

之后，我们需要为 Gogs 创建数据库和用户。

使用 postgres 用户登录并运行 psql 命令以访问 PostgreSQL 操作界面。

su - postgres
psql

创建一个名为 git 的新用户，给予此用户 CREATEDB 权限。

CREATE USER git CREATEDB;
\password git

创建名为 gogs_production 的数据库，设置 git 用户作为其所有者。

CREATE DATABASE gogs_production OWNER git;

用于 Gogs 的 gogs_production PostgreSQL 数据库和 git 用户已经创建完毕。

步骤 3 - 安装 Go 和 Git

使用下面的 apt 命令从库中安装 Git。

sudo apt install git

此时，为系统创建名为 git 的新用户。

sudo adduser --disabled-login --gecos 'Gogs' git

登录 git 账户并且创建名为 local 的目录。

su - git
mkdir -p /home/git/local

切换到 local 目录，依照下方所展示的内容，使用 wget 命令下载 Go（最新版）。

cd ~/local
wget https://dl.google.com/go/go1.9.2.linux-amd64.tar.gz

解压并且删除 go 的压缩文件。

tar -xf go1.9.2.linux-amd64.tar.gz
rm -f go1.9.2.linux-amd64.tar.gz

Go 二进制文件已经被下载到 ~/local/go 目录。此时我们需要设置环境变量 - 设置 GOROOT 和 GOPATH 目录到系统环境，这样，我们就可以在 git 用户下执行 go 命令。

执行下方的命令。

cd ~/
echo 'export GOROOT=$HOME/local/go' >> $HOME/.bashrc
echo 'export GOPATH=$HOME/go' >> $HOME/.bashrc
echo 'export PATH=$PATH:$GOROOT/bin:$GOPATH/bin' >> $HOME/.bashrc

之后通过运行 source ~/.bashrc 重载 Bash，如下：

source ~/.bashrc

确定您使用的 Bash 是默认的 shell。

现在运行 go 的版本查看命令。

go version

之后确保您得到下图所示的结果。

现在，Go 已经安装在系统的 git 用户下了。

步骤 4 - 使用 Gogs 安装 Git 服务

使用 git 用户登录并且使用 go 命令从 GitHub 下载 Gogs。

su - git
go get -u github.com/gogits/gogs

此命令将在 GOPATH/src 目录下载 Gogs 的所有源代码。

切换至 $GOPATH/src/github.com/gogits/gogs 目录，并且使用下列命令搭建 Gogs。

cd $GOPATH/src/github.com/gogits/gogs
go build

确保您没有遇到错误。

现在使用下面的命令运行 Gogs Go Git 服务器。

./gogs web

此命令将会默认运行 Gogs 在 3000 端口上。

打开网页浏览器，键入您的 IP 地址和端口号，我的是 http://192.168.33.10:3000/ 。

您应该会得到与下方一致的反馈。

Gogs 已经在您的 Ubuntu 系统上安装完毕。现在返回到您的终端，并且键入 Ctrl + C 中止服务。

步骤 5 - 配置 Gogs Go Git 服务器

本步骤中，我们将为 Gogs 创建惯例配置。

进入 Gogs 安装目录并新建 custom/conf 目录。

cd $GOPATH/src/github.com/gogits/gogs
mkdir -p custom/conf/

复制默认的配置文件到 custom 目录，并使用 vim 修改。

cp conf/app.ini custom/conf/app.ini
vim custom/conf/app.ini

在 [server] 小节中，修改 HOST_ADDR 为 127.0.0.1。

[server]
 PROTOCOL = http
 DOMAIN = localhost
 ROOT_URL = %(PROTOCOL)s://%(DOMAIN)s:%(HTTP_PORT)s/
 HTTP_ADDR = 127.0.0.1
 HTTP_PORT = 3000

在 [database] 选项中，按照您的数据库信息修改。

[database]
 DB_TYPE = postgres
 HOST = 127.0.0.1:5432
 NAME = gogs_production
 USER = git
 PASSWD = aqwe123@#

保存并退出。

运行下面的命令验证配置项。

./gogs web

并且确保您得到如下的结果。

Gogs 现在已经按照自定义配置下运行在 localhost 的 3000 端口上了。

步骤 6 - 运行 Gogs 服务器

这一步，我们将在 Ubuntu 系统上配置 Gogs 服务器。我们会在 /etc/systemd/system 目录下创建一个新的服务器配置文件 gogs.service。

切换到 /etc/systemd/system 目录，使用 vim 创建服务器配置文件 gogs.service。

cd /etc/systemd/system
vim gogs.service

粘贴下面的代码到 Gogs 服务器配置文件中。

[Unit]
Description=Gogs
After=syslog.target
After=network.target
After=mariadb.service mysqld.service postgresql.service memcached.service redis.service

[Service]
# Modify these two values and uncomment them if you have
# repos with lots of files and get an HTTP error 500 because
# of that
###
#LimitMEMLOCK=infinity
#LimitNOFILE=65535
Type=simple
User=git
Group=git
WorkingDirectory=/home/git/go/src/github.com/gogits/gogs
ExecStart=/home/git/go/src/github.com/gogits/gogs/gogs web
Restart=always
Environment=USER=git HOME=/home/git

[Install]
WantedBy=multi-user.target

之后保存并且退出。

现在可以重载系统服务器。

systemctl daemon-reload

使用下面的命令开启 Gogs 服务器并设置为开机启动。

systemctl start gogs
systemctl enable gogs

Gogs 服务器现在已经运行在 Ubuntu 系统上了。

使用下面的命令检测：

netstat -plntu
systemctl status gogs

您应该会得到下图所示的结果。

步骤 7 - 为 Gogs 安装和配置 Nginx 反向代理

在本步中，我们将为 Gogs 安装和配置 Nginx 反向代理。我们会在自己的库中调用 Nginx 包。

使用下面的命令添加 Nginx 库。

sudo add-apt-repository -y ppa:nginx/stable

此时更新所有的库并且使用下面的命令安装 Nginx。

sudo apt update
sudo apt install nginx -y

之后，进入 /etc/nginx/sites-available 目录并且创建虚拟主机文件 gogs。

cd /etc/nginx/sites-available
vim gogs

粘贴下面的代码到配置文件。

server {
     listen 80;
     server_name git.hakase-labs.co;

     location / {
         proxy_pass http://localhost:3000;
     }
 }

保存退出。

注意: 请使用您的域名修改 server_name 项。

现在激活虚拟主机并且测试 nginx 配置。

ln -s /etc/nginx/sites-available/gogs /etc/nginx/sites-enabled/
nginx -t

确保没有遇到错误，重启 Nginx 服务器。

systemctl restart nginx

步骤 8 - 测试

打开您的网页浏览器并且输入您的 Gogs URL，我的是 http://git.hakase-labs.co

现在您将进入安装界面。在页面的顶部，输入您所有的 PostgreSQL 数据库信息。

之后，滚动到底部，点击 “Admin account settings” 下拉选项。

输入您的管理者用户名和邮箱。

之后点击 “Install Gogs” 按钮。

然后您将会被重定向到下图显示的 Gogs 用户面板。

下面是 Gogs 的 “Admin Dashboard（管理员面板）”。

现在，Gogs 已经通过 PostgreSQL 数据库和 Nginx 网页服务器在您的 Ubuntu 16.04 上完成安装。

via: https://www.howtoforge.com/tutorial/how-to-install-gogs-go-git-service-on-ubuntu-1604/

作者：Muhammad Arul 译者：CYLeft 校对：wxy

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

在你的日常工作中，不可能每天都从头开始去开发一个新的应用程序。而真实的情况是，在日常工作中，我们大多数时候所面对的都是遗留下来的一个代码库，去修改一些特性的内容或者现存的一些代码行，这是我们在日常工作中很重要的一部分。而这也就是分布式版本控制系统 git 的价值所在。现在，我们来深入了解怎么去使用 git 的历史以及如何很轻松地去浏览它的历史。

Git 历史

首先和最重要的事是，什么是 git 历史？正如其名字一样，它是一个 git 仓库的提交历史。它包含一堆提交信息，其中有它们的作者的名字、该提交的哈希值以及提交日期。查看一个 git 仓库历史的方法很简单，就是一个 git log 命令。

旁注：为便于本文的演示，我们使用 Ruby on Rails 的仓库的 master 分支。之所以选择它的理由是因为，Rails 有良好的 git 历史，漂亮的提交信息、引用以及对每个变更的解释。如果考虑到代码库的大小、维护者的年龄和数量，Rails 肯定是我见过的最好的仓库。当然了，我并不是说其它的 git 仓库做的不好，它只是我见过的比较好的一个仓库。

那么，回到 Rails 仓库。如果你在 Ralis 仓库上运行 git log。你将看到如下所示的输出：

commit 66ebbc4952f6cfb37d719f63036441ef98149418
Author: Arthur Neves <[email protected]>
Date:   Fri Jun 3 17:17:38 2016 -0400

    Dont re-define class SQLite3Adapter on test

    We were declaring  in a few tests, which depending of    the order load will cause an error, as the super class could change.

    see https://github.com/rails/rails/commit/ac1c4e141b20c1067af2c2703db6e1b463b985da#commitcomment-17731383

commit 755f6bf3d3d568bc0af2c636be2f6df16c651eb1
Merge: 4e85538 f7b850e
Author: Eileen M. Uchitelle <[email protected]>
Date:   Fri Jun 3 10:21:49 2016 -0400

    Merge pull request #25263 from abhishekjain16/doc_accessor_thread

    [skip ci] Fix grammar

commit f7b850ec9f6036802339e965c8ce74494f731b4a
Author: Abhishek Jain <[email protected]>
Date:   Fri Jun 3 16:49:21 2016 +0530

    [skip ci] Fix grammar

commit 4e85538dddf47877cacc65cea6c050e349af0405
Merge: 082a515 cf2158c
Author: Vijay Dev <[email protected]>
Date:   Fri Jun 3 14:00:47 2016 +0000

    Merge branch 'master' of github.com:rails/docrails

    Conflicts:
        guides/source/action_cable_overview.md

commit 082a5158251c6578714132e5c4f71bd39f462d71
Merge: 4bd11d4 3bd30d9
Author: Yves Senn <[email protected]>
Date:   Fri Jun 3 11:30:19 2016 +0200

    Merge pull request #25243 from sukesan1984/add_i18n_validation_test

    Add i18n_validation_test

commit 4bd11d46de892676830bca51d3040f29200abbfa
Merge: 99d8d45 e98caf8
Author: Arthur Nogueira Neves <[email protected]>
Date:   Thu Jun 2 22:55:52 2016 -0400

    Merge pull request #25258 from alexcameron89/master

    [skip ci] Make header bullets consistent in engines.md

commit e98caf81fef54746126d31076c6d346c48ae8e1b
Author: Alex Kitchens <[email protected]>
Date:   Thu Jun 2 21:26:53 2016 -0500

    [skip ci] Make header bullets consistent in engines.md

正如你所见，git log 展示了提交的哈希、作者及其 email 以及该提交创建的日期。当然，git 输出的可定制性很强大，它允许你去定制 git log 命令的输出格式。比如说，我们只想看提交信息的第一行，我们可以运行 git log --oneline，它将输出一个更紧凑的日志：

66ebbc4 Dont re-define class SQLite3Adapter on test
755f6bf Merge pull request #25263 from abhishekjain16/doc_accessor_thread
f7b850e [skip ci] Fix grammar4e85538 Merge branch 'master' of github.com:rails/docrails
082a515 Merge pull request #25243 from sukesan1984/add_i18n_validation_test
4bd11d4 Merge pull request #25258 from alexcameron89/master
e98caf8 [skip ci] Make header bullets consistent in engines.md
99d8d45 Merge pull request #25254 from kamipo/fix_debug_helper_test
818397c Merge pull request #25240 from matthewd/reloadable-channels
2c5a8ba Don't blank pad day of the month when formatting dates
14ff8e7 Fix debug helper test

如果你想看 git log 的全部选项，我建议你去查阅 git log 的 man 页面，你可以在一个终端中输入 man git-log 或者 git help log 来获得。

小提示：如果你觉得 git log 看起来太恐怖或者过于复杂，或者你觉得看它太无聊了，我建议你去寻找一些 git 的 GUI 或命令行工具。在之前，我使用过 GitX ，我觉得它很不错，但是，由于我看命令行更“亲切”一些，在我尝试了 tig 之后，就再也没有去用过它。

寻找尼莫

现在，我们已经知道了关于 git log 命令的一些很基础的知识之后，我们来看一下，在我们的日常工作中如何使用它更加高效地浏览历史。

假如，我们怀疑在 String#classify 方法中有一个预期之外的行为，我们希望能够找出原因，并且定位出实现它的代码行。

为达到上述目的，你可以使用的第一个命令是 git grep，通过它可以找到这个方法定义在什么地方。简单来说，这个命令输出了匹配特定模式的那些行。现在，我们来找出定义它的方法，它非常简单 —— 我们对 def classify 运行 grep，然后看到的输出如下：

➜  git grep 'def classify'

activesupport/lib/active_support/core_ext/string/inflections.rb:    def classifyactivesupport/lib/active_support/inflector/methods.rb:    def classify(table_name)tools/profile:    def classify

现在，虽然我们已经看到这个方法是在哪里创建的，但是，并不能够确定它是哪一行。如果，我们在 git grep 命令上增加 -n 标志，git 将提供匹配的行号：

➜  git grep -n 'def classify'

activesupport/lib/active_support/core_ext/string/inflections.rb:205:  def classifyactivesupport/lib/active_support/inflector/methods.rb:186:    def classify(table_name)tools/profile:112:    def classify

更好看了，是吧？考虑到上下文，我们可以很轻松地找到，这个方法在 activesupport/lib/active_support/core_ext/string/inflections.rb 的第 205 行的 classify 方法，它看起来像这样，是不是很容易？

# Creates a class name from a plural table name like Rails does for table names to models.
# Note that this returns a string and not a class. (To convert to an actual class
# follow +classify+ with +constantize+.)
#
#   'ham_and_eggs'.classify # => "HamAndEgg"
#   'posts'.classify        # => "Post"
    def classify
        ActiveSupport::Inflector.classify(self)
    end

尽管我们找到的这个方法是在 String 上的一个常见的调用，它调用了 ActiveSupport::Inflector 上的另一个同名的方法。根据之前的 git grep 的结果，我们可以很轻松地发现结果的第二行， activesupport/lib/active_support/inflector/methods.rb 在 186 行上。我们正在寻找的方法是这样的：

# Creates a class name from a plural table name like Rails does for table
# names to models. Note that this returns a string and not a Class (To
# convert to an actual class follow +classify+ with constantize).
#
#   classify('ham_and_eggs') # => "HamAndEgg"
#   classify('posts')        # => "Post"
#
# Singular names are not handled correctly:
#
#   classify('calculus')     # => "Calculus"
def classify(table_name)
    # strip out any leading schema name
    camelize(singularize(table_name.to_s.sub(/.*\./, ''.freeze)))
end

酷！考虑到 Rails 仓库的大小，我们借助 git grep 找到它，用时都没有超越 30 秒。

那么，最后的变更是什么？

现在，我们已经找到了所要找的方法，现在，我们需要搞清楚这个文件所经历的变更。由于我们已经知道了正确的文件名和行数，我们可以使用 git blame。这个命令展示了一个文件中每一行的最后修订者和修订的内容。我们来看一下这个文件最后的修订都做了什么：

git blame activesupport/lib/active_support/inflector/methods.rb

虽然我们得到了这个文件每一行的最后的变更，但是，我们更感兴趣的是对特定方法（176 到 189 行）的最后变更。让我们在 git blame 命令上增加一个选项，让它只显示那些行的变化。此外，我们将在命令上增加一个 -s （忽略）选项，去跳过那一行变更时的作者名字和修订（提交）的时间戳：

git blame -L 176,189 -s activesupport/lib/active_support/inflector/methods.rb

9fe8e19a 176)   #Creates a class name from a plural table name like Rails does for table
5ea3f284 177)   # names to models. Note that this returns a string and not a Class (To
9fe8e19a 178)   # convert to an actual class follow +classify+ with #constantize).
51cd6bb8 179)   #
6d077205 180)   #   classify('ham_and_eggs') # => "HamAndEgg"
9fe8e19a 181)   #   classify('posts')        # => "Post"
51cd6bb8 182)   #
51cd6bb8 183)   # Singular names are not handled correctly:
5ea3f284 184)   #
66d6e7be 185)   #   classify('calculus')     # => "Calculus"
51cd6bb8 186)   def classify(table_name)
51cd6bb8 187)     # strip out any leading schema name
5bb1d4d2 188)     camelize(singularize(table_name.to_s.sub(/.*\./, ''.freeze)))
51cd6bb8 189)     end

现在，git blame 命令的输出展示了指定行的全部内容以及它们各自的修订。让我们来看一下指定的修订，换句话说就是，每个变更都修订了什么，我们可以使用 git show 命令。当指定一个修订哈希（像 66d6e7be）作为一个参数时，它将展示这个修订的全部内容。包括作者名字、时间戳以及完整的修订内容。我们来看一下 188 行最后的修订都做了什么？

git show 5bb1d4d2

你亲自做实验了吗？如果没有做，我直接告诉你结果，这个令人惊叹的 提交 是由 Schneems 完成的，他通过使用 frozen 字符串做了一个非常有趣的性能优化，这在我们当前的场景中是非常有意义的。但是，由于我们在这个假设的调试会话中，这样做并不能告诉我们当前问题所在。因此，我们怎么样才能够通过研究来发现，我们选定的方法经过了哪些变更？

搜索日志

现在，我们回到 git 日志，现在的问题是，怎么能够看到 classify 方法经历了哪些修订？

git log 命令非常强大，因此它提供了非常多的列表选项。我们尝试使用 -p 选项去看一下保存了这个文件的 git 日志内容，这个选项的意思是在 git 日志中显示这个文件的完整补丁:

git log -p activesupport/lib/active_support/inflector/methods.rb

这将给我们展示一个很长的修订列表，显示了对这个文件的每个修订。但是，正如下面所显示的，我们感兴趣的是对指定行的修订。对命令做一个小的修改，只显示我们希望的内容：

git log -L 176,189:activesupport/lib/active_support/inflector/methods.rb

git log 命令接受 -L 选项，它用一个行的范围和文件名做为参数。它的格式可能有点奇怪，格式解释如下：

git log -L <start-line>,<end-line>:<path-to-file>

当我们运行这个命令之后，我们可以看到对这些行的一个修订列表，它将带我们找到创建这个方法的第一个修订：

commit 51xd6bb829c418c5fbf75de1dfbb177233b1b154
Author: Foo Bar <[email protected]>
Date:   Tue Jun 7 19:05:09 2011 -0700

    Refactor

diff--git a/activesupport/lib/active_support/inflector/methods.rb b/activesupport/lib/active_support/inflector/methods.rb
--- a/activesupport/lib/active_support/inflector/methods.rb
+++ b/activesupport/lib/active_support/inflector/methods.rb
@@ -58,0 +135,14 @@
+    # Create a class name from a plural table name like Rails does for table names to models.
+    # Note that this returns a string and not a Class. (To convert to an actual class
+    # follow +classify+ with +constantize+.)
+    #
+    # Examples:
+    #   "egg_and_hams".classify # => "EggAndHam"
+    #   "posts".classify        # => "Post"
+    #
+    # Singular names are not handled correctly:
+    #   "business".classify     # => "Busines"
+    def classify(table_name)
+      # strip out any leading schema name
+      camelize(singularize(table_name.to_s.sub(/.*\./, '')))
+    end

现在，我们再来看一下 —— 它是在 2011 年提交的。git 可以让我们重回到这个时间。这是一个很好的例子，它充分说明了足够的提交信息对于重新了解当时的上下文环境是多么的重要，因为从这个提交信息中，我们并不能获得足够的信息来重新理解当时的创建这个方法的上下文环境，但是，话说回来，你不应该对此感到恼怒，因为，你看到的这些项目，它们的作者都是无偿提供他们的工作时间和精力来做开源工作的。（向开源项目贡献者致敬！）

回到我们的正题，我们并不能确认 classify 方法最初实现是怎么回事，考虑到这个第一次的提交只是一个重构。现在，如果你认为，“或许、有可能、这个方法不在 176 行到 189 行的范围之内，那么就你应该在这个文件中扩大搜索范围”，这样想是对的。我们看到在它的修订提交的信息中提到了“重构”这个词，它意味着这个方法可能在那个文件中是真实存在的，而且是在重构之后它才存在于那个行的范围内。

但是，我们如何去确认这一点呢？不管你信不信，git 可以再次帮助你。git log 命令有一个 -S 选项，它可以传递一个特定的字符串作为参数，然后去查找代码变更（添加或者删除）。也就是说，如果我们执行 git log -S classify 这样的命令，我们可以看到所有包含 classify 字符串的变更行的提交。

如果你在 Ralis 仓库上运行上述命令，首先你会发现这个命令运行有点慢。但是，你应该会发现 git 实际上解析了在那个仓库中的所有修订来匹配这个字符串，其实它的运行速度是非常快的。在你的指尖下 git 再次展示了它的强大之处。因此，如果去找关于 classify 方法的第一个修订，我们可以运行如下的命令：

git log -S 'def classify'

它将返回所有这个方法的引用和修改的地方。如果你一直往下看，你将看到日志中它的最后的提交：

commit db045dbbf60b53dbe013ef25554fd013baf88134
Author: David Heinemeier Hansson <[email protected]>
Date:   Wed Nov 24 01:04:44 2004 +0000
    Initial
    git-svn-id: http://svn-commit.rubyonrails.org/rails/trunk@4 5ecf4fe2-1ee6-0310-87b1-e25e094e27de

很酷！是吧？它初次被提交到 Rails，是由 DHH 在一个 svn 仓库上做的！这意味着 classify 大概在一开始就被提交到了 Rails 仓库。现在，我们去看一下这个提交的所有变更信息，我们运行如下的命令：

git show db045dbbf60b53dbe013ef25554fd013baf88134

非常好！我们终于找到它的根源了。现在，我们使用 git log -S 'def classify' 的输出，结合 git log -L 命令来跟踪这个方法都发生了哪些变更。

下次见

当然，我们并没有真的去修改任何 bug，因为我们只是去尝试使用一些 git 命令，来演示如何查看 classify 方法的演变历史。但是不管怎样，git 是一个非常强大的工具，我们必须学好它、用好它。我希望这篇文章可以帮助你掌握更多的关于如何使用 git 的知识。

你喜欢这些内容吗？

作者简介：

后端工程师，对 Ruby、Go、微服务、构建弹性架构来解决大规模部署带来的挑战很感兴趣。我在阿姆斯特丹的 Rails Girls 担任顾问，维护着一个小而精的列表，并且经常为开源做贡献。

那个列表是我写的关于软件开发、编程语言以及任何我感兴趣的东西。

via: https://ieftimov.com/learn-your-tools-navigating-git-history

作者：Ilija Eftimov 译者：qhwdw 校对：wxy

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