zhong—ForFuture

for a better future!no fear more!

Git和GitHub

本文旨在使用通俗易懂的文字,讲解版本控制背后的理论,以便你能对程序员们如何工作有个全局概念。本文不涉及代码,不用下载啥东西,循序渐进,不关注繁复细节,只有文字和一些不怎么漂亮的手绘涂鸦。来源于:大白话解释 Git 和 GitHub

写本文的动机

学习任何东西都能在网络上找到如此之多的指导教程,这一直令我惊讶不已。Git 和 Github 也不例外,网络上有大量优秀资源,这些资源要么只对其中一个,要么兼顾二者引导你开始学习。以下是我特别喜欢的一些资源:

然而,我发现这些教程总是跳过许多理论知识,直接解释如何通过命令行或 Github 桌面应用程序使用 Git 。坦白说,如果你只是想知道你的开发团队谈论的到底是什么,这些指导教程也绰绰有余了。如上所述,我的目标是对版本控制的整体概念进行简明扼要地讲解,同时希望能让你了解到版本控制是如此酷。

让我们从最基础的开始:版本控制

                                                 

Image credit: weebletheringskite, WordPress

版本控制(Version control):学习它,爱上它,享受它。顾名思义,版本控制系统是任何能让你了解到一个文件的历史,以及它的发展过程的系统。之前作为平面设计师时,我常常会遇到这种文件:

看起来眼熟?尽管上述系统不是一个好用的系统 ,但它确实是一个版本控制系统。更复杂点的例子就像,Google 文档的 “修订历史”或  Photoshop 的“历史”工具。

  Git

Git 是一种专为处理文本文件而设计的版本控制系统。因为,归根到底,这就是代码的本质:一堆堆以某种方式联合在一起的文本文件。Git 是一个可安装应用,它允许你对你自己所做的更改进行注释,用以创建易于导航的系统历史。

(附: “Git”  也是工程师取的名字,我们对市场部同仁感到抱歉)

那么, Git 做了什么,是简单地保存文件所做不到的呢?从根本上讲,文件保存就是一个简化的版本控制系统,但坦率地说,它并不是一个好用的系统,因为它只能前进。当然,你也许会争论“撤消”按钮可以让你的文件回滚到以前的状态。但我们都清楚,“撤消”按钮有其局限性,最明显示的是,在关闭文件时,文件的过去也随之丢失。

另外,文件保存是非常个人化的。它不能够显示整个系统的历史,只能够显示该文件的。针对这一点,你可能会想,“嗯,我不是一个工程师,我不需要为系统烦恼”。我愿意花些时间来解释一下,很多事情你认为不是“系统”,而实际上它们就是。

以  Sally为例,她是一个正在写下一个大冒险奇幻小说系列的作家。Sally 已经写完该系列小说中的第一本,并把它传给了她的编辑。此外,由于她才华出众,在等待编辑的反馈的同时,她还写了第二本书的前三章。每本书都建立了独立的 World 文件。

在某个快乐的日子,Sally  等来了她的编辑关于第一本书的反馈。他担心年轻的读者不想读一系列专写兽人故事的书,希望她在这个故事中引入一些精灵。关于这点,Sally  叹了口气,但很快意识到,她的精灵新角色将带来始料未及的冲突和曲折的情节。然后,她做了以下事情:

  • 在第一本书中加入新角色,并修改故事情节。
  • 完成第一本书之后,对第二本书的故事情节,进行必要的修改。
  • 所有的这些修改,导致她需要引入某个地理位置到第一本书中,而不是第二本书。
  • 重新编辑第一本书,让它包含新的地理位置。

终于,她推开了她的键盘,确信已经把精灵融入到了她的奇幻世界之中。

你瞧,Sally 实际上在处理一个系统。她的两本书互相影响。角色、地理位置和故事情节在两本书中流动交织。然而,遗憾的是,一个月后,她的文件系统里什么都没有了。Word 的 “文档历史”工具,或她曾经粘贴在显示屏边缘用于记录修改过程的便签纸,将把所有的变化过程都揉合在一起。

这正是Git 大放光芒之处。如果 Sally 一直结合 Git 使用Word,她就能对所有这些相关的变化做一个关于“将精灵引入到系列”的简洁小结。她可以看到所有穿插在页、章节、文件,以及每本书中的修改记录,让她真正地了解引入精灵对她的奇幻系列产生的影响。这个“简洁的小结”就是我们在 Git 领域中所讲的提交(commit)

