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

最原始的 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 来干嘛?

想更深入的学习 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 并不能明确的描述这种变化。当然我个人是非常希望图片的编辑可以像把文本“<sky>丑陋的蓝绿色</sky>”修改成“<sky>漂浮着蓬松白云的天蓝色</sky>”一样的简单，但是事实上图片的编辑并没有这么简单。

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

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