在编程届有个共识,想要成为一个合格的程序员必须要掌握 GitHub 的用法!所以本文除了详细介绍Github的详细使用教程,还为大家整理了一些平台大部分关于GitHub的教程博文,这部分放于文末希望能给大家带来帮助。
一、什么是 Github?
GitHub 是一个面向开源及私有软件项目的托管平台,因为只支持 Git 作为少数的版本库格式进行托管,故名 GitHub。
GitHub 于 2008 年 4 月 10 日正式上线,除了 Git 代码仓库托管及基本的 Web 管理界面以外,还提供了订阅、讨论组、文本渲染、在线文件编辑器、协作图谱(报表)、代码片段分享(Gist)等功能。目前,其托管版本数量非常之多,而且其中不乏知名开源项目,例如 Ruby on Rails、jQuery、python 等。
作为开源代码库以及版本控制系统,Github 拥有超过千万的开发者用户。随着越来越多的应用程序转移到了云上,Github 已经成为了管理软件开发以及发现已有代码的优选方法。
如前所述,作为一个分布式的版本控制系统,在 Git 中并不存在主库这样的概念,每一份复制出的库都可以独立使用,任何两个库之间的不一致之处都可以进行合并。
GitHub 可以托管各种 Git 库,并提供一个 web 界面,但与其它像 SourceForge 或 Google Code 这样的服务不同,GitHub 的独特卖点在于从另外一个项目进行分支的简易性。为一个项目贡献代码非常简单:首先点击项目站点的Fork的按钮,然后将代码检出并将修改加入到刚才分出的代码库中,最后通过内建的pull request机制向项目负责人申请代码合并。
GitHub 项目本身自然而然的也在 GitHub 上进行托管,只不过在一个私有的,公共视图不可见的库中。开源项目可以免费托管,但私有库则并非如此。在 GitHub,用户可以通过Explore轻而易举地找到海量的开源代码。因此,称之为程序员的 圣地 也不过吧?
今天,GitHub已是:
- 一个拥有143万开发者的社区。其中不乏Linux发明者Torvalds这样的拔尖黑客,以及Rails创始人DHH这样的年轻极客。
- 这个星球上最流行的开源托管服务。目前已托管431万git项目,不仅越来越多知名开源项目迁入GitHub,比如Ruby on Rails、jQuery、Ruby、Erlang/OTP;近三年流行的开源库往往在GitHub首发,例如:BootStrap、Node.js、CoffeScript等。
- alexa全球排名414的网站。
二、GitHub 使用教程
1.注册 GitHub 账户
首先,进入 GitHub 的官网:GitHub
- 标注 1:
Sign in
,登录; - 标注 2:
Sign up
,注册。
如上图所示,这是 GitHub 的官网首页,点击Sign up
进行注册:
- 标注 1:
Username
,用户名; - 标注 2:
Email Address
,邮箱地址; - 标注 3:
Password
,密码; - 标注 4:
Create an account
,创建账号按钮。
如上图所示,其中 标注 1 比较重要,较好起对我们具有标识性的用户名,而且如果以后我们要在 GitHub 上搭建自己的个人博客,其默认地址就是username.github.io
;标注 2 是需要我们验证 GitHub 账号的邮箱,注册时只能填写一个,之后可以添加多个邮箱。上面的信息都填写完成后,点击Create an account
,进入如下界面:
- 标注 1:公开的,免费仓库;
- 标注 2:私有的,付费仓库。
如上图所示,我们进入了注册 GitHub 账号流程的第 2 步,在这里有一点需要我们注意,那就是:GitHub 的仓库分为两种,一种是public repositories公开免费版,一种是private repositories私有付费版。其中,私有仓库一般是由企业或者不希望自己的仓库公开的个人用户购买,这也是 GitHub 的主要收入来源。在这里,我们选择免费版就可以,然后点击Continue,进入如下界面:
如上图所在,这是注册 GitHub 账号流程的第 3 步,也是最后一步。这个步骤的主要作用就是收集用户的个人信息,如果感兴趣的话,可以对上面的“ 问答表 ”进行勾选,然后点击Submit
提交;如果不感兴趣的话,则可以直接点击skip this step
跳过这一步。无论点击两者之中的那个按钮,都将进入如下界面:
- 标注1:
Read the guide
,阅读指南; - 标注2:
Start a project
,建立项目。
如上图所示,到这里,说明我们已经成功注册了 GitHub 的账号。在这个界面,GitHub 为我们提供了两个建议性的选择,一是Read the guide
阅读 GitHub 指南,二是Start a project
直接建立项目。
对于,标注 1 所示的Read the guide
为阅读 GitHub 英文指南,为了方便大家阅读,博主已经将其翻译为中文版,即「Hello World · GitHub 指南」,点击即可阅读。
2.GitHub 主页介绍及修改个人信息
接着上一节的内容,我们继续往下介绍:
- 标注 1:
View profile and more
,更多选项视图; - 标注 2:
Your profile
,个人简介。
如上图所在,我们依次点击 标注 1 所示的View profile and more
和 标注 2 所示的Your profile
,进入「个人简介」界面:
- 标注 1:
Edit profile
,修改个人简介; - 标注 2:
Overview
,个人主页概览; - 标注 3:
Repositories
,仓库; - 标注 4:
Star
,点星记录; - 标注 5:
Followers
,粉丝; - 标注 6:
Following
,关注的 GitHub 账号; - 标注 7:个人贡献历史记录。
如上图所示,标注 1 表示的为Edit profile
,这个选项当我们修改完个人信息之后,就会自动消失;标注 2 表示的为Overview
,展示了我们账号的主要内容,包括仓库和贡献等;标记 3 表示的为Repositories
,是我们建立的仓库,包括Fork
来的项目,GitHub 也会自动为我们创建一个仓库;标注 4 表示为Star
,收藏了我们的“点星”,或者说是“点赞”过的项目;标注 7 表示的为我们最近一年来的contribution
,用实心的小方格标记,小方格的颜色越深,表示我们的contribution
越多。在这里,我们点击Edit profile
,编辑个人简历:
如上图所示,我们可以通过这个界面填写个人信息,包括 Name(昵称)、Bio(自我介绍)、URL(链接)、Company(公司)、Location(位置)以及 Upload new picture(上传头像)等等。在我们填写完个人信息之后,可以点击Update profile
更新个人简介,同时可以勾选Available for hire
,选择“雇主可见”,然后点击Save jobs profile
,保存我们的求职简历。
此外,在Personal settings
中,还包含很多其他的选择,如在Account
中,可以修改账号密码;在Emails
中,可以修改绑定的邮箱等等。在这里,用红色框圈起的SSH and GPG keys
非常重要,我们可以通过它连接到本地的 IDE,从而保证项目提交与检出的安全性。
接下来,展示一下我们刚刚修改完的 GitHub 账号主页:
如上图所示,这就是博主最新的 GitHub 账号啦!
3.创建 GitHub 仓库的步骤及方法
我们已经对 GitHub 的个人主页有了一些了解,并且完成了对个人信息的修改。但是美中不足的是,我们还没有自己的Repo
啊,也就是 GitHub 的核心要素——库,接下来,我们就尝试创建自己的 GitHub 仓库。
如上图所示,此为博主的 GitHub 个人主页,点击Repositories
,进入如下界面:
点击上图标注所示的绿色New
按钮,进入下一步:
- 标注 1:
Repository name
,仓库名称; - 标注 2:
Description
,可选描述,也就是写不写都可以; - 标注 3:
Public
,默认的仓库类型; - 标注 4:
Initialize this repository with a README
,初始化仓库的信息文件,建议勾选。
如上图所示,这是创建 GitHub 仓库的核心页面,里面包含了众多信息。为了方便演示,博主已经把各种所需的信息都填写完啦!接下来,点击绿色Create repository
按钮即可:
如上图所示,我们已经把仓库创建成功啦!仓库名为springmvc-tutorial
,包含 1 个commit
,也就是我们通过勾选Initialize this repository with a README
,创建了一个初始化提交文件README.md
,其中文件后缀为.md
,表示文件为 Markdown 格式;包含 1 个branch
,为master
分支,即主分支;包含 1 个contributor
,为贡献者,也就是我们自己。
- 标注 1:
Popular repositories
,受欢迎的仓库,以Star
数为依据,依次展示个人项目中Star
数前 6 的项目; - 标注 2:
Contribution
,贡献标记,贡献越多,小方块的颜色越深; - 标注 3:
Contribution activity
,贡献活动记录,展示了我们的活动记录。
如上图所示,这是我们创建了仓库之后主页的变化,显然比较之前主页的元素丰富了很多,看着更爽啦!
延伸阅读:GitHub术语说明
为了大家进一步了解和使用 GitHub,在本文中,我们一起来看看 GitHub 的常用术语,也可以说是基本概念:
Repository
:简称Repo
,可以理解为“仓库”,我们的项目就存放在仓库之中。也就是说,如果我们想要建立项目,就得先建立仓库;有多个项目,就建立多个仓库。Issues
:可以理解为“问题”,举一个简单的例子,如果我们开源一个项目,如果别人看了我们的项目,并且发现了bug
,或者感觉那个地方有待改进,他就可以给我们提出Issue
,等我们把Issues
解决之后,就可以把这些Issues
关闭;反之,我们也可以给他人提出Issue
。Star
:可以理解为“点赞”,当我们感觉某一个项目做的比较好之后,就可以为这个项目点赞,而且我们点赞过的项目,都会保存到我们的Star
之中,方便我们随时查看。在 GitHub 之中,如果一个项目的点星数能够超百,那么说明这个项目已经很不错了。Fork
:可以理解为“拉分支”,如果我们对某一个项目比较感兴趣,并且想在此基础之上开发新的功能,这时我们就可以Fork
这个项目,这表示复制一个完成相同的项目到我们的 GitHub 账号之中,而且独立于原项目。之后,我们就可以在自己复制的项目中进行开发了。Pull Request
:可以理解为“提交请求”,此功能是建立在Fork
之上的,如果我们Fork
了一个项目,对其进行了修改,而且感觉修改的还不错,我们就可以对原项目的拥有者提出一个Pull
请求,等其对我们的请求审核,并且通过审核之后,就可以把我们修改过的内容合并到原项目之中,这时我们就成了该项目的贡献者。Merge
:可以理解为“合并”,如果别人Fork
了我们的项目,对其进行了修改,并且提出了Pull
请求,这时我们就可以对这个Pull
请求进行审核。如果这个Pull
请求的内容满足我们的要求,并且跟我们原有的项目没有冲突的话,就可以将其合并到我们的项目之中。当然,是否进行合并,由我们决定。Watch
:可以理解为“观察”,如果我们Watch
了一个项目,之后,如果这个项目有了任何更新,我们都会在名列前茅时候收到该项目的更新通知。Gist
:如果我们没有项目可以开源或者只是单纯的想分享一些代码片段的话,我们就可以选择Gist
。不过说心里话,如果不翻墙的话,Gist
并不好用。
三、安装 Git 及体验 Git 命令
1.Git 的安装流程及步骤
我们已经知道了如何创建 GitHub 账号、创建仓库、进行个性化设置等等,但是我们还要知道:GitHub 是基于版本控制系统 Git 之上的啊!如果我们想要进行代码托管,想要进行团队协作,这都少不了一个工具,那就是:Git. 因此,在本小节,我们就一起来了解一下 Git 的安装流程及步骤。
首先,进入 Git 的官网:git – -fast-version-control
如上图所示,在 Git 的官网中点击Downloads
,进入如下页面:
如上图所示,选择对应的操作系统,以博主为例,点击Windows
,进入如下页面:
如上图所示,正常情况下,会自动弹出下载框,否则的话,手动点击红色箭头所示的click here to download manually
亦可进入如下界面:
如上图所示,直接点击 下载 即可,下载完成后,双击打开,进入如下界面:
如上图所示,这是 Git 的安装界面,点击Next
,进入如下界面:
如上图所示,选择 Git 的安装目录,默认安装到C
盘的Program Files
目录下,想换的话,点击Browse
进入更换。在这里,我们选择将其安装到D
盘的Program Files
目录下,选择完成后,点击Next
,进入如下界面:
如上图所示,这里有一些可勾选的项,我们可以按自己的实际需求进行选择(后面同样如此),例如勾选Additional icons
,将在 Git 安装完成后,在桌面创建一个图标,也就是打开 Git 的快捷方式。在这一步,建议大家选择默认即可,例如默认勾选的Windows Explorer integration
,就可以让我们在点击鼠标右键的时候,快速选择打开Git GUI
或者 Git Bash
。选择完成后,点击Next
,进入如下界面:
如上图所示,选择 开始菜单文件夹,默认即可,点击Next
,进入如下界面:
- 标注 1:仅使用 Git Bash 进行操作;
- 标注 2:在选择使用 Git Bash 进行操作的同时,也可以使用 Windows 命令行操作,建议选择此项;
- 标注 3:在选择使用 Git 的同时,也把 Unix 工具加入到了我们的配置之中,而且此操作会覆盖 Windows 的一些工具,强烈不建议选择此项。
如上图所示,我们选择 标注2 所示的Use Git from the Windows Command Prompt
,点击Next
,进入如下界面:
如上图所示,选择 HTTPS 传输后台,默认即可,点击Next
,进入如下界面:
如上图所示,配置行结束标记,默认即可,点击Next
,进入如下界面:
如上图所示,配置 Git Bash 的终端模拟器,默认即可,点击Next
,进入如下界面:
如上图所示,配置补充功能,默认即可,点击Next
,进入如下界面:
如上图所示,展示了 Git 安装中的界面,安装完成后,弹出如下窗口:
如上图所示,这表示 Git 已经安装完成了,至于图中的两个选择,则分别表示 打开 Git Bash 和 浏览 Git 版本信息,可以都选,也可以都不选,在这里,我们选择Launch Git Bash
,进入如下界面:
如上图所示,我们打开了 Git Bash,输入git
命令,将显示如下结果:
如上图所示,Git 已经准备就绪啦,接下来就是你的 show time 啦!
2.Git 初体验及其常用命令介绍
我们已经把 Git 安装成功了,现在,就让我们一起体验 Git 的魅力吧!
不知道大家是否还记得,在 Git 安装完成的时候,我们曾在 Git Bash 中输入git
命令进行测试,其返回的结果如下图所示:
如上图所示,其返回了很多关于 Git 的信息,其中就包括 Git 的常用命令,例如init
、add
、log
和status
等等。在 Git 中,所有的命令都是以git
开头,例如,git init
其作用就是初始一个 Git 仓库。
为了方便演示,我们先在D
盘的CoderLife
目录下创建一个名为demo
的子目录,并在其中新建一个名为hit.txt
的文件,接下来我们的 Git 操作都是基于此目录和文件的。
此外,在这里还要强调一点,那就是:在我们进行任何的git
操作之前,我们都得先切换到 Git 的仓库目录。换言之,我们得到先进入到(我们定义的)Git 仓库的最顶层文件目录下,然后从此目录中进入 Git Bash,这样之后的操作才能顺利进行。如果是 Linux 操作系统,则可以直接cd
到仓库目录。以博主为例,选择demo
目录作为 Git 仓库,然后进入demo
目录之中,点击鼠标右键,再选择Git Bash Here
,即可打开 Git Bash 的命令行窗口。
如上图所示,Git 会自动定位到进入的位置,如我们选择的demo
目录,这也是为什么我们需要先进入到 Git 仓库的最顶层目录下,然后再打开 Git Bash 的原因。下面,我们结合 Git 的常用命令演示一下 Git 的相关操作。
第 1 个命令:git status
在命令行窗口的光标处,输入git status
命令,查看仓库的状态:
如上图所示,结果显示demo
不是一个 Git 仓库,这是很正常的反应,因为我们还没有在计算机中声明demo
为 Git 仓库,之前说demo
是 Git 仓库只是我们口头上的说的,计算机当然不会认可。
第 2 个命令:git init
在命令行窗口的光标处,输入git init
命令,初始化 Git 仓库:
如上图所示,结果显示已经初始化demo
为一个空的 Git 仓库啦!在这里大家可以会有些疑问,因为我们在建立demo
目录的同时也在里面新建了一个名为hit.txt
的文件,怎么初始化仓库之后,demo
目录就变成空的了呢?这个问题稍后解惑,我们重新输入git status
命令检查一下仓库的状态:
如上图所示,在我们初始化仓库之后,demo
目录已经成为一个 Git 仓库了,并且默认进入 Git 仓库的master
分支,即主分支。在这里,我们需要注意的是Untracked fies
提示,它表示demo
仓库中有文件没有被追踪,并提示了具体没有被追踪的文件为hit.txt
,还提示了我们可以使用git add
命令操作这个文件,简直不要太好。
第 3 个命令:git add
在命令行窗口的光标处,输入git add hit.txt
命令,将hit.txt
文件添加到 Git 仓库:
如上图所示,如果没有报错,就说明命令已经执行啦!接下来,输入git status
命令查看仓库状态:
如上图所示,已经显示Initial commit
初始化提交了,同时已经没有Untracked files
提示了,这说明文件hit.txt
已经被添加到 Git 仓库了,而在我们没有进行git add
操作之前,文件hit.txt
并不被 Git 仓库认可,因此才会出现提示初始化仓库为空的现象。在这里,需要声明一点,那就是:git add
命令并没有把文件提交到 Git 仓库,而是把文件添加到了「临时缓冲区」,这个命令有效防止了我们错误提交的可能性。
第 4 个命令:git commit
在命令行窗口的光标处,输入git commit -m "text commit"
命令,将hit.txt
文件提交到 Git 仓库:
如上图所示,我们成功将文件hit.txt
提交到了 Git 仓库,其中commit
表示提交,-m
表示提交信息,提交信息写在双引号""
内。接下来,再输入git status
命令查看仓库状态:
如上图所示,结果显示nothing to commit, working tree clean
,这表示已经没有内容可以提交了,即全部内容已经提交完毕。
第 5 个命令:git log
在命令行窗口的光标处,输入git log"
命令,打印 Git 仓库提交日志:
如上图所示,显示了我们的提交记录,提交记录的内容包括Author
提交作者、Date
提交日期和提交信息。
通过以上的操作,我们会发现一个现象,那就是:在每个git
操作之后,我们基本都会输入git status
命令,查看仓库状态。这也从侧面说明了git status
命令使用的频率之高,也建议大家在操作 Git 仓库的时候多使用git status
命令,这能帮助我们实时了解仓库的状态,显然非常有用。
此外,不知道大家注没注意到:在提交记录的Author
部分,显示了提交作者的名字guobinhit
和提交作者的邮箱guobinhit@qq.com
,不过这当然不是 Git 自动生成的啦,而是我事先进行了设置,具体如何设置,将在下一篇博文中介绍,还包括如何拉分支和合并分支等。
下面我们接着上一篇博文的内容,继续介绍 Git 的常用命令。
第 6 个命令:git branch
在命令行窗口的光标处,输入git branch
命令,查看 Git 仓库的分支情况:
如上图所示,显示了仓库demo
中的分支情况,现在仅有一个master
分支,其中master
分支前的*
号表示“当前所在的分支”,例如* master
就意味着我们所在的位置为demo
仓库的主分支。输入命令git branch a
,再输入命令git branch
,结果如下图所示:
如上图所示,我们创建了一个名为a
的分支,并且当前的位置仍然为主分支。
第 7 个命令:git checkout
在命令行窗口的光标处,输入git checkout a
命令,切换到a
分支:
如上图所示,我们已经切换到a
分支啦!也可以通过命令git branch
查看分支情况:
在这里,我们还有一个更简单的方法来查看当前的分支,即通过观察上图中用红色框圈起来的部分。此外,我们也可以在创建分支的同时,直接切换到新分支,命令为git checkout -b
,例如输入git checkout -b b
命令:
如上图所示,我们在a
分支下创建b
分支(b
为a
的分支),并直接切换到b
分支。
第 8 个命令:git merge
切换到master
分支,然后输入git merge a
命令,将a
分支合并到master
分支:
如上图所示,我们已经将a
分支合并到主分支啦!此外,在这里需要注意一点,那就是:在合并分支的时候,要考虑到两个分支是否有冲突,如果有冲突,则不能直接合并,需要先解决冲突;反之,则可以直接合并。
第 9 个命令:git branch -d
& git branch -D
在命令行窗口的光标处,输入git branch -d a
命令,删除a
分支:
如上图所示,我们已经将分支a
删除啦!不过有的时候,通过git branch -d
命令可以出现删除不了现象,例如分支a
的代码没有合并到主分支等,这时如果我们一定要删除该分支,那么我们可以通过命令git branch -D
进行强制删除。
第 10 个命令:git tag
在命令行窗口的光标处,输入git tag v1.0
命令,为当前分支添加标签:
如上图所示,我们为当前所在的a
分支添加了一个v1.0
标签。通过命令git tag
即可查看标签记录:
如上图所示,显示了我们添加标签的记录。通过命令git checkout v1.0
即可切换到该标签下的代码状态:
如上图所示,我们已经成功切换到a
分支的v1.0
标签啦!
通过「Git 初体验及其常用命令介绍」两篇博文的内容,我们已经了解了一些 Git 的常用命令啦,但还有很多命令我们没有进行演示,例如clone
、rm
、grep
、pull
和push
等,Git 的魅力也并不止于此,还有更多的精彩等待大家探索。
此外,对于前一篇博文中遗留的问题,即“提交内容”中的Author
和Email
,可以用如下命令进行设置:
git config --global user.name "名字"
git config --global user.email "邮箱"
其中,global
表示设置为全局可用,如果想设置局部可用,删除global
即可。
四、使用 Git 与 GitHub 进行交互
1.利用 SSH 完成 Git 与 GitHub 的绑定
我们已经对 GitHub 有了一定的了解,包括创建仓库、拉分支,或者通过Clone or download
克隆或者下载代码;我们也下载并安装了 Git,也了解了其常用的命令。But,无论是 GitHub,还是 Git,我们都是单独或者说是独立操作的,并没有将两者绑定啊!也就是说,我们现在只能通过 GitHub 下载代码,并不能通过 Git 向 GitHub 提交代码。
因此,在本篇博文中,我们就一起完成 Git 和 GitHub 的绑定,体验通过 Git 向 GitHub 提交代码的能力。不过在这之前,我们需要先了解 SSh(安全外壳协议),因为在 GitHub 上,一般都是通过 SSH 来授权的,而且大多数 Git 服务器也会选择使用 SSH 公钥来进行授权,所以想要向 GitHub 提交代码,首先就得在 GitHub 上添加 SSH key
配置。在这里,如果大家对 SSH 还不太了解,那么建议先阅读博主之前写的文章「详述 SSH 的原理及其应用 」,从而对 SSH 有一个大致的了解。
第 1 步:生成
SSH key
我们要想生成SSH key
,首先就得先安装 SSH,对于 Linux 和 Mac 系统,其默认是安装 SSH 的,而对于 Windows 系统,其默认是不安装 SSH 的,不过由于我们安装了 Git Bash,其也应该自带了 SSH. 可以通过在 Git Bash 中输入ssh
命令,查看本机是否安装 SSH:
如上图所示,此结果表示我们已经安装 SSH 啦!接下来,输入ssh-keygen -t rsa
命令,表示我们指定 RSA 算法生成密钥,然后敲三次回车键,期间不需要输入密码,之后就就会生成两个文件,分别为id_rsa
和id_rsa.pub
,即密钥id_rsa
和公钥id_rsa.pub
. 对于这两个文件,其都为隐藏文件,默认生成在以下目录:
- Linux 系统:
~/.ssh
- Mac 系统:
~/.ssh
- Windows 系统:
C:\Documents and Settings\username\\.ssh
- Windows 10 ThinkPad:
C:\Users\think\.ssh
密钥和公钥生成之后,我们要做的事情就是把公钥id_rsa.pub
的内容添加到 GitHub,这样我们本地的密钥id_rsa
和 GitHub 上的公钥id_rsa.pub
才可以进行匹配,授权成功后,就可以向 GitHub 提交代码啦!
第 2 步:添加
SSH key
如上图所示,进入我们的 GitHub 主页,先点击右上角所示的倒三角▽
图标,然后再点击Settins
,进行设置页面;点击我们的头像亦可直接进入设置页面:
如上图所示,进入Settings
页面后,再点击SSH and GPG Keys
进入此子界面,然后点击New SSH key
按钮:
如上图所示,我们只需要将公钥id_rsa.pub
的内容粘贴到Key
处的位置(Titles
的内容不填写也没事),然后点击Add SSH key
即可。
第 3 步:验证绑定是否成功
在我们添加完SSH key
之后,也没有明确的通知告诉我们绑定成功啊!不过我们可以通过在 Git Bash 中输入ssh -T git@github.com
进行测试:
如上图所示,此结果即为Git 与 GitHub 绑定成功的标志。
2.通过 Git 将代码提交到 GitHub
我们完成了本地 Git 与远程 GitHub 的绑定,这意味着我们已经可以通过 Git 向 GitHub 提交代码啦!但是在进行演示之前,我们需要先了解两个命令,也是我们在将来需要经常用到的两个命令,分别为push
和pull
.
push
:该单词直译过来就是“推”的意思,如果我们本地的代码有了更新,为了保持本地与远程的代码同步,我们就需要把本地的代码推到远程的仓库,代码示例:
git push origin master
pull
:该单词直译过来就是“拉”的意思,如果我们远程仓库的代码有了更新,同样为了保持本地与远程的代码同步,我们就需要把远程的代码拉到本地,代码示例:
git pull origin master
此外,在之前我们讲到过pull request
,在这里,估计大家就能更好的理解了,它表示:如果我们fork
了别人的项目(或者说代码),并对其进行了修改,想要把我们的代码合并到原始项目(或者说原始代码)中,我们就需要提交一个pull request
,让原作者把我们的代码拉到 ta 的项目中,至少对于 ta 来说,我们都是属于远程端的。
一般情况下,我们在push
操作之前都会先进行pull
操作,这样不容易造成冲突。
提交代码
对于向远处仓库(GitHub)提交代码,我们可以细分为两种情况:
- 名列前茅种:本地没有 Git 仓库,这时我们就可以直接将远程仓库
clone
到本地。通过clone
命令创建的本地仓库,其本身就是一个 Git 仓库了,不用我们再进行init
初始化操作啦,而且自动关联远程仓库。我们只需要在这个仓库进行修改或者添加等操作,然后commit
即可。
接下来,以博主的 GitHub 账号中的mybatis-tutorial
项目为例,进行演示。首先,进入 GitHub 个人主页:
如上图所示,点击mybatis-tutorial
项目:
如上图所示,进入mybatis-tutorial
项目后,点击Clone or download
,复制上图所示的地址链接。然后,进入我们准备存储 Git 仓库的目录,例如下面我们新建的GitRepo
目录, 从此目录进入 Git Bash:
接下来,输入git clone https://github.com/guobinhit/mybatis-tutorial.git
命令,其中clone
后面所接的链接为我们刚刚复制的远程仓库的地址:
如上图所示,我们已经把远程的mybatis-tutorial
仓库clone
到本地啦!下面,我们看看clone
到本地的仓库内容与远程仓库的内容,是否完全一致:
如上图所示,显示我们已经把远程仓库mybatis-tutorial
的内容都clone
到本地啦!接下来,为了方便演示,我们直接把之前重构的「史上最简单的 MyBatis 教程」里面的mybatis-demo
项目的代码复制过来:
如上图所示,我们已经把mybatis-demo
项目里面的主要内容src
目录和web
目录复制过来啦!接下来,从此目录进入 Git Bash,然后输入git status
命令查看仓库状态:
如上图所示,mybatis-tutorial
已经是一个 Git 仓库了,而且在输入git status
命令后显示有两个文件未被追踪,也就是我们刚刚复制过来的两个文件没有提交。通过「Git 初体验及其常用命令介绍」,我们已经知道了在真正提交代码之前,需要先进行git add
操作:
如上图所示,我们已经将src
目录add
并commit
到mybatis-tutorial
仓库啦!接下来,我们将web
目录提交到仓库,然后输入git log
命令查看仓库日志:
再输入git status
命令查看仓库状态:
如上图所示,我们已经将mybatis-tutorial
仓库里面新添加的两个目录都提交啦!下面,我们将本地仓库的内容push
到远程仓库,输入git push origin master
命令:
如上图所示,在名列前茅次向远程仓库提交代码的时候,需要输入账号及密码进行验证,验证成功后,显示如下结果:
然后,刷新 GitHub 中mybatis-tutorial
仓库:
如上图所示,我们已经将项目(仓库)中新添加的内容提交到了远程仓库。接下来,返回 GitHub 个人主页:
观察上图,我们会发现一个现象,那就是:mybatis-tutorial
仓库的概要中新增了一个Java
语言的标记。对于这个仓库语言的标记,其来源有两个,一是在我们创建仓库时就指定语言;二是在我们提交或者新建代码后由 GitHub 自动识别该语言。
我们已经介绍了向 GitHub 提交代码时的名列前茅种情况,即:
- 名列前茅种:本地没有 Git 仓库,这时我们可以直接将远程仓库
clone
到本地。通过clone
命令创建的本地仓库,其本身就是一个 Git 仓库了,不用我们再进行init
初始化操作啦,而且自动关联远程仓库。我们只需要在这个仓库进行修改或者添加等操作,然后commit
即可。
接下来,我们继续介绍向 GitHub 提交代码时可能遇到的第二种情况,即:
- 第二种:本地有 Git 仓库,并且我们已经进行了多次
commit
操作。
仍然以博主的开源项目为例,不过这次换成springmvc-tutorial
项目进行演示。首先,建立一个本地仓库,命名为springmvc-tutorial
:
如上图所示,进入该仓库,进入init
初始化操作:
然后,输入git remote add origin https://github.com/guobinhit/springmvc-tutorial.git
命令,关联远程仓库(在此,默认大家都知道如何获取远程仓库的地址),其中origin
为远程仓库的名字:
输入git pull origin master
命令,同步远程仓库和本地仓库:
再回到本地springmvc-tutorial
仓库,看看我们是否已经把远程仓库的内容同步到了本地:
如上图所示,显然我们已经把远程springmvc-tutorial
仓库里面仅有的README.md
文件同步到了本地仓库。接下来,在本地仓库新建一个名为test.txt
的测试文件:
输入git add
和git commit
命令,将文件test.txt
添加并提交到springmvc-tutorial
仓库:
再输入git push origin master
命令,将本地仓库修改(或者添加)的内容提交到远程仓库:
如上图所示,我们已经将本地仓库的内容同步到了远程仓库。下面,我们进入远程springmvc-tutorial
仓库的页面,看看我们的提交结果:
如上图所示,我们已经将「通过 Git 将代码提交到 GitHub」的第二种情况演示完毕。
此外,在本篇博文中,我们将远程仓库命名为origin
,本地仓库名为springmvc-tutorial
,其实两者的名字咱们可以随意取,一般来说,我们习惯性将远程仓库命名为origin
,不过在需要关联多个远程仓库的时候,就需要我们再取别的名字啦!
最后,再强调一遍:在我们向远程仓库提交代码的时候,一定要先进行pull
操作,再进行push
操作,防止本地仓库与远程仓库不同步导致冲突的问题,尤其是第二种提交代码的情况,很容易就出现问题。
3.Git 进阶之「设置别名」
我们已经接触了不少常用的命令,包括:
git status
,查询仓库状态;git init
,初始化仓库;git add
,添加文件;git commit
,提交文件;git log
,查询提交日志;git branch
,拉分支;git checkout
,切换分支或者标签;git merge
,合并分支;git branch -d & git branch -D
,删除或者强制删除分支;git tag
,添加标签。
对于上述的 Git 命令,我们使用的频繁特别高,虽然这些单词都不算长,但是我们敲上十次、百次,甚至千次呢?敲一个git checkout
和敲一个git co
,哪一个更省时省力呢?显然是后者。这时,就体现了别名的作用啦!也就是alias
.
还记得我们设置Author
和Email
时的操作吗?设置别名也类似,输入:
git config --global alias.co check
如上所示,这样我们就设置checkout
的别名为co
啦!也就是说,以后我们直接输入git co
,就表示git checkout
啦,特别是对于一些组合操作,例如:
git config --global alias.psm 'push origin master'
git config --global alias.plm 'pull origin master'
显然方便了很多。在这里,各种命令的别名我们可以顺便的起,只要我们能记住就 OK 啦!
此外,我们再了解一个比较diǎo
的命令。正常情况下,我们输入git log
查询日志,结果如下图所示:
现在,我们输入命令:
git log --graph --pretty=format:'%Cred%h%Creset - %C(yellow)%d%Creset %s %Cgreen(%cr)
%C(bold blue)<%an>%Creset' --abbrev-commit --date=relative
结果如下图所示:
显然,日志看着更加清楚啦!
最后,我们介绍一个查看本机 Git 配置的命令,即git config -l
:
如上图所示,展示了color.ui
、core.repositoryformatversion
和core.filemode
等配置信息。
4.回滚 Git 提交到 GitHub 的 commit 记录
在我们使用 Git 的时候,有时候会遇到想要回滚到某次提交之前的场景。
在这时,我们只需要按照如下步骤操作,即可实现这个目的:
首先,找到想要回退到某个版本的版本号,查看版本号的命令为git log
,例如
如上图所示,找到想要回退的版本号之后,在本地 Git 仓库执行如下命令:
git reset --hard <版本号>
或者git reset --soft <版本号>
对于上述两条命令,仅有--hard
和--soft
参数的不同,两者的区别是:
--hard
,抛弃当前工作区的修改--soft
,回退到之前的版本,但保留当前工作区的修改,可以重新提交
执行完本地回滚之后,还需要执行如下命令,同步远端的内容:
git push origin <分支名>
在执行上述命令的时候,可能会提示本地的版本落后于远端的版本,因此我们还需要在上述命令中加上--force
参数:
git push origin <分支名> --force
到这里,我们就可以把本地和远端的代码都回退到某一个指定的版本了。
5.详述 Git 的 rebase 命令使用方法
在基于 Git 的开发过程中,我们很容易遇到合并代码的情况,例如我们从 master 分支拉取了一个 feature 分支,当我们开发到一段时间之后,可能需要将 master 的代码合并到我们当前的 feature 分支之中。
这时,我们有两个选择,一个是使用git merge
命令,一个是使用git rebase
命令,这两个命令都是用来合并代码的,但却有一些差异。在本文中,我们主要讲述git rebase
命令的使用方法,也会简单介绍这两个命令的差异。
如上图所示,我们从 master 分支拉取了一个名为 feature 的分支,并且在拉取新分支之后,有过三次提交记录;同时,master 分支在我们拉取 feature 分支之后,也有过两次提交记录。现在我们已经构造了背景,接下来我们合并代码。
首次,我们使用merge
命令,其命令形式一般为git merge --no-ff master
,即表示将 master 的代码合并到 feature 分支,其中--no-ff
参数是为了保留 master 分支的提交记录。如上图所示,在使用merge
命令进行代码合并之后,Git 会自动创建一个新的 commit 用来表示当前的合并操作,此 commit 记录了 master 代码合并到 feature 分支时产生的所有改动。
接下来,我们使用rebase
命令,其命令一般形式为git rebase feature
,即表示在 master 分支上执行rebase
命令,将 feature 分支的代码合并到 master 分支。如上图所示,在使用rebase
命令之后,Git 会合并两个分支的 commit 记录,其规则为「在基准分支上合并目标分支的代码,会将目标分支的提交记录全部前置到基准分支的最新提交记录之前」,就如上面这样,我们在 master 分支上使用了rebase
命令之后,Git 将 feature 分支上面的所有 commit 记录都前置到了 master 分支的最新 commit 记录之前。
在这里,需要注意的是:rebase
是以 commit 为维度的,按 commit 提交的顺序依次进行合并操作;如果在合并的过程中,某个 commit 遇到了冲突,则需要我们先解决该冲突,然后才能继续进行合并操作。特别地,在我们解决冲突之后,需要使用git add + 冲突文件
命令将当前冲突标记为已解决,然后使用git rebase --continue
命令继续合并操作。
通过上面的描述,我们能发现merge
和rebase
有一个很明显的差异,那就是当遇到冲突的时候,使用merge
命令,我们只需要解决一次冲突即可;使用rebase
命令,我们则需要依次解决每一个冲突。
对于 Git 的rebase
命令,其除了能进行代码合并之外,还有一个常用的功能,那就是将多个 commit 合并为一个,仍然以上面的 feature 分支为例,我们将其从 master 分支拉取之后,进行了三次提交,现在我们将这三个提交结论合并为一个,其命令一般形式为:
git rebase -i HEAD~N
其中,N
为我们需要合并的 commit 记录的数量,因为示例中是三次提交记录,所以在此场景下,将N
替换为3
即可。
在执行完上面的命令之后,我们会进入vi
或者vim
文件编辑器:
如上图所示,pick
标识了我们的三次提交记录,按i
建进入编辑模式,保留名列前茅个pick
,然后将后面两个pick
修改为s
或者f
,然后键入:wq
保留修改。最后,为了将变更同步到远程分支,我们需要使用git push -f
命令,其中参数-f
表示强制提交。
五、关于 GitHub 使用的若干补充
1.GitHub 使用的补充
为了大家玩的更好,在此给出 GitHub 的若干补充。
Point 1:查看Repo
数据
对于一个开源项目,我们可以清晰的查看其commit
记录的情况(可以用图形的方式表现出来),如果这个项目有多个分支以及有过合并分支的记录,那么我们也可以查看其合并分支的情况等。以博主的项目「java-skills」为例:
如上图所示,进入项目java-skills
,然后点击Insights
并选择其中的Contributors
(原先为Graphs
):
观察上图,其清晰的显示出了这个项目的整体贡献情况。当然,我们也可以选择Commits
,查看这个项目的提交情况;或者选择Members
,查看参与这个项目的具体成员等。
Point 2:查看技术趋势
说实话,这个小标题起的名字并不小,反而很大。但是虽然其不能100%
的反应技术的趋势,却可以在很大程度上表现出在过去一段时间内(例如,一天内、一周内或者一月内)大家都关心什么,或者对什么感兴趣。具体操作步骤为:先点击Explor
:
然后再点击Trending
:
结果如下图所示:
在上图中,我们还可以继续选择如日期、语言等,来完成进一步的筛选工作。
Point 3:按条件搜索开源项目
一般情况下,我们搜索开源项目,只需要在搜索栏输入关键词(多个关键词,用空格隔开)即可,例如我们直接输入关键词java
进行搜索:
如上图所示,显示了众多的搜索结果,但这样的结果可能并不是特别好。实际上,我们可以更进一步,直接进行条件搜索,例如输入关键词java stars:>1000
,结果如下图所示:
观察上图,显然我们可以发现其展示出来的结果为star
数大于1000
的开源项目。
2.详述 GitHub 中声明 LICENSE 的方法
当我们在 GitHub 浏览一些开源项目时,我们经常会看到这样的标志:
如上图所示,Apache-2.0
,我们可以将其称之为开源许可证,那么到底开源许可证是什么呢?
- 开源许可证即授权条款。开源软件并非完全没有限制。最基本的限制,就是开源软件强迫任何使用和修改该软件的人承认发起人的著作权和所有参与人的贡献。任何人拥有可以自由复制、修改、使用这些源代码的权利,不得设置针对任何人或团体领域的限制;不得限制开源软件的商业使用等。而许可证就是这样一个保证这些限制的法律文件。
常见的开源许可证包括:
Apache License 2.0
GNU General Public License v3.0
MIT License
开源许可证种类很多,以上三个许可证是比较常用的。至于 GitHub 都允许什么类型的许可证,以博主的项目cg-favorite-list
为例:
如上图所示,在项目首页,点击Create new file
,创建名为LICENSE
文件:
实际上,当我们键入LICENSE
文件名的时候,GitHub 就已经自动提示Choose a license template
选项啦,点击进入:
如上图所示,最左侧展示了 GitHub 可以选择的开源许可证名称,以MIT License
为例,点击之后,中间部分显示具体开源许可证的内容。在此处,我们可以自由选择自己想要的许可证,然后点击Review and submit
:
- 标注 1:
Commit directly to the master branch.
- 标注 2:
Create a new branch for this commit and start a pull request.
如上图所示,在这里,我们有两个选择。如果我们选择 标注 1 所示的内容,则直接将此许可证提交到master
分支;如果我们选择 标注 2 所示的内容,则是新建立一个分支,然后我们可以提PR
到master
,再进行合并。在此,我们选择 标注 1 所示的内容,直接将MIT License
提交到master
分支:
如上图所示,我们已经为cg-favorite-list
项目创建了一个开源许可证。那么,你还在等什么?赶紧为你的项目创建开源许可证吧!
3.详述 GitHub 如何将代码从原分支合并到 fork 分支
在使用 GitHub 的过程中,我们可能会遇到这样的问题,即:
- 如何将原分支的代码合并到
fork
的分支?
这个问题其实很常见。当我们fork
别人代码的时候,实际上是对原项目当时状态以及进度进行了一个快照,其随后发生的改变,并不会自动同步到我们的fork
分支!但是为了保证我们fork
的分支状态与原分支同步,这就需要我们主动将原分支的代码合并到我们fork
的分支了。现在,以博主fork
的akka
项目为例,就让我们一起看看,将原分支代码合并到fork
分支的具体操作步骤:
- 标注 1:
New pull request
,新建拉请求按钮; - 标注 2: 显示
fork
分支与原分支相差的提交次数。
如上图所示,标注 2 显示了我们已经向fork
的分支进行了 6 次提交以及在我们fork
原分支或者上一次合并之后,原分支已经进行了 160 次提交。为了原分支的代码,点击 标注 1 所示的New pull request
按钮。
如上图所示,默认是从我们fork
的分支向原分支合并,标注 1 左边的箭头表示合并的方向,点击 标注 1 所示的位置,选择 标注 2 所示的akka/akka
,也就是原分支。
点击原分支之后,会自动跳转到如上界面,点击compare across forks
:
点击compare across forks
之后,会再次显示出两个分支,点击 标注 1 所示的位置,选择 标注 2 所示的guobinhit/akka
,也就是我们fork
的分支。
如上图所示,显示出了原分支的提交记录,点击Create pull request
按钮:
- 标注 1:显示分支合并方向;
- 标注 2:合并记录标题,必填项;
- 标注 3:合并记录信息,选填项;
- 标注 4:
Create pull request
,创建拉请求按钮。
如上图所示,填写完 标注 2 和 标注 3 所需的内容之后,点击 标注 4 所示的Create pull request
按钮:
如上图所示,我们成功创建了一个PR
,其中醒目的绿色Open
标识,表示有待处理的拉请求。继续向下滑动页面,可以按时间顺序查阅原分支的提交记录,当页面滑动至底部的时候,会出现一个Merge pull request
按钮:
如上图所示,点击Merge pull request
按钮:
如上图所示,点击Merge pull request
按钮之后,继续点击Confrim merge
按钮:
如上图所示,合并完成!特别地,当合并操作完成之后,先前绿色的Open
标识,变为紫色的Merged
标识。
最后,回到项目主页面,如上图所示,其展示了我们刚刚完成的合并操作记录。
六、深入理解 GitHub Flow
GitHub Flow 是一个轻量级,基于分支的工作流,支持团队和项目的定期部署。本指南介绍了 GitHub Flow 的工作原理。
Step 1. 创建分支(Create a branch)
当你操作一个项目的时候,无论其他协作者做什么,你都可以在特定的分支上实现自己的想法。也就是说,分支的存在是帮助你管理这些工作流。
在你创建了一个项目的分支的时候,你也就创建了一个可以尝试你的新想法的环境。在分支上做的更改不会影响master
分支,所以你可以自由地进行实验和提交更改,这些操作都是安全的。当然,只有你完成的代码被协作人审阅并通过的时候,才可以被合并。
提示(ProTip)
分支是 Git 中的核心概念,而且整个 GitHub Flow 也是基于此的。在这里,只有一条规则,那就是:master
分支中任何内容都是可以被展开的。
正因为如此,新分支在实现一个功能或修复一个程序的时候是非常重要的。你的分支名称应该具有描述性(例如,refactor-authentication
、user-content-cache-key
、make-retina-avatars
),以便其他人通过分支名称就可以知道它到底是干什么用的。
Step 2. 添加提交(Add commit)
只要你创建了分支,就说明你要对它进行修改啦!无论添加、修改、还是删除文件,你都必须进行提交,将它们同步到你的分支上。当你在分支上工作的时候,这些提交操作可以跟踪你的工作进度。
提交操作也建立一个关于你工作的透明历史,通过查看这些提交记录,其他人可以知道你做了什么和为什么这么做。每个提交操作都有一个相关的提交信息(Commit messages),用于描述你做出的修改。此外, 每一个提交操作都被视为一个“修改单元”。如果发现了 bug 或者决定走不同的开发方向,你也可以通过这些“修改单元”进行回滚操作。
提示(ProTip)
提交信息非常的重要,特别是当你将修改的内容提交到服务器之后,Git 可以追踪到你的修改内容并展示它们。通过写清楚的提交信息,你可以让其他人更容易跟上我们的思路并提供反馈。
Step 3. 提出 Pull 请求(Open a pull request)
Pull 请求开启了一个关于你的提交内容的讨论。因为他们与底层 Git 仓库紧密集成,所以如果他们接受你的请求,任何人都可以准确地看到合并的变化。
你可以在开发过程中的任何时候提出一个 Pull 请求:当你有很少或没有代码但想分享一些截图或一些想法的时候;当你卡住了需要帮助或建议的时候;或者当你准备好了让人来审查你工作的时候。在你写 Pull 请求信息的时候,通过使用 GitHub 的@mention system
,你可以向特定的人或团队反馈问题,无论他们在你身边还是在 10 个时区之外。
提示(ProTip)
Pull 请求对于促进开源项目和管理共享库的更改非常有用。如果你使用Fork & Pull Model
,Pull 请求提供一种方式来通知工程维护人员关于你希望他们考虑的变化。如果使用Shared Repository Model
,则在将它们合并到主分支前,Pull 请求帮助启动代码审查和有关更改建议的会话。
Step 4. 讨论和评估你的代码(Discuss and review your code)
当你提出 Pull 请求的时候,审查你的更改内容的人或团队可能有一些问题或者意见。也许你的编码风格与项目规范不符,或者缺少单元测试,也有可能所有的东西看起来都很棒,条理清晰。Pull 请求的目的就是鼓励和捕捉这种类型的对话。
你也可以在大家讨论和给出关于你提交内容的反馈时,继续 Push 你的分支。如果有人评论说你什么没有做,或者代码中有 bug,你也可以及时把它修复,然后 Push 这些修改。GitHub 将会给你展示出最新评论和反馈,你也可以在 Pull 请求的视图中统一接收这些消息。
提示(ProTip)
Pull 请求的评论是用 Markdown 编辑的,因此你可以在评论中嵌入图片、表情符号、使用预格式化文本块,以及其他轻量级的格式。
Step 5. 部署(Deploy)
只要你的 Pull 请求被审查并且通过了你的测试,你就可以部署这些修改,在生产环境中验证她们。如果分支发生了问题,你也可以回滚到之前的状态。
Step 6. 合并(Merge)
现在, 你修改的内容已经在生产环境中验证了,是时候将你的代码合并到master
分支啦!合并之后,Pull 请求就保存了一份关于你修改代码的历史记录。因为它们是可搜索的,所有任何人都可以通过搜索了解你为什么这么修改以及如何修改的。
提示(ProTip)
通过将某些关键字加入到你的 Pull 请求文本中,你可以将问题与代码关联起来。当你的 Pull 请求被合并时,相关问题也将被关闭。例如,输入短语Closes #32
,将关闭仓库中序号为 32 的问题。