回顾一下。 Git 是一个软件,它允许你通过提交对一个系统(或一组)文件的历史进行注释。这些提交便是在给定时间点对系统做出的差异“快照”。

那么,如果我是Sally,我的提交历史看起来是这样子的:


Github

到目前为止,一切都还不错。但是,如果 Sally 同时用到两台电脑工作,将会发生什么呢?问得好。这时,就该用到 Github了。注意,不要和 Git 混淆了。Github 获取 Git 中的提交历史,并将其存储在互联网上,因此你可以从任一一台电脑访问它。你在本机(例如:你当前正在使用的电脑)推送(pushing)提交到 Github,然后,从另一台新的或不同的电脑上拉取(pulling)这些提交。

让我们假设上图为 Sally 的工作流程。她在家里的台式电脑(左边,橘黄色的)上开启她一天的工作。接下来,她完成了几个章节的写作,又做了一些编辑工作,等等。整个过程中,她对工作总共进行了三次策略性的“快照”(Git 提交)。

下午,Sally 常常喜欢带着她的笔记本电脑(上图中的右侧,蓝色的)去咖啡馆写作。今天也不例外。因此,在关闭家里的台式电脑之前,她需要确认当前的Git 提交历史已推送(push)到了在线Github。一旦被上传到 Github,这些提交记录就被存储在远程仓库(remote repository)中。

我们先来分析一下几个计算机术语:远程(remote)仅仅意味着联网(与“本地”的意思相反,和之前我们理解到的意思一样的,代表当前正在使用的电脑)。而仓库(repository,经常简写为“repo”),就是一个具备 Git 超级权限的文件夹。

因此,Github 就是让你把工作(通过Git提交进行注解)存储在了一个指定的在线文件夹(repo)。明白了吧?简单。

午餐之后,在当地的一家咖啡馆中,Sally 拿出了她的笔记本电脑。很明显,她想接着家里的工作进度继续。因些,她从 Github 仓库上获取到最新进度的工作。“从 Github 上获取她的工作”,这一过程就叫拉取(pulling)。再看一下上面这幅图片,你将看到 Sally 拉取了之前她在家时进行的三个提交。

现在,在她的笔记本电脑上,Sally 有整个系统(包含她的幻想系列的所有文本文件)的最新的完整副本,并能够基于上次的进度,继续工作。她写了更多的章节,对工作进行了两次以上的策略“快照”(提交)。最后,Sally 把这些提交推送push)到 Github 上,结束了这一天的工作。这样第二天上午的时候,在家里的台式电脑上就可以取得这些最新进度的工作。

协同工作

好吧,这一切都能说得通。但是, Sally再如何酷,整个项目也只有她一人而已。工程团队要如何确保他们的工作不会重叠?

简而言之,创建分支。将你的 Git 提交历史想像成一棵树。树的主干就是我们谈到的主分支。为了让团队成员避免彼此牵扯,他们在独立于他人的隔离区(在一个功能分支)进行工作,然而最终,每个人的工作成果都会被提交到主代码库 (主分支)。

现在,回到 Sally 的例子。她加入了奇幻作家协会,在这里每个人都与他人合作完成这本书——《奇幻系列生物辞典》。这本辞典更像一本教材,由多个作者共同完成:Sally、Tom 和 Adam。

让我们来看看《奇幻系列生物辞典》项目的在线 Github 仓库,现在的情况是:

如上图所示,树的类比完全适用于奇幻作家协会在这个项目上的合作情况,仓库历史沿主分支向上移动。常规工作流始于每个作者为完成一个工作任务(例如编写章节内容,或排版章节)而在主分支上创建分支。只有当更改得到其他合作作家的批准时,分支才会被合并到主分支上(请谨记,主分支上的内容,才是最终要发布的内容)。

当一个分支的内容合并(merged)到主分支时,意味着该分支的内容会覆盖主分支上的。因此,现有内容的任何更改都将会替代之前的。当然,任何新添加的内容也会添加到主分支。实际上,当分支合并到主分支时,该分支的提交历史被添加到主分支提交历史的顶部。

然而,你可能正在思考:人们在本机的工作和之后才推送到 Github 的工作变更是如何连接到一起的呢?

