在本文里，我们来了解几个能帮你在日常工作中舒服地用上 Git 的工具。

我是在这许多漂亮界面出来之前学习的 Git，而且我的日常工作经常是基于字符界面的，所以 Git 本身自带的大部分功能已经足够我用了。在我看来，最好能理解 Git 的工作原理。不过，能有的选也不错，下面这些就是能让你不用终端就可以开始使用 Git 的一些方式。

KDE Dolphin 里的 Git

我是一个 KDE 用户，如果不在 Plasma 桌面环境下，就是在 Fluxbox 的应用层。Dolphin 是一个非常优秀的文件管理器，有很多配置项以及大量秘密小功能。大家为它开发的插件都特别好用，其中一个几乎就是完整的 Git 界面。是的，你可以直接在自己的桌面上很方便地管理你的 Git 仓库。

但首先，你得先确认已经安装了这个插件。有些发行版带的 KDE 将各种插件都装的满满的，而有些只装了一些最基本的，所以如果你在下面的步骤里没有看到 Git 相关选项，就在你的软件仓库里找找类似 dolphin-extras 或者 dolphin-plugins 的包。

要打开 Git 集成功能，在 Dolphin 的任一窗口里点击 Settings 菜单，并选择 Configure Dolphin。

在弹出的 Configure Dolphin 窗口里，点击左边侧栏里的 Services 图标。

在 Services 面板里，滚动可用的插件列表找到 Git。

（勾选上它，）然后保存你的改动并关闭 Dolphin 窗口。重新启动 Dolphin，浏览一个 Git 仓库试试看。你会发现现在所有文件图标都带有标记：绿色方框表示已经提交的文件，绿色实心方块表示文件有改动，没加入库里的文件没有标记，等等。

之后你在 Git 仓库目录下点击鼠标右键弹出的菜单里就会有 Git 选项了。你在 Dolphin 窗口里点击鼠标就可以检出一个版本，推送或提交改动，还可以对文件进行 git add 或 git remove 操作。

不过 Dolphin 不支持克隆仓库或是改变远端仓库路径，需要到终端窗口操作，按下 F4 就可以很方便地进行切换。

坦白地说，KDE 的这个功能太牛了，这篇文章已经可以到此为止。将 Git 集成到原生文件管理器里可以让 Git 操作非常清晰；不管你在工作流程的哪个阶段，一切都能直接地摆在面前。在终端里 Git，切换到 GUI 后也是一样 Git。完美。

不过别急，还有好多呢！

Sparkleshare

SparkleShare 来自桌面环境的另一大阵营，由一些 GNOME 开发人员发起，一个使用文件同步模型 (“就像 Dropbox 一样!”) 的项目。不过它并没有集成任何 GNOME 特有的组件，所以你可以在任何平台使用。

如果你在用 Linux，可以从你的软件仓库直接安装 SparkleShare。如果是其它操作系统，可以去 SparkleShare 网站下载。你可以不用看 SparkleShare 网站上的指引，那个是告诉你如何架设 SparkleShare 服务器的，不是我们这里讨论的。当然你想的话也可以架设 SparkleShare 服务器，但是 SparkleShare 能兼容 Git 仓库，所以其实没必要再架一个自己的。

在安装完成后，从应用程序菜单里启动 SparkleShare。走一遍设置向导，只有两个步骤外加一个简单介绍，然后可以选择是否将 SparkleShare 设置为随桌面自动启动。

之后在你的系统托盘里会出现一个橙色的 SparkleShare 目录。目前，SparkleShare 对你电脑上的任何东西都一无所知，所以你需要添加一个项目。

要添加一个目录给 SparkleShare 追踪，可以点击系统托盘里的 SparkleShare 图标然后选择 Add Hosted Project。

SparkleShare 支持本地 Git 项目，也可以是存放在像 GitHub 和 Bitbucket 这样的公共 Git 服务器上的项目。要获得完整访问权限，你可能会需要使用 SparkleShare 生成的客户端 ID。这是一个 SSH 密钥，作为你所用到服务的授权令牌，包括你自己的 Git 服务器，应该也使用 SSH 公钥认证而不是用户名密码。将客户端 ID 拷贝到你服务器上 Git 用户的 authorized_hosts 文件里，或者是你的 Git 主机的 SSH 密钥面板里。

在配置要你要用的主机后，SparkleShare 会下载整个 Git 项目，包括（你可以自己选择）提交历史。可以在 ~/SparkleShare 目录下找到同步完成的文件。

不像 Dolphin 那样的集成方式，SparkleShare 是不透明的，让人心里没底。在你做出改动后，它会悄悄地把改动同步到服务器远端项目中。对大部分人来说，这样做有一个很大的好处：可以用到 Git 的全部威力但是不用维护。对我来说，这样有些乱，因为我想自己管理我的提交以及要用的分支。

SparkleShare 可能不适合所有人，但是它是一个强大而且简单的 Git 解决方案，展示了不同的开源项目完美地协调整合到一起后所创造出的独特项目。

Git-cola

另一种配合 Git 仓库工作的模型，没那么原生，更多的是监视方式；不是使用一个集成的应用程序和你的 Git 项目直接交互，而是你可以使用一个桌面客户端来监视项目改动，并随意处理每一个改动。这种方式的一个优势就是专注。当你实际只用到项目里的三个文件的时候，你可能不会关心所有的 125 个文件，能将这三个文件挑出来就很方便了。

如果你觉得有好多 Git 托管网站，那只是你还不知道 Git 客户端有多少。桌面上的 Git 客户端 上有一大把。实际上，Git 默认自带一个图形客户端。它们中最跨平台、最可配置的就是开源的 Git-cola 客户端，用 Python 和 Qt 写的。

