欢迎来到我的 Git 版本控制系统学习系列!在本系列介绍中,您将了解 Git 的用途以及哪些人应该使用它。
阅读
- 第 1 部分:什么是 Git?
- 第 2 部分:Git 入门
- 第 3 部分:创建您的第一个 Git 仓库
- 第 4 部分:如何在 Git 中恢复旧版本文件
- 第 5 部分:3 个 Git 图形化工具
- 第 6 部分:如何构建自己的 Git 服务器
- 第 7 部分:如何使用 Git 管理二进制大对象
另一方面,关于 Git 的所有兴奋和炒作往往使事情变得有点混乱。您只能使用 Git 与他人共享您的代码吗?或者您可以在自己家中或企业的隐私环境中使用 Git 吗?您必须拥有 GitHub 帐户才能使用 Git 吗?为什么要使用 Git?Git 的好处是什么?Git 是唯一的选择吗?
所以,忘掉您知道的或您认为您知道的关于 Git 的一切,让我们从头开始。
什么是版本控制?
Git 首先是一个版本控制系统 (VCS)。市面上有许多版本控制系统:CVS、SVN、Mercurial、Fossil,当然还有 Git。
Git 是许多服务的基础,例如 GitHub 和 GitLab,但您可以使用 Git 而无需使用任何其他服务。这意味着您可以私下或公开使用 Git。
如果您曾经与任何人合作处理过任何数字内容,那么您就知道它是如何进行的。一开始很简单:您有您的版本,然后将其发送给您的合作伙伴。他们做出一些更改,所以现在有两个版本,并将建议发回给您。您将他们的更改整合到您的版本中,现在又只有一个版本了。
然后情况变得更糟:当您进一步更改您的版本时,您的合作伙伴对他们的版本进行了更多更改。现在您有三个版本;您和您的合作伙伴共同处理的合并副本、您更改的版本以及您的合作伙伴更改的版本。
正如 Jason van Gumster 在他的文章《即使艺术家也需要版本控制》中指出的那样,这种综合症也往往发生在个人环境中。在艺术和科学领域,开发一个事物的试验版本并不罕见;您项目的版本可能会使其变得更好,或者可能会彻底失败。因此,您创建诸如 project_justTesting.kdenlive 和 project_betterVersion.kdenlive,然后是 project_best_FINAL.kdenlive 之类的文件名,但不可避免地允许 project_FINAL-alternateVersion.kdenlive,等等。
无论是 for 循环的更改还是编辑更改,这种情况都会发生在最好的我们身上。这就是一个好的版本控制系统使生活更轻松的地方。
Git 快照
Git 会拍摄项目的快照,并将这些快照存储为唯一版本。
如果您在项目中朝着您认为错误的方向前进,您可以回滚到最后一个良好版本,并沿着另一条路径继续前进。
[下载我们的 Git 速查表]
如果您正在协作,那么当有人向您发送更改时,您可以将这些更改合并到您的工作分支中,然后您的协作者可以获取项目的合并版本并从新的当前版本继续工作。
Git 不是魔法,因此冲突确实会发生(“您更改了书的最后一行,但我完全删除了该行;我们如何解决这个问题?”),但总的来说,Git 使您能够管理单个作品的许多潜在变体,保留所有更改的历史记录,甚至允许并行版本。
Git 分布式
在不同的机器上处理项目很复杂,因为您希望在工作时拥有项目的最新版本,进行自己的更改,并与您的协作者共享您的更改。这样做的默认方法往往是笨拙的在线文件共享服务,或者老式的电子邮件附件,这两种方法效率低下且容易出错。
Git 专为分布式开发而设计。如果您参与一个项目,您可以克隆该项目的 Git 仓库,然后像它是唯一存在的副本一样进行处理。然后,使用几个简单的命令,您可以从其他贡献者那里拉取任何更改,也可以将您的更改推送到其他人。现在,关于谁拥有哪个版本的项目,或者谁的更改存在于何处,不再有困惑。这一切都是本地开发的,并朝着一个共同的目标推送和拉取(或者不推送和拉取,取决于项目选择如何开发)。
Git 界面
在自然状态下,Git 是一个在 Linux 终端中运行的应用程序。然而,由于其设计良好且是开源的,世界各地的开发人员都设计了其他访问它的方式。
它是免费的,任何人都可以以 0 美元的价格获得,并且以软件包的形式出现在 Linux、BSD、Illumos 和其他类 Unix 操作系统上。它看起来像这样
$ git --version
git version 2.5.3
可能最著名的 Git 界面是基于 Web 的:像 GitHub、开源的 GitLab、Savannah、BitBucket 和 SourceForge 这样的网站都提供在线代码托管,以最大限度地发挥开源的公共和社交方面,并以不同程度提供基于浏览器的 GUI,以最大限度地降低使用 Git 的学习曲线。这就是 GitLab 界面的样子
此外,Git 服务或独立开发人员甚至可能拥有非基于 HTML 的自定义 Git 前端,如果您不希望浏览器永远打开,这将特别方便。最透明的集成以文件管理器支持的形式出现。KDE 文件管理器 Dolphin 可以显示目录的 Git 状态,甚至可以生成提交、推送和拉取。
Sparkleshare 使用 Git 作为其自己的 Dropbox 风格文件共享界面的基础。
欲了解更多信息,请参阅官方 Git wiki 上列出具有 Git 图形界面的项目的(长)页面。
哪些人应该使用 Git?
您应该使用!真正的问题是何时?以及用于什么?
我应该何时使用 Git,以及我应该将其用于什么?
为了充分利用 Git,您需要比平常更多地考虑文件格式。
Git 旨在管理源代码,在大多数语言中,源代码由文本行组成。当然,Git 不知道您是在向其馈送源代码还是下一部伟大的美国小说,因此只要它分解为文本,Git 就是管理和跟踪版本的绝佳选择。
但是什么是文本?如果您在像 Libre Office 这样的办公应用程序中编写内容,那么您可能不会生成原始文本。通常在复杂的应用程序周围有一个包装器,它将原始文本封装在 XML 标记中,然后再封装在 zip 容器中,以此确保当您将该文件发送给其他人时,您的 Office 文件的所有资产都可用。然而,奇怪的是,您可能期望非常复杂的东西,例如 Kdenlive 项目的保存文件,或来自 Inkscape 的 SVG,实际上是原始 XML 文件,可以轻松地由 Git 管理。
如果您使用 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 可以管理其他格式的文件,但它将它们视为 blobs。区别在于,在文本文件中,两个 Git 快照(或我们称之为提交)可能彼此相差三行。如果您有一张照片在两个不同的提交之间被修改过,Git 如何表达这种变化?它实际上无法表达,因为照片不是由任何可以简单插入或删除的合理文本组成的。我希望照片编辑就像将文本从“<sky>ugly greenish-blue</sky>”更改为“<sky>blue-with-fluffy-clouds</sky>”一样容易,但事实并非如此。
人们一直将 blobs(例如 PNG 图标、电子表格或流程图)签入 Git,因此如果您正在 Git 中工作,请不要害怕这样做。但要知道,对大文件这样做是不明智的。如果您正在处理的项目确实生成文本文件和大型 blobs(视频游戏的一个常见场景,视频游戏在源代码与图形和音频资产方面是均等的),那么您可以做两件事之一:要么发明您自己的解决方案,例如指向共享网络驱动器的指针,要么使用像 Joey Hess 出色的 git annex 或 Git-Media 项目这样的 Git 附加组件。
所以您看,Git 真的适合所有人。它是管理文件版本的好方法,它是一个强大的工具,而且它并不像最初看起来那么可怕。
12 条评论