关于这个问题,重点在于:你在 Github 的远程仓库是你本机工作项目的一个镜像。这意味着,你在自己的电脑里存储了该项目(例如:一个已设置可进行 Git 提交的文件夹)的本地 Git 仓库。在这个本地的 Git 仓库(再次,这是一个特定术语,指你的电脑里某个启用了 Git 功能的文件夹)中,你拥有与该项目相关的所有文件,在本文的例子中,即《奇幻系列生物辞典》。

它的工作原理很像 Dropbox :你在不同的设备(你的家庭电脑、办公室电脑,等等)上创建本地文件夹,进行工作并更新这些文件。最后,这些操作被同步到网络上。然而,我们知道,Git/Github 工作流还包含了一些额外的步骤。首先,你必须有意识地对某一时刻的工作执行“快照”(即执行一次提交)。然后,你必须特意地推送这些提交(push) 到 Github。只有这样,你的工作才被同步到网络上的位置(Github 版本库)。

既然如此,为什么不自动化该工作流呢?为什么不让它像 Dropbox一样,当你更新本地文件时,同时自动更新 Github 上的文件?有很多理由让我们不这么做。最主要的理由是——bugs 。同出版界一样,软件工程中也不是所有写过的东西都要保留。有时,你希望实验一下你的想法,如果实验失败,你希望有一种简单的方式能让工作快速回滚到之前的正确状态上。这也是为什么我们提倡这个经验法则,即在你试图用不同的方法编辑或实验之前,先对当前你希望保留的修改进行提交。频繁地提交小块工作有益无害,事实上,许多工程师为自己能做到这一点而感到自豪。

现在,回到《奇幻系列生物辞典》。由于  Sally 对兽族有较深的了解,她被挑选为写兽族章节。但她不想在没有经过其它合作人员允许的情况下去修改这本书,于是,她创建了一个本地分支,并在该分支上进行写作和提交。然后,她将本地分支推送到 Github。像往常一样,Github 的远程仓库是本地库的一个镜像,最新进展显示 Sally 已创建了一个包含部分提交的分支(如下图所示)。

随着她对本章节的持续写作,Sally 进行了更多的提交,并将它们推送到 Github 的在线镜像分支。终于,她准备请 Tom 和 Adam 一起对她的工作进行评审。因此,她在 Github 上发布了一个 Pull Request(发布请求),这是一个 Github 功能,允许她解释该分支相对于主分支做了哪些修改。Github 还提供了一个简易平台,合作人员可以在该平台上针对分支的修改内容进行讨论,并要求 Sally 在分支合并到主分支之前对一些有异议的内容进行修改。

在对部分内容请求修改后,如上图所示,Tom 和 Adam 对 Sally 的分支内容很满意,并决定将她的工作成果合并到 Github 的主分支上。此时,他们所要做的就是将 Sally 之前独立提交的内容,添加到主分支的提交历史顶部:

此时,Sally可以切换(或“check out”)到本地计算机上的主分支,并将先前在功能分支(兽人章节分支)中的独立提交拉取下来。现在她又要在新的主分支上重新开始了:以该主分支为基础为她的下一步工作创建一个新的本地分支,帮助汤姆编辑有关妖精的章节。因此,这一过程又将重复:

  1. 创建本地分支
  2. 在本地分支上编辑修改,然后提交
  3. 推送提交(Push)到 Github
  4.  创建发布请求(Pull Request),说明该分支包含了哪些更改
  5. 合并(Merge)分支内容到主分支
  6. 将主分支上的最新提交拉取(pull)到本地
  7. 重复上述步骤

正如你所看到的,这是一个非常流畅的工作流,完美地结合了独立工作与团队协作。你本机的 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(切换):该操作指从一个分支切换到另一个分支。
阅读更多
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/ganquanzhong/article/details/80330588
文章标签: Git GitHub
个人分类: Git
想对作者说点什么? 我来说一句

git github github入门使用教程.doc

2017年12月08日 448KB 下载

windows下的git安装包

2014年04月14日 15.05MB 下载

GitGitHub使用教程

2017年09月27日 16.65MB 下载

git操作文档

2018年01月25日 1.47MB 下载

GitGitHub使用

2016年09月14日 1.62MB 下载

Git for windows 10 64

2017年12月11日 31.1MB 下载

GitGitHub教程

2017年03月13日 9.04MB 下载

Github 漫游指南

2016年01月05日 2.27MB 下载

GitGitHub教程 2017-03-21

2017年03月21日 12.33MB 下载

没有更多推荐了,返回首页

不良信息举报

Git和GitHub

最多只允许输入30个字

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