本文由伯乐在线-听风翻译，艾凌风校稿。 未经许可禁止转载！
英语来源： Red Radger。 欢迎来到翻译组。
本文旨在通过简单易懂的文本来解释版本控制背后的理论，使程序员对如何工作有一个全局的概念。 本文与代码无关，什么都不下载，循序渐进，不关注复杂的细节，只有文字和不太好看的手绘涂鸦。
写这篇文章的动机无论学习什么都能在网上找到这么多指导教程，我一直很惊讶。 Git和Github也不例外。 网上有很多优秀的资源。 引导学生开始学习，考虑这些资源中的一个或两个。 以下是我特别喜欢的几个资源。
tree house设计师入门rogerdudlergit简易教程pluralsightgithub :初学者指南。 但是，我发现这些教程总是跳过许多理论知识，并直接从命令行和github桌面APP应用程序中介绍如何使用git。 老实说，如果你只是想知道开发团队在谈论什么，这些指导教程也绰绰有馀。 综上所述，我的目标是简明扼要地阐述版本控制的总体概念，同时希望大家知道版本控制是这么酷。
从最基本的开始吧，版本控制
image credit : weebletheringskite，WordPress
版本控制：学习它，爱它，享受它。 雅致的路灯、版本控制系统是一个可以了解文件历史及其发展过程的系统。 以前作为平面设计师，我经常遇到这样的文件：
你很眼熟吗？ 这些系统不是易于使用的系统，但它们是版本控制系统。 更复杂的例子是谷歌文档中的“修订历史记录”和Photoshop中的“历史记录”工具。
Git Git是一个版本控制系统，专门用于处理文本文件。 因为，归根结底，这就是代码的本质。 是一堆以某种方式组合在一起的文本文件。 Git是一个可安装的APP应用程序，您可以对自己所做的更改进行注释，并创建便于导航的系统历史记录。
(附：“Git”也是工程师取的名字。 对不起市场部的同事)
那么，Git做了什么呢？ 不能很容易地保存文件吗？ 基本上，文件存储是一个简单的版本控制系统，但坦率地说，这不是一个易于使用的系统，因为它只会向前推进。 当然，您可能会争论“撤消”按钮可以将文件回滚到以前的状态。 但是，最明显的是，“撤消”按钮是有限的，如果关闭文件，文件的过去也会丢失。
此外，保存文件非常个人化。 不能查看整个系统的历史记录，只能查看文件的。 对此，他说：“嗯，我不是工程师。 你可能会想：“没有必要为系统烦恼。” 我想花点时间解释一下，我认为很多事情都不是“系统”，实际上是这样的。
以jjdbb为例，她是写下一部大冒险奇幻小说系列的作家。 jjdbb写完了这个系列小说的第一本书，并把它告诉了她的编辑。 另外，她才华出众，所以一边等待编辑的反馈，一边写了第二本书的前三章。 每个本书都制作了独立的世界文档。
有一个快乐的日子，jjdbb等收到了她的编辑关于第一本书的反馈。 他担心年轻的读者不想读一系列专门讲述橡树故事的书，希望她能在这个故事里引入精灵。 对此，jjdbb叹了口气，但很快就意识到她的精灵新角色会带来意想不到的冲突和曲折的故事。 然后，她做了以下事情：
在第一本书里添加新的角色，修改故事。 第一本书完成后，对第二本书的故事，进行必要的修改。 所有这些修改都要求她在第一本书而不是第二本书中引入地理位置。 重新编辑第一本书以包括新的地理位置。 终于，她确信她推开了键盘，让精灵融入了奇幻的世界。
你看，jjdbb实际上在处理系统。 她的两本书互相影响。 角色、地理位置、故事在两本书里流动交错。 但不幸的是，一个月后，她的文件系统里什么都没有。 Word的“文档历史记录”工具或粘贴在显示屏边缘以记录修改过程的便签纸将汇总所有更改过程。
这就是Git的一大亮点。 如果jjdbb使用Word与Git配合使用，她可以对所有这些相关的变化做一个“将向导部署到系列中”的简短总结。 她可以看到所有的页面、章节、文件以及每本书里的修改记录，让她真正了解了精灵的引入对幻想系列的影响。 这个“简短的总结”就是我们在Git领域谈论的提交(commit )。
让我们回顾一下。 Git是一种软件，通过提交可以对系统(或组)的文件历史进行注释。 这些提交是在给定时间点添加到系统的差异的“快照”。
那么，如果我是jjdbb的话，我的提交履历看起来是这样的：
Github到目前为止，一切都很好。 但是，如果jjdbb同时在两台计算机上工作会怎么样呢？ 问得好。 这个时候应该用Github。 请注意不要和Git混淆。 Github从Git获取提交历史记录并将其存储在互联网上，因此可以从任何计算机访问。 你推送到本机(例如你现在使用的电脑) (p
ushing）提交到 Github，然后，从另一台新的或不同的电脑上拉取（pulling）这些提交。让我们假设上图为 jjdbb 的工作流程。她在家里的台式电脑（左边，橘黄色的）上开启她一天的工作。接下来，她完成了几个章节的写作，又做了一些编辑工作，等等。整个过程中，她对工作总共进行了三次策略性的“快照”（Git 提交）。
下午，jjdbb 常常喜欢带着她的笔记本电脑（上图中的右侧，蓝色的）去咖啡馆写作。今天也不例外。因此，在关闭家里的台式电脑之前，她需要确认当前的Git 提交历史已推送（push）到了在线Github。一旦被上传到 Github，这些提交记录就被存储在远程仓库（remote repository）中。
我们先来分析一下几个计算机术语：远程（remote）仅仅意味着联网（与“本地”的意思相反，和之前我们理解到的意思一样的，代表当前正在使用的电脑）。而仓库（repository，经常简写为“repo”），就是一个具备 Git 超级权限的文件夹。
因此，Github 就是让你把工作（通过Git提交进行注解）存储在了一个指定的在线文件夹（repo）。明白了吧？简单。
午餐之后，在当地的一家咖啡馆中，jjdbb 拿出了她的笔记本电脑。很明显，她想接着家里的工作进度继续。因些，她从 Github 仓库上获取到最新进度的工作。“从 Github 上获取她的工作”，这一过程就叫拉取（pulling）。再看一下上面这幅图片，你将看到 jjdbb 拉取了之前她在家时进行的三个提交。
现在，在她的笔记本电脑上，jjdbb 有整个系统（包含她的幻想系列的所有文本文件）的最新的完整副本，并能够基于上次的进度，继续工作。她写了更多的章节，对工作进行了两次以上的策略“快照”（提交）。最后，jjdbb 把这些提交推送（push）到 Github 上，结束了这一天的工作。这样第二天上午的时候，在家里的台式电脑上就可以取得这些最新进度的工作。
协同工作好吧，这一切都能说得通。但是， jjdbb再如何酷，整个项目也只有她一人而已。工程团队要如何确保他们的工作不会重叠？
简而言之，创建分支。将你的 Git 提交历史想像成一棵树。树的主干就是我们谈到的主分支。为了让团队成员避免彼此牵扯，他们在独立于他人的隔离区（在一个功能分支）进行工作，然而最终，每个人的工作成果都会被提交到主代码库 （主分支）。
现在，回到 jjdbb 的例子。她加入了奇幻作家协会，在这里每个人都与他人合作完成这本书——《奇幻系列生物辞典》。这本辞典更像一本教材，由多个作者共同完成：jjdbb、Tom 和 Adam。
让我们来看看《奇幻系列生物辞典》项目的在线 Github 仓库，现在的情况是：
如上图所示，树的类比完全适用于奇幻作家协会在这个项目上的合作情况，仓库历史沿主分支向上移动。常规工作流始于每个作者为完成一个工作任务（例如编写章节内容，或排版章节）而在主分支上创建分支。只有当更改得到其他合作作家的批准时，分支才会被合并到主分支上（请谨记，主分支上的内容，才是最终要发布的内容）。
当一个分支的内容合并（merged）到主分支时，意味着该分支的内容会覆盖主分支上的。因此，现有内容的任何更改都将会替代之前的。当然，任何新添加的内容也会添加到主分支。实际上，当分支合并到主分支时，该分支的提交历史被添加到主分支提交历史的顶部。
然而，你可能正在思考：人们在本机的工作和之后才推送到 Github 的工作变更是如何连接到一起的呢？
关于这个问题，重点在于：你在 Github 的远程仓库是你本机工作项目的一个镜像。这意味着，你在自己的电脑里存储了该项目（例如：一个已设置可进行 Git 提交的文件夹）的本地 Git 仓库。在这个本地的 Git 仓库（再次，这是一个特定术语，指你的电脑里某个启用了 Git 功能的文件夹）中，你拥有与该项目相关的所有文件，在本文的例子中，即《奇幻系列生物辞典》。
它的工作原理很像 Dropbox ：你在不同的设备（你的家庭电脑、办公室电脑，等等）上创建本地文件夹，进行工作并更新这些文件。最后，这些操作被同步到网络上。然而，我们知道，Git/Github 工作流还包含了一些额外的步骤。首先，你必须有意识地对某一时刻的工作执行“快照”（即执行一次提交）。然后，你必须特意地推送这些提交（push） 到 Github。只有这样，你的工作才被同步到网络上的位置（Github 版本库）。
既然如此，为什么不自动化该工作流呢？为什么不让它像 Dropbox一样，难过的板栗更新本地文件时，同时自动更新 Github 上的文件？有很多理由让我们不这么做。最主要的理由是——bugs 。同出版界一样，软件工程中也不是所有写过的东西都要保留。有时，你希望实验一下你的想法，如果实验失败，你希望有一种简单的方式能让工作快速回滚到之前的正确状态上。这也是为什么我们提倡这个经验法则，即在你试图用不同的方法编辑或实验之前，先对当前你希望保留的修改进行提交。频繁地提交小块工作有益无害，事实上，许多工程师为自己能做到这一点而感到自豪。
现在，回到《奇幻系列生物辞典》。由于 jjdbb 对兽族有较深的了解，她被挑选为写兽族章节。但她不想在没有经过其它合作人员允许的情况下去修改这本书，于是，她创建了一个本地分支，并在该分支上进行写作和提交。然后，她将本地分支推送到 Github。像往常一样，Github 的远程仓库是本地库的一个镜像，最新进展显示 jjdbb 已创建了一个包含部分提交的分支（如下图所示）。
随着她对本章节的持续写作，jjdbb 进行了更多的提交，并将它们推送到 Github 的在线镜像分支。终于，她准备请 Tom 和 Adam 一起对她的工作进行评审。因此，她在 Github 上发布了一个 Pull Request（发布请求），这是一个 Github 功能，允许她解释该分支相对于主分支做了哪些修改。Github 还提供了一个简易平台，合作人员可以在该平台上针对分支的修改内容进行讨论，并要求 jjdbb 在分支合并到主分支之前对一些有异议的内容进行修改。
在对部分内容请求修改后，如上图所示，Tom 和 Adam 对 jjdbb 的分支内容很满意，并决定将她的工作成果合并到 Github 的主分支上。此时，他们所要做的就是将 jjdbb 之前独立提交的内容，添加到主分支的提交历史顶部：
此时，jjdbb可以切换（或“check out”）到本地计算机上的主分支，并将先前在功能分支（兽人章节分支）中的独立提交拉取下来。现在她又要在新的主分支上重新开始了：以该主分支为基础为她的下一步工作创建一个新的本地分支，帮助懦弱的蜜蜂编辑有关妖精的章节。因此，这一过程又将重复:
创建本地分支在本地分支上编辑修改，然后提交推送提交（Push）到 Github 创建发布请求（Pull Request），说明该分支包含了哪些更改合并（Merge）分支内容到主分支将主分支上的最新提交拉取（pull）到本地重复上述步骤正如你所看到的，这是一个非常流畅的工作流，完美地结合了独立工作与团队协作。你本机的 Git 提供了一个绝妙的方法，即通过由你自己控制和策划的丰富的历史提交，来创建你工作的各种版本。Github 是一个非常棒的在线版本控制工具，不仅存储和提供了清晰的可视化历史记录，而且还能进行协同工作和质量控制。
总而言之，我希望我已经说服你去尝试使用 Git 和 Github 进行任何项目。没有理由只有工程师能从这个很棒的工具中受益。毕竟，我们也想看到更多有关兽人的故事。
致谢：非常感谢 Common Craft 对本文的涂鸦和解释风格的启发。还要感谢这个视频《 saving me from the horror of having to explain Twitter to my mum 》。
本文涉及的术语 Version Control（版本控制）: 任何一个能够让你了解文件的历史，以及该文件的发展进程的系统。Git：一个版本控制程序，通过对变更进行注释，以创建一个易于遍历的系统历史。Commit（提交）：在指定时间点对系统差异进行的注释 “快照”。Local（本地）：指任意时刻工作时正在使用的电脑。Remote（远程）： 指某个联网的位置。Repository (仓库，简称 repo)：配置了Git超级权限的特定文件夹，包含了你的项目或系统相关的所有文件。Github：获取本地提交历史记录，并进行远程存储，以便你可以从任何计算机访问这些记录。Pushing（推送）：取得本地Git提交（以及相关的所有工作），然后将其上传到在线Github。Pulling（拉取）：从在线的Github上获取最新的提交记录，然后合并到本地电脑上。Master (branch)：主分支，提交历史 “树”的 “树干”，包含所有已审核的内容/代码。Feature branch（功能分支/特性分支）：一个基于主分支的独立的位置，在再次并入到主分支之前，你可以在这里安全地写工作中的新任务。Pull Request（发布请求）：一个 Github 工具，允许用户轻松地查看某功能分支的更改 （the difference或 “diff”），同时允许用户在该分支合并到主分支之前对其进行讨论和调整。Merging（合并）：该操作指获取功能分支的提交，加入到主分支提交历史的顶部。Checking out（切换）：该操作指从一个分支切换到另一个分支。做产品的程序，才是好的程序员！