GitHub入门与实践

欢迎来到GitHub的世界~

本文同步发表于TonnyL的简书, 知乎专栏

GitHub入门与实践(一) - 欢迎来到GitHub的世界

1.1 什么是GitHub

GitHub是一个同性交友社区,不好意思,拿错剧本了。GitHubWikipedia上的介绍是这样的:

GitHub是一个通过Git进行版本控制的软件源代码托管服务,由GitHub公司(曾称Logical Awesome)的开发者Chris Wanstrath、PJ Hyett和Tom Preston-Werner使用Ruby on Rails编写而成。

简单来说,GitHub是一个让开发者与他人共享代码的地方。其公司总部位于美国加利福利亚州旧金山,其logo是一只名为Octocat的可爱章鱼猫,就是下面的这个小萌萌了↓

Octocat

当然,她还有可能是这样的🙃
Octocat

1.2 GitHub与Git有什么区别

Git其实是一种版本控制的协议,定义了一个版本控制的各种操作,类似的还有SVN/CVS,但是和SVN/CVS不同的是,Git采用的是分布式的方式,并不需要服务器端的软件。

而GitHub是基于Git协议的一个网络代码仓库,也就是说,GitHub上公开的软件源代码都是有Git进行管理,但是GitHub除了提供Git仓库的托管服务外,还为开发者或团队提供了一系列的功能(后面会详细说明),例如在线浏览、搜索和管理、社交等等,帮助开发者和团队高效率、高品质的编写代码。

(好吧,说了这么多拗口的话,简单来说,你可以将Git与GitHub的关系理解为「魔兽争霸」和「对战平台」的关系。)

1.3 GitHub的使用情况

截止到2015年,GitHub已经有超过九百万注册用户和2110万代码库。事实上已经成为了世界上最大的代码存放网站和开源社区。全世界每时每刻都有开发者在使用它。