如果你在用 Linux，Git-cola 应该在你的软件仓库里就有。不是的话，可以直接从它的网站下载并安装：

$ python setup.py install

启动 git-cola 后，会有三个按钮用来打开仓库，创建新仓库，或克隆仓库。

不管选哪个，最终都会停在一个 Git 仓库中。和大多数我用过的客户端一样，Git-cola 不会尝试成为你的仓库的接口；它们一般会让操作系统工具来做这个。换句话说，我可以通过 Git-cola 创建一个仓库，但随后我就在 Thunar 或 Emacs 里打开仓库开始工作。打开 Git-cola 来监视仓库很不错，因为当你创建新文件，或者改动文件的时候，它们都会出现在 Git-cola 的状态面板里。

Git-cola 的默认布局不是线性的。我喜欢从左向右分布，因为 Git-cola 是高度可配置的，所以你可以随便修改布局。我自己设置成最左边是状态面板，显示当前分支的任何改动，然后右边是差异面板，可以浏览当前改动，然后是动作面板，放一些常用任务的快速按钮，最后，最右边是提交面板，可以写提交信息。

不管怎么改布局，下面是 Git-cola 的通用流程：

改动会出现在状态面板里。右键点击一个改动或选中一个文件，然后在动作面板里点击 Stage 按钮来将文件加入待提交暂存区。

待提交文件的图标会变成绿色三角形，表示该文件有改动并且正等待提交。你也可以右键点击并选择 Unstage Selected 将改动移出待提交暂存区，或者点击动作面板里的 Unstage 按钮。

在差异面板里检查你的改动。

当准备好提交后，输入提交信息并点击 Commit 按钮。

在动作面板里还有其它按钮用来处理其它普通任务，比如拉取或推送。菜单里有更多的任务列表，比如用于操作分支，改动审查，变基等等的专用操作。

我更愿意将 Git-cola 当作文件管理器的一个浮动面板（在不能用 Dolphin 的时候我只用 Git-cola）。虽然它的交互性没有完全集成 Git 的文件管理器那么强，但另一方面，它几乎提供了原始 Git 命令的所有功能，所以它实际上更为强大。

有很多 Git 图形客户端。有些是不提供源代码的付费软件，有些只是用来查看，有些尝试加入新的特定术语（用 "sync" 替代 "push" ...?) 来重造 Git，也有一些只适合特定的平台。Git-cola 一直是能在任意平台上使用的最简单的客户端，也是最贴近纯粹 Git 命令的，可以让用户在使用过程中学习 Git，即便是高手也会很满意它的界面和术语。

Git 命令还是图形界面？

我一般不用图形工具来操作 Git；一般我使用上面介绍的工具时，只是帮助其他人找出适合他们的界面。不过，最终归结于怎么适合你的工作。我喜欢基于终端的 Git 命令是因为它可以很好地集成到 Emacs 里，但如果某天我几乎都在用 Inkscape 工作时，我一般会很自然地使用 Dolphin 里带的 Git，因为我在 Dolphin 环境里。

如何使用 Git 你可以自己选择；但要记住 Git 是一种让生活更轻松的方式，也是让你在工作中更安全地尝试一些疯狂点子的方法。熟悉 Git 的工作模式，然后不管以什么方式使用 Git，只要能让你觉得最适合就可以。

在下一期文章里，我们将了解如何架设和管理 Git 服务器，包括用户权限和管理，以及运行定制脚本。

via: https://opensource.com/life/16/8/graphical-tools-git

作者：Seth Kenlon 译者：zpl1025 校对：wxy

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

在这篇文章中，你将学到如何查看项目中的历史版本，如何进行版本回退，以及如何创建 Git 分支以便你可以大胆尝试而不会出现问题。

在你的 Git 项目的历史中，你的位置就像是摇滚专辑中的一个片段，由一个被称为 HEAD 的 标记来确定（如磁带录音机或录音播放器的播放头）。要在你的 Git 时间线上前后移动 HEAD ，需要使用 git checkout 命令。

git checkout 命令的使用方式有两种。最常见的用途是从一个以前的提交中恢复文件，你也可以整个倒回磁带，切换到另一个分支。

恢复一个文件

当你意识到一个本来很好文件被你完全改乱了。我们都这么干过：我们把文件放到一个地方，添加并提交，然后我们发现它还需要做点最后的调整，最后这个文件被搞得面目全非了。

要把它恢复到最后的完好状态，使用 git checkout 从最后的提交（即 HEAD）中恢复：

$ git checkout HEAD filename

如果你碰巧提交了一个错误的版本，你需要找回更早的版本，使用 git log 查看你更早的提交，然后从合适的提交中找回它：

$ git log --oneline
79a4e5f bad take
f449007 The second commit
55df4c2 My great project, first commit.

$ git checkout 55df4c2 filename

现在，以前的文件恢复到了你当前的位置。（任何时候你都可以用 git status 命令查看你的当前状态）因为这个文件改变了，你需要添加这个文件，再进行提交：

$ git add filename
$ git commit -m 'restoring filename from first commit.'

使用 git log 验证你所提交的：

$ git log --oneline
d512580 restoring filename from first commit
79a4e5f bad take
f449007 The second commit
55df4c2 My great project, first commit.

从本质上讲，你已经倒好了磁带并修复了坏的地方，所以你需要重新录制正确的。

回退时间线

恢复文件的另一种方式是回退整个 Git 项目。这里使用了分支的思想，这是另一种替代方法。

如果你要回到历史提交，你要将 Git HEAD 回退到以前的版本才行。这个例子将回到最初的提交处：

