Github 相关概念解析

---

一、前言

很多项目开发都会采用git这一优秀的分布式版本管理工具进行项目版本管理，使用github开源平台作为代码仓库托管平台。

由于git的使用非常灵活，在实践当中衍生了很多种不同的工作流程，不同的项目、不同的团队会有不同的协作方式。因此，掌握git对于以后的学习、开发工作大有好处。

---

二、概念介绍

1、仓库（Repository）

在项目的开始到结束，我们会有两种仓库。一种是源仓库（origin），一种是开发者仓库。

1.1、源仓库

在项目的开始，项目的发起者构建起一个项目的最原始的仓库，我们将其称为origin
源仓库的作用有：

• 汇总参与该项目的各个开发者的代码
• 存放趋于稳定和可发布的代码

源仓库应该是受保护的，开发者不应该直接对其进行开发工作。只有项目管理者（通常是项目发起人）能对其进行较高权限的操作

1.2、开发者仓库

任何开发者都不会对源仓库进行直接的操作，源仓库建立以后，每个开发者需要做的事情就是把源仓库的“复制”一份，作为自己日常开发的仓库。这个复制，也就是github上面的fork。

每个开发者所fork的仓库是完全独立的，互不干扰，甚至与源仓库都无关。

每个开发者仓库相当于一个源仓库实体的影像，开发者在这个影像中进行编码，提交到自己的仓库中，这样就可以轻易地实现团队成员之间的并行开发工作。

而开发工作完成以后，开发者可以向源仓库发送pull request，请求管理员把自己的代码合并到源仓库中，这样就实现了分布式开发工作，和最后的集中式的管理。

---

2、分支（Branch）

分支是git中非常重要的一个概念，利用git的分支，可以非常方便地进行开发和测试。

如果使用git没有让你感到轻松和愉悦，那是因为你还没有学会使用分支。

分支的种类如下：

2.1、永久性分支

永久性分支是寿命无限的分支，存在于整个项目的开始、开发、迭代、终止过程中。永久性分支只有两个master和develop。

• master branch：主分支

master分支从项目一开始便存在，它用于存放经过测试，已经完全稳定代码.

在项目开发以后的任何时刻当中，master存放的代码应该是可作为产品供用户使用的代码。所以，应该随时保持master仓库代码的清洁和稳定，确保入库之前是通过完全测试和代码reivew的。

master分支是所有分支中最不活跃的，大概每个月或每两个月更新一次，每一次master更新的时候都应该用git打上tag，说明你的产品有新版本发布了。

• develop branch：开发分支

develop 分支，一开始从master分支中分离出来，用于开发者存放基本稳定代码。

之前说过，每个开发者的仓库相当于源仓库的一个镜像，每个开发者自己的仓库上也有master和develop。

开发者把功能做好以后，是存放到自己的develop分支中，当测试完以后，可以向管理者发起一个pull request，请求把自己仓库的develop分支合并到源仓库的develop中。

所有开发者开发好的功能会在源仓库的develop分支中进行汇总，当develop中的代码经过不断的测试，已经逐渐趋于稳定了，接近产品目标了。这时候，我们就可以把develop分支合并到master分支中，发布一个新版本。

注意，任何人不应该向master直接进行无意义的合并、提交操作。正常情况下，master只应该接受develop的合并，也就是说，master所有代码更新应该源于合并develop的代码。

2.2、临时性分支

暂时性分支和永久性分支不同，暂时性分支在开发过程中是一定会被删除的。所有暂时性分支，一般源于develop，最终也一定会回归合并到develop分支

• feature branch：功能分支

功能性分支，是用于开发项目的功能的分支，是开发者主要战斗阵地。开发者在本地仓库从develop分支分出功能分支，在该分支上进行功能的开发，开发完成以后再合并到develop分支上，这时候功能性分支已经完成任务，可以删除。

功能性分支的命名一般为feature-*，*为需要开发的功能的名称

举例如下：

假设我现在已经把某个源仓库fork了，并且clone到了本地

现在我要开发一个新的功能，那么我可以这样做：

git checkout develop  // 切换到develop分支，当前所在的分支为develop 

git checkout -b feature-myfeature // 分出一个功能性分支，当前所在的分支为 feature-myfeature

// 开发与测试，在当前分支下进行多次的commit，当前所在的分支为 feature-myfeature

git checkout develop // 回到develop分支，当前所在的分支为develop ，后续所在的分支都是develop 

git merge --no-ff feature-myfeature // 把做好的功能合并到develop中

git branch -d feature-myfeature // 删除功能性分支

git push origin develop // 把develop提交到自己的远程仓库中

• release branch：预发布分支

预发布分支，当产品即将发布的时候，要进行最后的调整和测试，这时候就可以分出一个预发布分支，进行最后的bug fix。测试完全以后，发布新版本，就可以把预发布分支删除。预发布分支一般命名为release-*

• hotfix branch：bug修复分支

修复bug分支，当产品已经发布了，突然出现了重大的bug。这时候就要新建一个hotfix分支，继续紧急的bug修复工作，当bug修复完以后，把该分支合并到master和develop以后，就可以把该分支删除。修复bug分支命名一般为hotfix-*

---

3、工作流（Workflow）

3.1、源仓库的构建

这一步通常由项目发起人来操作，假设项目发起人已经为我们建立起了一个源仓库A，并且已经初始化了两个永久性分支master和develop

3.2、开发者fork源仓库

源仓库建立以后，每个开发就可以去复制一份源仓库到自己的github账号中，然后作为自己开发所用的仓库。假设我是一个项目中的开发者，我就到A项目主页上去fork

fork完以后，我就可以在我自己的仓库列表中看到一个和源仓库一模一样的复制品

3.3、把自己开发者仓库clone到本地

在本地使用git clone指令即可

3.4、构建功能分支进行开发

如2.2中所示

3.5、向管理员提交pull request

假设我完成了相应的功能（当然，你还可能对自己的develop进行了多次合并，完成了多个功能），经过测试以后，觉得没问题，就可以请求管理员把自己仓库的develop分支合并到源仓库的develop分支中，这就是传说中的pull request

3.6、管理员测试、合并

接下来就是管理员的操作了，管理员登陆github，便看到了我们对源仓库发起的pull request

此时管理员要做的是：

1. 对我的代码进行review

github提供非常强大的代码review功能

2. 在他的本地测试新建一个测试分支，测试我的代码

>> git checkout develop
# 进入他本地的develop分支

>> git checkout -b livoras-develop
# 从develop分支中分出一个叫livoras-develop的测试分支测试我的代码

>> git pull https://github.com/livoras/git-demo.git develop
# 把我的代码pull到测试分支中，进行测试

3. 判断是否同意合并到源仓库的develop中，如果经过测试没问题，可以把我的代码合并到源仓库的develop中

>> git checkout develop

>> git merge --no-ff livoras-develop

>> git push origin develop

注意，管理员一直在操作的仓库是源仓库

所以我们经过上面一系列操作以后，就可以在源仓库主页中看到了

---

三、参考

https://segmentfault.com/a/1190000002413519#articleHeader2