1.4 GitHub提供的主要功能

  • Git仓库

    一般情况下,当我们注册了GitHub账户之后,我们免费新建任意个GitHub提供的Git仓库。如果需要建立只对特定用户或自己公开的私有仓库,则需要按照Plans for all workflows支付每月最低7美元的费用。
    Plans for all workflows

  • Organization

    通常情况下,如果只是个人使用,个人账户就足够了。但如果是团队或者公司,建议使用Organization账户,它可以统一管理账户和权限,同时也能统一支付一些费用。

    和个人账户类似,如果只是创建公开仓库,创建Organization账户是不收费的。因此,对于小型开发团队而言,Organization或许是个不错的选择。
    Organization

    下面是Google Organization账户信息:
    Google Organization Account

  • Issue

    Issue用于对有一个任务或问题进行追踪和管理。这有点类似于BUG管理系统(例如Mozilla公司出品的Bugzilla)。在GitHub上,我们每次创建一个Pull Request时,都会要求创建一个Issue。

    每次将要对功能进行更改或者修正时,都应该创建一个Issue(除非是有特殊的原因,最好使用英文,如果使用中文,项目所有者还需要耗费时间和精力替你翻译,而这本是你应该完成的事物),讨论或者修正都围绕这个Issue为中心进行。只要查看Issue,就能了解和这个更改有关的信息,并以此进行管理。

    在Git的提交信息中写上Issue的ID(例如「#7」),GitHub就会自动生成从Issue到对应提交的链接。另外,只要按照特定的格式描述提交信息,还可以关闭Issue。

    下面是google-gson项目的一个Issue。

    ps:请不要在Issue中讨论和项目无关的内容(例如灌水、无意义的聊天等),也不要连着发帖,因为你每发布一次无意义的内容,项目的作者和关注(Watch)这个项目的人就会收到一封垃圾邮件。所以,请共同维护GitHub的良好氛围。

  • Wiki

    通过Wiki功能,任何人都可以随时对一篇文章进行更改并保存,因此可以多人共同完成一篇文章。该功能常用于在开发文档或手册的编写中。

    Wiki也是作为Git仓库进行管理的,改进的历史记录也会被切实保存,使用者可以放心的改写,并且支持克隆到本地进行编辑。

    这是开源大户square的项目okhttp的wiki首页:
    [okhttp wiki](https://github.com/square/okhttp/wiki)

  • Pull Request

    当我们fork了别人的代码,并做了相应的修改之后,就可以Pull Request向仓库的所有者提出申请,请求对方合并自己修改之后的代码。发出Pull Request之后,对方的管理人员可以查看Pull Request的内容及其中包含的代码更改。

    同时,你可以利用GitHub提供的对Pull Request和源代码差别评论的功能,以行为单位对代码进行讨论。

    square的另外一个项目retrofitPull Request:
    [Pull Request](https://github.com/square/retrofit/pulls)

  • Gist

    有时候我们并不需要为了一个小小的代码片段而开启一个仓库,这个时候Gist就派上用场了。Gist是一个有趣的服务,最简单的功能就是分享代码片段,但她的功能并不局限于此,Gist并不仅仅为开发者服务,任何人(允许匿名)都可以利用她分享内容。

  • GitHub Pages

    GitHub Pages 是免费的静态空间服务,可以架设静态网站,包括静态博客。我们可以利用GitHub Pages搭配Hexo或者Jekyll等静态博客系统搭建我们自己的博客。

    这是我利用GitHub Pages和Hexo搭配的博客:
    https://tonnyl.github.io/

1.5 GitHub上的一些知名项目

  • Linux - Linux kernel source tree.(43k star, 无穷个贡献者)
  • Git
  • node - Node.js JavaScript runtime.
  • rails - Ruby on Rails.

1.6 彩蛋

[GitHub](https://github.com/TonnyL)

GitHub,同性交友,真人约会,排解寂寞,释放压力。百分百真人,谁没事会去注册GitHub啊,通过“Follow”交到同性好友;通过Issue和PR互动和交流。So, f**k, oh no, follow me on GitHub。

GitHub入门与实践(二) - Git的导入

Git仓库管理功能是GitHub的核心。因此,在使用GitHub之前必须先掌握Git的使用方法。

2.1 诞生背景

Git属于分散型版本管理系统,是为版本管理而设计的软件。

Linux的创始人Linus Torvalds(没错,就是那个Linus)在2005年开发了Git的原型程序。当时,由于在Linux内核开发中使用的既有版本管理系统的开发方许可证发生了变更,为了更换新的版本管理系统,Torvalds开发了Git(大神总是一言不合就自己写软件)。

在当时的情况下,虽然已经有许多版本管理软件,但是功能和性能都差强人意,特别是在开发Linux内核这样更新频繁的软件时,缺点就被进一步放大了。

在Git诞生之前,人们普遍采用的Subversion(SVN)等集中型版本管理系统,而在Git出现之后,Git就成为了主流。

2.2 什么是版本管理

版本管理就是管理更新的历史记录。它为我们提供了一些在软件开发过程中必不可少的功能,例如记录一款软件添加或更改源代码的过程,回滚到特定阶段,恢复误删的文件等。

2.2.1 集中型与分散型

下面就比较一下集中型管理系统(以Subversion为例)与分散型管理系统(以Git为例)二者的不同点。

集中型

以Subversion为代表的集中型,会将仓库存集中存放在服务器中,所以只存在一个仓库。而这也是这种版本管理系统被称为集中型的原因。

集中型将所有的数据都存放在服务器中,有便于管理的优点。但是一旦开发者所处的环境不能连接服务器,就无法获取最新的源代码,开发也几乎无法进行。服务器宕机时也是同样的道理,而且万一服务器故障导致数据消失,恐怕开发者就再也见不到最新的源代码了。

SVN

分散型

GitHub将仓库Fork给了每一个用户。Fork就是讲GitHub的某个特定仓库复制到自己的账户下。Fork的仓库与原仓库是两个不同的仓库,开发者可以随意编辑。

Git

如图所示,分散型拥有多个仓库,相对于Subversion稍显复杂。但是,由于本地的开发环境中就有仓库,所以开发者不必连接远程仓库就可以进行开发(妈妈再也不用担心服务器宕机了)。

图中只显示了一般的使用流程。实际上,所有仓库之间都可以进行push和pull。即使不通过GitHub,开发者A也可以直接向开发者B的仓库进行push和pull。因此在使用前如果不事先制定规范,开发过程往往就out of control了。

哪个更好

各有优缺点,视情况而定。但是,Git和GitHub的普及,已经有越来越多的开发者开始采用分散型版本管理。并且,只要规则制定得当,分散型也能像集中型那样进行管理。所以,我的推荐是,优先选择学习分散型,如果你的感兴趣且精力允许,可以学习集中型。

2.3 安装

2.3.1 MAC与Linux

在 Mac 上安装 Git 有两种方式。最容易的当属使用图形化的 Git 安装工具,界面如图,下载地址在:

http://sourceforge.net/projects/git-osx-installer/

git osx installer

另一种是通过 MacPorts (http://www.macports.org) 安装。如果已经装好了 MacPorts,用下面的命令安装 Git:

$ sudo port install git-core +svn +doc +bash_completion +gitweb

这种方式就不需要再自己安装依赖库了,Macports 会帮你搞定这些麻烦事。一般上面列出的安装选项已经够用,要是你想用 Git 连接 Subversion 的代码仓库,还可以加上 +svn 选项,具体将在第八章作介绍。(译注:还有一种是使用 homebrew(https://github.com/mxcl/homebrew): brew install git 。)

2.3.2 Linux

如果要在 Linux 上安装预编译好的 Git 二进制安装包,可以直接用系统提供的包管理工具。在 Fedora 上用 yum 安装:

$ yum install git-core

在 Ubuntu 这类 Debian 体系的系统上,可以用 apt-get 安装:

$ apt-get install git

2.3.3 Windows

在 Windows 上安装 Git 同样轻松,有个叫做 msysGit 的项目提供了安装包,可以到 GitHub 的页面上下载 exe 安装文件并运行:

http://msysgit.github.com/

完成安装之后,就可以使用命令行的 git 工具(已经自带了 ssh 客户端)了,另外还有一个图形界面的 Git 项目管理工具。

给 Windows 用户的敬告:你应该在 msysGit 提供的 Unix 风格的 shell 来运行 Git。在 Unix 风格的 shell 中,可以使用本书中提及的复杂多行的命令。对于那些需要在 Windows 命令行中使用 Git 的用户,必须注意:在参数中间有空格的时候,必须使用双引号将参数括起来(在 Linux 中是单引号);另外,如果扬抑符(^)作为参数的结尾,并且作为这一行的最后一个字符,则这个参数也需要用双引号括起来。因为扬抑符在 Windows 命令行中表示续行(译注:即下一行为这一行命令的继续)。

2.3.4 从源代码安装

若是条件允许,从源代码安装有很多好处,至少可以安装最新的版本。Git 的每个版本都在不断尝试改进用户体验,所以能通过源代码自己编译安装最新版本就再好不过了。有些 Linux 版本自带的安装包更新起来并不及时,所以除非你在用最新的 distro 或者 backports,那么从源代码安装其实该算是最佳选择。

Git 的工作需要调用 curl,zlib,openssl,expat,libiconv 等库的代码,所以需要先安装这些依赖工具。在有 yum 的系统上(比如 Fedora)或者有 apt-get 的系统上(比如 Debian 体系),可以用下面的命令安装:

$ yum install curl-devel expat-devel gettext-devel \
  openssl-devel zlib-devel

$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
  libz-dev libssl-dev

之后,从下面的 Git 官方站点下载最新版本源代码:

http://git-scm.com/download

然后编译并安装:

$ tar -zxf git-1.7.2.2.tar.gz
$ cd git-1.7.2.2
$ make prefix=/usr/local all
$ sudo make prefix=/usr/local install

现在已经可以用 git 命令了,用 git 把 Git 项目仓库克隆到本地,以便日后随时更新:

$ git clone git://git.kernel.org/pub/scm/git/git.git

本小节内容均来自: https://git-scm.com/book/zh/v1/%E8%B5%B7%E6%AD%A5-%E5%AE%89%E8%A3%85-Git

组件的选择

组件选择

设置环境变量

设置环境变量

换行符的处理

GitHub 中公开的代码大部分都是以 Mac 或 Linux 中的 LF(Line Feed)换行。然而,由于 Windows 中是以 CRLF(Carriage Return + Line Feed)换行的,所以在非对应的编辑器中将不能正常显示。

Git 可以通过设置自动转换这些换行符。使用 Windows 环境的童鞋,请选择推荐的“Checkout Windows-style, commit Unix-style line endings”选项。换行符在签出时会自动转换为 CRLF,在提交时则会自动转换为 LF。

换行符的处理

请注意以上这几点,配合当前使用的环境进行安装。

Git Bash

顺利安装好 msysGit 之后,Git Bash 会作为一个应用程序添加进系统,接下来请启动它。双击之后,会弹出一个名为 Git Bash 的命令提示符,它附属于 msysGit。如果你是按照上面的配置安装的话,那么git命令就只能在Git Bash中使用,在Windows的命令提示符(CMD)中是无法运行的。

Git Bash

从名字中带有 Bash 就不难猜到,Git Bash 中照搬了许多 Bash 命令,习惯 Linux 的人用起来会感觉比 Windows 命令提示符更得心应手。借这个机会,不妨也熟悉一下 Windows 的 CLI(Command Line Interface,命令行界面)操作。

2.3.3本教程所用的环境

本教程使用的macOS 10.12.4, Git 2.8.4,建议安装较新版本的Git。

2.4 初始设置

2.4.1 设置姓名和邮箱地址

首先设置使用Git时的姓名和邮箱。注意名字需要为英文。

$ git config --global user.name "Firstname Lastname"
$ git config --global user.email "myemail@email.com"

这个命令会在「~/.gitconfig」文件中以下面的格式设置文件。

[user]
    name = Firstname Lastname
    email = myemail@email.com

想要更改这些信息时,可以直接编辑这个文件,也可以使用上面的命令重新设置。这里的姓名和邮箱地址会用在Git的提交日志中,在GitHub上公开仓库时,这里的姓名和邮箱地址会随着提交日志一同公开,所以不要在这里使用不宜公开的隐私信息。

在 GitHub 上公开代码后,前来参考的程序员可能来自世界任何地方,所以请不要使用汉字,尽量用英文进行描述。当然,如果您不想使用真名,使用 two dog (二狗)或者 cuihuaer (翠花儿)也是可以的。

2.4.2 提高命令输出的可读性

将color.ui设置为auto可以让命令的输出的可读性更高。

$ git config --global color.ui auto

「~/.gitconfig」文件就会增加下面的内容:

[color]
  ui = auto

2.5 小结

安装好Git,让我们走在时代前列线上,开始愉快的写代码吧。