$ git log --oneline
d512580 restoring filename from first commit
79a4e5f bad take
f449007 The second commit
55df4c2 My great project, first commit.

$ git checkout 55df4c2

当你以这种方式倒回磁带，如果你按下录音键再次开始，就会丢失以前的工作。Git 默认假定你不想这样做，所以将 HEAD 从项目中分离出来，可以让你如所需的那样工作，而不会因为偶尔的记录而影响之后的工作。

如果你想看看以前的版本，想要重新做或者尝试不同的方法，那么安全一点的方式就是创建一个新的分支。可以将这个过程想象为尝试同一首歌曲的不同版本，或者创建一个混音的。原始的依然存在，关闭那个分支做你想做的版本吧。

就像记录到一个空白磁带一样，把你的 Git HEAD 指到一个新的分支处：

$ git checkout -b remix
Switched to a new branch 'remix'

现在你已经切换到了另一个分支，在你面前的是一个替代的干净工作区，准备开始工作吧。

也可以不用改变时间线来做同样的事情。也许你很想这么做，但切换到一个临时的工作区只是为了尝试一些疯狂的想法。这在工作中完全是可以接受的，请看：

$ git status
On branch master
nothing to commit, working directory clean

$ git checkout -b crazy_idea
Switched to a new branch 'crazy_idea'

现在你有一个干净的工作空间，在这里你可以完成一些奇怪的想法。一旦你完成了，可以保留你的改变，或者丢弃他们，并切换回你的主分支。

若要放弃你的想法，切换到你的主分支，假装新分支不存在：

$ git checkout master

想要继续使用你的疯狂的想法，需要把它们拉回到主分支，切换到主分支然后合并新分支到主分支：

$ git checkout master
$ git merge crazy_idea

git 的分支功能很强大，开发人员在克隆仓库后马上创建一个新分支是很常见的做法；这样，他们所有的工作都在自己的分支上，可以提交并合并到主分支。Git 是很灵活的，所以没有“正确”或“错误”的方式（甚至一个主分支也可以与其所属的远程仓库分离），但分支易于分离任务和提交贡献。不要太激动，你可以如你所愿的有很多的 Git 分支。完全自由。

远程协作

到目前为止你已经在自己舒适而私密的家中维护着一个 Git 仓库，但如何与其他人协同工作呢？

有好几种不同的方式来设置 Git 以便让多人可以同时在一个项目上工作，所以首先我们要克隆仓库，你可能已经从某人的 Git 服务器或 GitHub 主页，或在局域网中的共享存储上克隆了一个仓库。

工作在私人仓库下和共享仓库下唯一不同的是你需要把你的改变 push 到别人的仓库。我们把工作的仓库称之为 本地 （ local ） 仓库，其他仓库称为 远程 （ remote ） 仓库。

当你以读写的方式克隆一个仓库时，克隆的仓库会继承自被称为 origin 的远程库。你可以看看你的克隆仓库的远程仓库：

$ git remote --verbose
origin  [email protected]:~/myproject.Git (fetch)
origin  [email protected]:~/myproject.Git (push)

有一个 origin 远程库非常有用，因为它有异地备份的功能，并允许其他人在该项目上工作。

如果克隆没有继承 origin 远程库，或者如果你选择以后再添加，可以使用 git remote 命令：

$ git remote add [email protected]:~/myproject.Git

如果你修改了文件，想把它们发到有读写权限的 origin 远程库，使用 git push。第一次推送改变，必须也发送分支信息。不直接在主分支上工作是一个很好的做法，除非你被要求这样做：

$ git checkout -b seth-dev
$ git add exciting-new-file.txt
$ git commit -m 'first push to remote'
$ git push -u origin HEAD

它会推送你当前的位置（HEAD）及其存在的分支到远程。当推送过一次后，以后每次推送可以不使用 -u 选项：

$ git add another-file.txt
$ git commit -m 'another push to remote'
$ git push origin HEAD

合并分支

当你工作在一个 Git 仓库时，你可以合并任意测试分支到主分支。当团队协作时，你可能想在将它们合并到主分支之前检查他们的改变：

$ git checkout contributor
$ git pull
$ less blah.txt  ### 检查改变的文件
$ git checkout master
$ git merge contributor

如果你正在使用 GitHub 或 GitLab 以及类似的东西，这个过程是不同的。但克隆项目并把它作为你自己的仓库都是相似的。你可以在本地工作，将改变提交到你的 GitHub 或 GitLab 帐户，而不用其它人的许可，因为这些库是你自己的。

如果你想要让你克隆的仓库接受你的改变，需要创建了一个 拉取请求 （ pull request ） ，它使用 Web 服务的后端发送补丁到真正的拥有者，并允许他们审查和拉取你的改变。

克隆一个项目通常是在 Web 服务端完成的，它和使用 Git 命令来管理项目是类似的，甚至推送的过程也是。然后它返回到 Web 服务打开一个拉取请求，工作就完成了。

下一部分我们将整合一些有用的插件到 Git 中来帮你轻松的完成日常工作。

via: https://opensource.com/life/16/7/how-restore-older-file-versions-git

作者：Seth Kenlon 译者：strugglingyouth 校对：wxy

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

现在是时候学习怎样创建你自己的 Git 仓库了，还有怎样增加文件和完成提交。

在本系列前面的文章中，你已经学习了怎样作为一个最终用户与 Git 进行交互；你就像一个漫无目的的流浪者一样偶然发现了一个开源项目网站，克隆了仓库，然后你就可以继续钻研它了。你知道了和 Git 进行交互并不像你想的那样困难，或许你只是需要被说服现在去使用 Git 完成你的工作罢了。

虽然 Git 确实是被许多重要软件选作版本控制工具，但是并不是仅能用于这些重要软件；它也能管理你购物清单（如果它们对你来说很重要的话，当然可以了！）、你的配置文件、周报或日记、项目进展日志、甚至源代码！

使用 Git 是很有必要的，毕竟，你肯定有过因为一个备份文件不能够辨认出版本信息而抓狂的时候。

Git 无法帮助你，除非你开始使用它，而现在就是开始学习和使用它的最好时机。或者，用 Git 的话来说，“没有其他的 push 能像 origin HEAD 一样有帮助了”（千里之行始于足下的意思）。我保证，你很快就会理解这一点的。

类比于录音

我们经常用名词“快照”来指代计算机上的镜像，因为很多人都能够对插满了不同时光的照片的相册充满了感受。这很有用，不过，我认为 Git 更像是进行一场录音。

也许你不太熟悉传统的录音棚卡座式录音机，它包括几个部件：一个可以正转或反转的转轴、保存声音波形的磁带，可以通过拾音头在磁带上记录声音波形，或者检测到磁带上的声音波形并播放给听众。

除了往前播放磁带，你也可以把磁带倒回到之前的部分，或快进跳过后面的部分。

想象一下上世纪 70 年代乐队录制磁带的情形。你可以想象到他们一遍遍地练习歌曲，直到所有部分都非常完美，然后记录到音轨上。起初，你会录下鼓声，然后是低音，再然后是吉他声，最后是主唱。每次你录音时，录音棚工作人员都会把磁带倒带，然后进入循环模式，这样它就会播放你之前录制的部分。比如说如果你正在录制低音，你就会在背景音乐里听到鼓声，就像你自己在击鼓一样，然后吉他手在录制时会听到鼓声、低音（和牛铃声）等等。在每个循环中，你都会录制一部分，在接下来的循环中，工作人员就会按下录音按钮将其合并记录到磁带中。

你也可以拷贝或换下整个磁带，如果你要对你的作品重新混音的话。

现在我希望对于上述的上世纪 70 年代的录音工作的描述足够生动，这样我们就可以把 Git 的工作想象成一个录音工作了。

新建一个 Git 仓库

首先得为我们的虚拟的录音机买一些磁带。用 Git 的话说，这些磁带就是仓库；它是完成所有工作的基础，也就是说这里是存放 Git 文件的地方（即 Git 工作区）。

任何目录都可以成为一个 Git 仓库，但是让我们从一个新目录开始。这需要下面三个命令：

• 创建目录（如果你喜欢的话，你可以在你的图形化的文件管理器里面完成。）
• 在终端里切换到目录。
• 将其初始化成一个 Git 管理的目录。

也就是运行如下代码：

$ mkdir ~/jupiter  # 创建目录
$ cd ~/jupiter     # 进入目录
$ git init .       # 初始化你的新 Git 工作区

在这个例子中，文件夹 jupiter 是一个空的但是合法的 Git 仓库。

有了仓库接下来的事情就可以按部就班进行了。你可以克隆该仓库，你可以在一个历史点前后来回穿梭（前提是你有一个历史点），创建交替的时间线，以及做 Git 能做的其它任何事情。

在 Git 仓库里面工作和在任何目录里面工作都是一样的，可以在仓库中新建文件、复制文件、保存文件。你可以像平常一样做各种事情；Git 并不复杂，除非你把它想复杂了。

在本地的 Git 仓库中，一个文件可以有以下这三种状态：

• 未跟踪文件 （ Untracked ） ：你在仓库里新建了一个文件，但是你没有把文件加入到 Git 的管理之中。
• 已跟踪文件 （ Tracked ） ：已经加入到 Git 管理的文件。
• 暂存区文件 （ Staged ） ：被修改了的已跟踪文件，并加入到 Git 的提交队列中。

任何你新加入到 Git 仓库中的文件都是未跟踪文件。这些文件保存在你的电脑硬盘上，但是你没有告诉 Git 这是需要管理的文件，用我们的录音机来类比，就是录音机还没打开；乐队就开始在录音棚里忙碌了，但是录音机并没有准备录音。

不用担心，Git 会在出现这种情况时告诉你：

$ echo "hello world" > foo
$ git status
On branch master
Untracked files:
(use "git add <file>..." to include in what will be committed)    
    foo    
nothing added but untracked files present (use "git add" to track)

你看到了，Git 会提醒你怎样把文件加入到提交任务中。

不使用 Git 命令进行 Git 操作

在 GitHub 或 GitLab 上创建一个仓库只需要用鼠标点几下即可。这并不难，你单击“New Repository”这个按钮然后跟着提示做就可以了。

在仓库中包括一个“README”文件是一个好习惯，这样人们在浏览你的仓库的时候就可以知道你的仓库是干什么的，更有用的是可以让你在克隆一个有东西的仓库前知道它有些什么。

克隆仓库通常很简单，但是在 GitHub 上获取仓库改动权限就稍微复杂一些，为了通过 GitHub 验证你必须有一个 SSH 密钥。如果你使用 Linux 系统，可以通过下面的命令生成：

$ ssh-keygen

然后复制你的新密钥的内容，它是纯文本文件，你可以使用一个文本编辑器打开它，也可以使用如下 cat 命令查看：

$ cat ~/.ssh/id_rsa.pub

现在把你的密钥粘贴到 GitHub SSH 配置文件 中，或者 GitLab 配置文件。

如果你通过使用 SSH 模式克隆了你的项目，你就可以将修改写回到你的仓库了。

另外，如果你的系统上没有安装 Git 的话也可以使用 GitHub 的文件上传接口来添加文件。

跟踪文件

正如命令 git status 的输出告诉你的那样，如果你想让 git 跟踪一个文件，你必须使用命令 git add 把它加入到提交任务中。这个命令把文件存在了暂存区，这里存放的都是等待提交的文件，或者也可以用在快照中。在将文件包括到快照中，和添加要 Git 管理的新的或临时文件时，git add 命令的目的是不同的，不过至少现在，你不用为它们之间的不同之处而费神。

类比录音机，这个动作就像打开录音机开始准备录音一样。你可以想象为对已经在录音的录音机按下暂停按钮，或者倒回开头等着记录下个音轨。

当你把文件添加到 Git 管理中，它会标识其为已跟踪文件：

$ git add foo
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file:   foo

加入文件到提交任务中并不是“准备录音”。这仅仅是将该文件置于准备录音的状态。在你添加文件后，你仍然可以修改该文件；它只是被标记为已跟踪和处于暂存区，所以在它被写到“磁带”前你可以将它撤出或修改它（当然你也可以再次将它加入来做些修改）。但是请注意：你还没有在磁带中记录该文件，所以如果弄坏了一个之前还是好的文件，你是没有办法恢复的，因为你没有在“磁带”中记下那个文件还是好着的时刻。

如果你最后决定不把文件记录到 Git 历史列表中，那么你可以撤销提交任务，在 Git 中是这样做的：

$ git reset HEAD foo

这实际上就是解除了录音机的准备录音状态，你只是在录音棚中转了一圈而已。

大型提交

有时候，你想要提交一些内容到仓库；我们以录音机类比，这就好比按下录音键然后记录到磁带中一样。

在一个项目所经历的不同阶段中，你会按下这个“记录键”无数次。比如，如果你尝试了一个新的 Python 工具包并且最终实现了窗口呈现功能，然后你肯定要进行提交，以便你在实验新的显示选项时搞砸了可以回退到这个阶段。但是如果你在 Inkscape 中画了一些图形草样，在提交前你可能需要等到已经有了一些要开发的内容。尽管你可能提交了很多次，但是 Git 并不会浪费很多，也不会占用太多磁盘空间，所以在我看来，提交的越多越好。

commit 命令会“记录”仓库中所有的暂存区文件。Git 只“记录”已跟踪的文件，即，在过去某个时间点你使用 git add 命令加入到暂存区的所有文件，以及从上次提交后被改动的文件。如果之前没有过提交，那么所有跟踪的文件都包含在这次提交中，以 Git 的角度来看，这是一次非常重要的修改，因为它们从没放到仓库中变成了放进去。

完成一次提交需要运行下面的命令：

$ git commit -m 'My great project, first commit.'

这就保存了所有提交的文件，之后可以用于其它操作（或者，用英国电视剧《神秘博士》中时间领主所讲的 Gallifreyan 语说，它们成为了“固定的时间点” ）。这不仅是一个提交事件，也是一个你在 Git 日志中找到该提交的引用指针：

$ git log --oneline
55df4c2 My great project, first commit.

如果想浏览更多信息，只需要使用不带 --oneline 选项的 git log 命令。

在这个例子中提交时的引用号码是 55df4c2。它被叫做“ 提交哈希 （ commit hash ） ”（LCTT 译注：这是一个 SHA-1 算法生成的哈希码，用于表示一个 git 提交对象），它代表着刚才你的提交所包含的所有新改动，覆盖到了先前的记录上。如果你想要“倒回”到你的提交历史点上，就可以用这个哈希作为依据。

你可以把这个哈希想象成一个声音磁带上的 SMPTE 时间码，或者再形象一点，这就是好比一个黑胶唱片上两首不同的歌之间的空隙，或是一个 CD 上的音轨编号。

当你改动了文件之后并且把它们加入到提交任务中，最终完成提交，这就会生成新的提交哈希，它们每一个所标示的历史点都代表着你的产品不同的版本。

这就是 Charlie Brown 这样的音乐家们为什么用 Git 作为版本控制系统的原因。

在接下来的文章中，我们将会讨论关于 Git HEAD 的各个方面，我们会真正地向你揭示时间旅行的秘密。不用担心，你只需要继续读下去就行了（或许你已经在读了？）。

via: https://opensource.com/life/16/7/creating-your-first-git-repository

作者：Seth Kenlon 译者：vim-kakali 校对：wxy

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

在这个系列的介绍篇中，我们学习到了谁应该使用 Git，以及 Git 是用来做什么的。今天，我们将学习如何克隆公共 Git 仓库，以及如何提取出独立的文件而不用克隆整个仓库。

由于 Git 如此流行，因而如果你能够至少熟悉一些基础的 Git 知识也能为你的生活带来很多便捷。如果你可以掌握 Git 基础（你可以的，我发誓！），那么你将能够下载任何你需要的东西，甚至还可能做一些贡献作为回馈。毕竟，那就是开源的精髓所在：你拥有获取你使用的软件代码的权利，拥有和他人分享的自由，以及只要你愿意就可以修改它的权利。只要你熟悉了 Git，它就可以让这一切都变得很容易。

那么，让我们一起来熟悉 Git 吧。

读和写

一般来说，有两种方法可以和 Git 仓库交互：你可以从仓库中读取，或者你也能够向仓库中写入。它就像一个文件：有时候你打开一个文档只是为了阅读它，而其它时候你打开文档是因为你需要做些改动。

本文仅讲解如何从 Git 仓库读取。我们将会在后面的一篇文章中讲解如何向 Git 仓库写回的主题。

Git 还是 GitHub？

一句话澄清：Git 不同于 GitHub（或 GitLab，或 Bitbucket）。Git 是一个命令行程序，所以它就像下面这样：

$ git
usage: Git [--version] [--help] [-C <path>] 
  [-p | --paginate | --no-pager] [--bare]
  [--Git-dir=<path>] <command> [<args>]

由于 Git 是开源的，所以就有许多聪明人围绕它构建了基础软件；这些基础软件，包括在他们自己身边，都已经变得非常流行了。

我的文章系列将首先教你纯粹的 Git 知识，因为一旦你理解了 Git 在做什么，那么你就无需关心正在使用的前端工具是什么了。然而，我的文章系列也将涵盖通过流行的 Git 服务完成每项任务的常用方法，因为那些将可能是你首先会遇到的。

安装 Git

在 Linux 系统上，你可以从所使用的发行版软件仓库中获取并安装 Git。BSD 用户应当在 Ports 树的 devel 部分查找 Git。

对于闭源的操作系统，请前往其项目官网，并根据说明安装。一旦安装后，在 Linux、BSD 和 Mac OS X 上的命令应当没有任何差别。Windows 用户需要调整 Git 命令，从而和 Windows 文件系统相匹配，或者安装 Cygwin 以原生的方式运行 Git，而不受 Windows 文件系统转换问题的羁绊。

Git 下午茶

并非每个人都需要立刻将 Git 加入到我们的日常生活中。有些时候，你和 Git 最多的交互就是访问一个代码库，下载一两个文件，然后就不用它了。以这样的方式看待 Git，它更像是下午茶而非一次正式的宴会。你进行一些礼节性的交谈，获得了需要的信息，然后你就会离开，至少接下来的三个月你不再想这样说话。

当然，那是可以的。

一般来说，有两种方法访问 Git：使用命令行，或者使用一种神奇的因特网技术通过 web 浏览器快速轻松地访问。

假设你想要给终端安装一个回收站，因为你已经被 rm 命令毁掉太多次了。你可能听说过 Trashy ，它称自己为「理智的 rm 命令中间人」，也许你想在安装它之前阅读它的文档。幸运的是，Trashy 公开地托管在 GitLab.com。

Landgrab

我们工作的第一步是对这个 Git 仓库使用 landgrab 排序方法：我们会克隆这个完整的仓库，然后会根据内容排序。由于该仓库是托管在公共的 Git 服务平台上，所以有两种方式来完成工作：使用命令行，或者使用 web 界面。

要想使用 Git 获取整个仓库，就要使用 git clone 命令和 Git 仓库的 URL 作为参数。如果你不清楚正确的 URL 是什么，仓库应该会告诉你的。GitLab 为你提供了 Trashy 仓库的用于拷贝粘贴的 URL。

你也许注意到了，在某些服务平台上，会同时提供 SSH 和 HTTPS 链接。只有当你拥有仓库的写权限时，你才可以使用 SSH。否则的话，你必须使用 HTTPS URL。

一旦你获得了正确的 URL，克隆仓库是非常容易的。就是 git clone 该 URL 即可，以及一个可选的指定要克隆到的目录。默认情况下会将 git 目录克隆到你当前所在的目录；例如，'trashy.git' 将会克隆到你当前位置的 'trashy' 目录。我使用 .clone 扩展名标记那些只读的仓库，而使用 .git 扩展名标记那些我可以读写的仓库，不过这并不是官方要求的。

$ git clone https://gitlab.com/trashy/trashy.git trashy.clone
Cloning into 'trashy.clone'...
remote: Counting objects: 142, done.
remote: Compressing objects: 100% (91/91), done.
remote: Total 142 (delta 70), reused 103 (delta 47)
Receiving objects: 100% (142/142), 25.99 KiB | 0 bytes/s, done.
Resolving deltas: 100% (70/70), done.
Checking connectivity... done.

一旦成功地克隆了仓库，你就可以像对待你电脑上任何其它目录那样浏览仓库中的文件。

另外一种获得仓库拷贝的方式是使用 web 界面。GitLab 和 GitHub 都会提供一个 .zip 格式的仓库快照文件。GitHub 有一个大大的绿色下载按钮，但是在 GitLab 中，可以在浏览器的右侧找到并不显眼的下载按钮。

仔细挑选

另外一种从 Git 仓库中获取文件的方法是找到你想要的文件，然后把它从仓库中拽出来。只有 web 界面才提供这种方法，本质上来说，你看到的是别人的仓库克隆；你可以把它想象成一个 HTTP 共享目录。

使用这种方法的问题是，你也许会发现某些文件并不存在于原始仓库中，因为完整形式的文件可能只有在执行 make 命令后才能构建，那只有你下载了完整的仓库，阅读了 README 或者 INSTALL 文件，然后运行相关命令之后才会产生。不过，假如你确信文件存在，而你只想进入仓库，获取那个文件，然后离开的话，你就可以那样做。

在 GitLab 和 GitHub 中，单击文件链接，并在 Raw 模式下查看，然后使用你的 web 浏览器的保存功能，例如：在 Firefox 中，“文件” > “保存页面为”。在一个 GitWeb 仓库中（这是一个某些更喜欢自己托管 git 的人使用的私有 git 仓库 web 查看器），Raw 查看链接在文件列表视图中。

最佳实践

通常认为，和 Git 交互的正确方式是克隆完整的 Git 仓库。这样认为是有几个原因的。首先，可以使用 git pull 命令轻松地使克隆仓库保持更新，这样你就不必在每次文件改变时就重回 web 站点获得一份全新的拷贝。第二，你碰巧需要做些改进，只要保持仓库整洁，那么你可以非常轻松地向原来的作者提交所做的变更。

现在，可能是时候练习查找感兴趣的 Git 仓库，然后将它们克隆到你的硬盘中了。只要你了解使用终端的基础知识，那就不会太难做到。还不知道基本的终端使用方式吗？那再给多我 5 分钟时间吧。

终端使用基础

首先要知道的是，所有的文件都有一个路径。这是有道理的；如果我让你在常规的非终端环境下为我打开一个文件，你就要导航到文件在你硬盘的位置，并且直到你找到那个文件，你要浏览一大堆窗口。例如，你也许要点击你的家目录 > 图片 > InktoberSketches > monkey.kra。

在那样的场景下，文件 monkeysketch.kra 的路径是：$HOME/图片/InktoberSketches/monkey.kra。

在终端中，除非你正在处理一些特殊的系统管理员任务，你的文件路径通常是以 $HOME 开头的（或者，如果你很懒，就使用 ~ 字符），后面紧跟着一些列的文件夹直到文件名自身。

这就和你在 GUI 中点击各种图标直到找到相关的文件或文件夹类似。

如果你想把 Git 仓库克隆到你的文档目录，那么你可以打开一个终端然后运行下面的命令：

$ git clone https://gitlab.com/foo/bar.git 
$HOME/文档/bar.clone

一旦克隆完成，你可以打开一个文件管理器窗口，导航到你的文档文件夹，然后你就会发现 bar.clone 目录正在等待着你访问。

如果你想要更高级点，你或许会在以后再次访问那个仓库，可以尝试使用 git pull 命令来查看项目有没有更新：

$ cd $HOME/文档/bar.clone
$ pwd
bar.clone
$ git pull

到目前为止，你需要初步了解的所有终端命令就是那些了，那就去探索吧。你实践得越多，Git 掌握得就越好（熟能生巧），这是重点，也是事情的本质。

via: https://opensource.com/life/16/7/stumbling-git

作者：Seth Kenlon 译者：ChrisLeeGit 校对：wxy

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

欢迎阅读本系列关于如何使用 Git 版本控制系统的教程！通过本文的介绍，你将会了解到 Git 的用途及谁该使用 Git。

如果你刚步入开源的世界，你很有可能会遇到一些在 Git 上托管代码或者发布使用版本的开源软件。事实上，不管你知道与否，你都在使用基于 Git 进行版本管理的软件：Linux 内核（就算你没有在手机或者电脑上使用 Linux，你正在访问的网站也是运行在 Linux 系统上的），Firefox、Chrome 等其他很多项目都通过 Git 代码库和世界各地开发者共享他们的代码。

换个角度来说，你是否仅仅通过 Git 就可以和其他人共享你的代码？你是否可以在家里或者企业里私有化的使用 Git？你必须要通过一个 GitHub 账号来使用 Git 吗？为什么要使用 Git 呢？Git 的优势又是什么？Git 是我唯一的选择吗？这对 Git 所有的疑问都会把我们搞的一脑浆糊。

因此，忘记你以前所知的 Git，让我们重新走进 Git 世界的大门。

什么是版本控制系统？

Git 首先是一个版本控制系统。现在市面上有很多不同的版本控制系统：CVS、SVN、Mercurial、Fossil 当然还有 Git。

很多像 GitHub 和 GitLab 这样的服务是以 Git 为基础的，但是你也可以只使用 Git 而无需使用其他额外的服务。这意味着你可以以私有或者公有的方式来使用 Git。

如果你曾经和其他人有过任何电子文件方面的合作，你就会知道传统版本管理的工作流程。开始是很简单的：你有一个原始的版本，你把这个版本发送给你的同事，他们在接收到的版本上做了些修改，现在你们有两个版本了，然后他们把他们手上修改过的版本发回来给你。你把他们的修改合并到你手上的版本中，现在两个版本又合并成一个最新的版本了。

然后，你修改了你手上最新的版本，同时，你的同事也修改了他们手上合并前的版本。现在你们有 3 个不同的版本了，分别是合并后最新的版本，你修改后的版本，你同事手上继续修改过的版本。至此，你们的版本管理工作开始变得越来越混乱了。

正如 Jason van Gumster 在他的文章中指出 即使是艺术家也需要版本控制，而且已经在个别人那里发现了这种趋势变化。无论是艺术家还是科学家，开发一个某种实验版本是并不鲜见的；在你的项目中，可能有某个版本大获成功，把项目推向一个新的高度，也可能有某个版本惨遭失败。因此，最终你不可避免的会创建出一堆名为project\_justTesting.kdenlive、project\_betterVersion.kdenlive、project\_best\_FINAL.kdenlive、project\_FINAL-alternateVersion.kdenlive 等类似名称的文件。

不管你是修改一个 for 循环，还是一些简单的文本编辑，一个好的版本控制系统都会让我们的生活更加的轻松。

Git 快照

Git 可以为项目创建快照，并且存储这些快照为唯一的版本。

如果你将项目带领到了一个错误的方向上，你可以回退到上一个正确的版本，并且开始尝试另一个可行的方向。

如果你是和别人合作开发，当有人向你发送他们的修改时，你可以将这些修改合并到你的工作分支中，然后你的同事就可以获取到合并后的最新版本，并在此基础上继续工作。

Git 并不是魔法，因此冲突还是会发生的（“你修改了某文件的最后一行，但是我把这行整行都删除了；我们怎样处理这些冲突呢？”），但是总体而言，Git 会为你保留了所有更改的历史版本，甚至允许并行版本。这为你保留了以任何方式处理冲突的能力。

分布式 Git

在不同的机器上为同一个项目工作是一件复杂的事情。因为在你开始工作时，你想要获得项目的最新版本，然后此基础上进行修改，最后向你的同事共享这些改动。传统的方法是通过笨重的在线文件共享服务或者老旧的电邮附件，但是这两种方式都是效率低下且容易出错。

Git 天生是为分布式工作设计的。如果你要参与到某个项目中，你可以 克隆 （ clone ） 该项目的 Git 仓库，然后就像这个项目只有你本地一个版本一样对项目进行修改。最后使用一些简单的命令你就可以 拉取 （ pull ） 其他开发者的修改，或者你可以把你的修改 推送 （ push ） 给别人。现在不用担心谁手上的是最新的版本，或者谁的版本又存放在哪里等这些问题了。全部人都是在本地进行开发，然后向共同的目标推送或者拉取更新。（或者不是共同的目标，这取决于项目的开发方式）。

Git 界面

最原始的 Git 是运行在 Linux 终端上的应用软件。然而，得益于 Git 是开源的，并且拥有良好的设计，世界各地的开发者都可以为 Git 设计不同的访问界面。

Git 完全是免费的，并且已经打包在 Linux，BSD，Illumos 和其他类 Unix 系统中，Git 命令看起来像这样：

$ git --version
git version 2.5.3

可能最著名的 Git 访问界面是基于网页的，像 GitHub、开源的 GitLab、Savannah、BitBucket 和 SourceForge 这些网站都是基于网页端的 Git 界面。这些站点为面向公众和面向社会的开源软件提供了最大限度的代码托管服务。在一定程度上，基于浏览器的图形界面（GUI）可以尽量的减缓 Git 的学习曲线。下面的 GitLab 界面的截图：

再者，第三方 Git 服务提供商或者独立开发者甚至可以在 Git 的基础上开发出不是基于 HTML 的定制化前端界面。此类界面让你可以不用打开浏览器就可以方便的使用 Git 进行版本管理。其中对用户最透明的方式是直接集成到文件管理器中。KDE 文件管理器 Dolphin 可以直接在目录中显示 Git 状态，甚至支持提交，推送和拉取更新操作。

Sparkleshare 使用 Git 作为其 Dropbox 式的文件共享界面的基础。

想了解更多的内容，可以查看 Git wiki，这个（长长的）页面中展示了很多 Git 的图形界面项目。

谁应该使用 Git？

就是你！我们更应该关心的问题是什么时候使用 Git？和用 Git 来干嘛？

我应该在什么时候使用 Git 呢？我要用 Git 来干嘛呢？

想更深入的学习 Git，我们必须比平常考虑更多关于文件格式的问题。

Git 是为了管理源代码而设计的，在大多数编程语言中，源代码就意味者一行行的文本。当然，Git 并不知道你把这些文本当成是源代码还是下一部伟大的美式小说。因此，只要文件内容是以文本构成的，使用 Git 来跟踪和管理其版本就是一个很好的选择了。

但是什么是文本呢？如果你在像 Libre Office 这类办公软件中编辑一些内容，通常并不会产生纯文本内容。因为通常复杂的应用软件都会对原始的文本内容进行一层封装，就如把原始文本内容用 XML 标记语言包装起来，然后封装在 Zip 包中。这种对原始文本内容进行一层封装的做法可以保证当你把文件发送给其他人时，他们可以看到你在办公软件中编辑的内容及特定的文本效果。奇怪的是，虽然，通常你的需求可能会很复杂，就像保存 Kdenlive 项目文件，或者保存从 Inkscape 导出的SVG文件，但是，事实上使用 Git 管理像 XML 文本这样的纯文本类容是最简单的。

如果你在使用 Unix 系统，你可以使用 file 命令来查看文件内容构成：

$ file ~/path/to/my-file.blah
my-file.blah: ASCII text
$ file ~/path/to/different-file.kra: Zip data (MIME type "application/x-krita")

如果还是不确定，你可以使用 head 命令来查看文件内容：

$ head ~/path/to/my-file.blah

如果输出的文本你基本能看懂，这个文件就很有可能是文本文件。如果你仅仅在一堆乱码中偶尔看到几个熟悉的字符，那么这个文件就可能不是文本文件了。

准确的说：Git 可以管理其他格式的文件，但是它会把这些文件当成二进制大对象（blob）。两者的区别是，在文本文件中，Git 可以明确的告诉你在这两个快照（或者说提交）间有 3 行是修改过的。但是如果你在两个 提交 （ commit ） 之间对一张图片进行的编辑操作，Git 会怎么指出这种修改呢？实际上，因为图片并不是以某种可以增加或删除的有意义的文本构成，因此 Git 并不能明确的描述这种变化。当然我个人是非常希望图片的编辑可以像把文本“丑陋的蓝绿色”修改成“漂浮着蓬松白云的天蓝色”一样的简单，但是事实上图片的编辑并没有这么简单。

经常有人在 Git 上放入 png 图标、电子表格或者流程图这类二进制大型对象（blob）。尽管，我们知道在 Git 上管理此类大型文件并不直观，但是，如果你需要使用 Git 来管理此类文件，你也并不需要过多的担心。如果你参与的项目同时生成文本文件和二进制大文件对象（如视频游戏中常见的场景，这些和源代码同样重要的图像和音频材料），那么你有两条路可以走：要么开发出你自己的解决方案，就如使用指向共享网络驱动器的引用；要么使用 Git 插件，如 Joey Hess 开发的 git annex，以及 Git-Media 项目。

你看，Git 真的是一个任何人都可以使用的工具。它是你进行文件版本管理的一个强大而且好用工具，同时它并没有你开始认为的那么可怕。

via: https://opensource.com/resources/what-is-git

作者：Seth Kenlon 译者：cvsher 校对：wxy

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