目录

Git | Github 介绍、使用及参与 Github 开源项目

https://img.dawnguo.cn/Git/5_mind.png

1. Github 介绍

1.1. 是什么

github 是全球最大的同性交友社区(滑稽脸.jpg)。github 简单来说就是一个存代码的地方,也就相当于远端仓库。当然 github 除了存放代码之外,还有其他功能,可以看这个主页 https://github.com/features,简单来说有 code review、organization 类型的账号、project 看板的功能、issue(可以提问题、需求等)、marketplace等功能。甚至可以使用 github 来搭建博客等,如 jekelly。下面对 github 的部分功能进行阐述。

1.2. CI 持续集成(Continuous Integration)

CI 简单来说就是可以自动的帮助开发人员将代码更改合并到共享分支或者集成分支上。合并之后还可以自动构建应用并运行自动化测试来验证这些更改,假如新代码和现有代码之间存在冲突还可以快速修复这些错误,最后还可以通过 CI 将应用直接部署到云服务器上。这样子就让仓库的维护者可以只专注于编写代码,剩下的集成、测试、部署等都可以交给 CI 来做了。

持续集成(CI)可以帮助开发人员更加频繁地(有时甚至每天)将代码更改合并到共享分支或“主干”中。一旦开发人员对应用所做的更改被合并,系统就会通过自动构建应用并运行不同级别的自动化测试(通常是单元测试和集成测试)来验证这些更改,确保这些更改没有对应用造成破坏。这意味着测试内容涵盖了从类和函数到构成整个应用的不同模块。如果自动化测试发现新代码和现有代码之间存在冲突,CI 可以更加轻松地快速修复这些错误。

1.3. marketplace

marketplace 相当于是 github app 的商城,这边有很多 app 可以用到仓库中用来保证仓库的质量。另外,

github app 的获取除了从 markplace 中获取之外;也可以从外部引入;还可以自己开发,然后引入。

1.4. organization

Github 的组织可以创建多个仓库,可以邀请多个成员加入,可以通过创建 team 来实现成员的权限要求(比如给予某个成员删除某个仓库的权限等等),不同 team 可以负责组织中不同的仓库,并赋予相应的权限。加入组织后的成员可以看到组织的所有仓库和组织中的所有team及其相应的权限。那么需要什么加入哪个team的话,提出申请即可。

个人觉得,组织比个人账户多出的东西就是权限的分配和管理,在个人账户中比如你要删除一个仓库,那么得要登录这个人账户,然后删除仓库。但是在组织中,给某个成员赋予相应的权限之后,这个成员登录自己的 github 账户之后即可对这个组织中的仓库进行删除,而不需要登录组织 owner 的账户。

1.5. issue 跟踪需求和任务

issue 的功能也需要人为启用,这个在仓库的 setting 中可以找到。并且可以设置 issue 的模板,这个模板会存到仓库中。issue 还可以设置标签,标签的管理和指定只有仓库的所有者或者具有相应权限的人才能操作。

1.6. project 来管理 issue 、pull request

project 就是日常所说的看板,但是它这个看板跟相应的 issue 结合了,可以把 issue 直接拖到看板中。可以直接使用 project 来管理 issue,同理也可以管理 pull request。

1.7. release

release 是发行的意思,可以在 release 中发布某个阶段的产品包,也可以把相应平台上的二进制安装程序发布上去(这个可以通过人工上传)。为了方便,可以借助 CI 工具(配置 CI 对应的 yml 文件)将仓库自动打包发布到 release 中去。

1.8. WiKi

github 的 wiki 功能相当于项目的详细指导文档,wiki 支持 markdown,而且 wiki 本身就是一个 git 仓库。所以可以 clone 和 push 等操作。

2. Github 搜索项目-高级

简单的项目搜索只需要输入关键字即可,那么这些关键字将会在所有仓库的名字和 description 等内容搜索。但是这种搜索方式效率不高,那么可以使用 github 提供的高级搜索。使用 github 的高级搜索可以采用 UI 的方式,也可以采用直接在搜索框中加入 prefixes 的方式。

https://img.dawnguo.cn/Git/3_0.jpg

通过 UI 的方式来使用高级搜索的话,点击 advanced search 即可设置一些条件。那么,这边主要是简单介绍一下通过加入 prefixes 的方式来使用高级搜索,更加详细的 prefixes 说明可以点击上图中的 prefixes。高级搜索也可以查看官方文档:https://help.github.com/en/github/searching-for-information-on-github

  • in 关键字指定在哪块内容中搜索

    1
    
    git 程序锅 in:readme	# 在 readme 中搜索,关键字是"git"和"程序锅"
    
  • stars 关键字指定 stars 数的要求

    1
    
    git 程序锅 stars:>1000	# stars 数要求大于 1000,关键字是"git"和"程序锅"
    
  • language 关键字指定语言

    1
    
    language:javascript		# 指定语言为 javascript
    
  • filename 关键字可以搜索某个文件

    1
    2
    3
    
    filename:.gitlab-ci.yml	# 搜索 .gitlab-ci.yml 这个文件
      
    hello filename:.gitlab-ci.yml	# 1.查找满足该文件名,并且含有 hello 关键字的文件,2. 也会查找满足 hello 关键字的仓库
    

当然上述的 prefixes 也支持组合,也就是可以同时加多个条件。

3. Github 参与开源—如何向开源项目提交 pr

  • fork 到自己的仓库
  • git clone 到本地
  • 上游建立连接(这里上游指的是一开始 fork 的那个项目源) git remote add upstream 开源项目地址
  • 创建开发分支 (非必须) git checkout -b dev
  • 修改提交代码 git status git add . git commit -m git push origin branch
  • 同步代码三部曲 git fetch upstream git rebase upstream/master git push origin master
  • 提交pr 去自己github仓库对应fork的项目下 new pull request

pull request 的方式是开源项目保证质量的一种方式,在他人提交了 pull request 之后,对提交上来的代码进行 code review (人工或者自动化工具)之后,才会考虑是否纳入开源项目中。

4. Github 进行团队协作

github 可以让一个团队的成员协作维护一个仓库,那么这个仓库最好是通过 organization 创建的仓库,这样子方便权限的管理和分配。虽然个人也可以创建一个仓库,然后邀请协作者,但是针对团队来说,不太建议。

4.1. 项目内部实施 code review 的

这边讲的更多是项目内部之间怎么进行 code review,也就是一个项目中有多人共同维护,比如有权限可以直接 push 等。那么这种情况怎么实施 code review 呢?首先是给某个分支进行设置保护(比如 master),设置完成之后。团队成员不能直接往保护的分支进行 push,那么可以在另一个没有保护前提的分支下进行 commit 和 push 等操作,之后提交 pull request 申请将这个分支合并到 master 分支中,那么这样的话就会有相关人员 review 了,之后通过相关人员的 review 之后,才会被合并。其实跟前面的参与开源项目方式很像,只是这个是团队的内部成员提交 pull request。

4.2. 分支集成策略

上述提到了相关人员进行 review 之后可以将分支合并到集成分支 master 中。那么相关人员,比如仓库的拥有者,可以采用合并的方式有以下几种:

  • create a merge commit,意思就是把分支和 master 进行合并,产生一个新的 commit
  • squash and merge,将分支上的 commit 合并成一个,然后放到 master 中
  • rebase and merge,把分支上的 commit 依次合并到 master 分支中。

github 仓库的 insight 的 network 将会看见版本树的演进。

4.3. 如何保证集成的质量

可以通过设置 pull request 时的一些要求来保证集成的质量,比如要求必须多少人 code review 之后才会通过 pull request 最终被合并。也可以使用 github 的 marketplace 中一些工具来保证,github app 的获取除了从 markplace 中获取之外;也可以从外部引入;还可以自己开发,然后引入。

4.4. 团队工作流

就是选择适合团队开发的分支模型。需要从以下四个方面考虑

  • 团队人员的组成
  • 研发设计能力
  • 输出产品的特征
  • 项目难易程度

那么开发的分支模型有以下几种:

  • 主干开发—适合大公司

    https://img.dawnguo.cn/Git/5_0.png

  • git flow

    不具备主干开发能力,有预定的发布周期,需要执行严格的发布流程。

    https://img.dawnguo.cn/Git/5_1.png

  • github flow

    master 分支上的是直接可以上线了的

    https://img.dawnguo.cn/Git/5_2.png

  • gitlab flow(带生产分支)

    是 github flow 的完善,也有特性分支,当特性完善之后合并到 master 分支(作为一集成分支),但是 master 分支是不能直接上线的,那么可以加 production 分支。production 分支负责发布的,master 继续负责集成。

    https://img.dawnguo.cn/Git/5_3.png

  • gitlab flow(带环境分支)

    集成之后,通过一道道的环境测试之后,才能够上线的。

    https://img.dawnguo.cn/Git/5_4.png

  • gitlab flow(带发布分支)

    https://img.dawnguo.cn/Git/5_5.png

5. Gitlab 介绍

gitlab 其实和 github 在功能上差别不大,具体功能可以看官网。gitlab 相比 github 的一大优势就是 gitlab 是开源的,虽然要想使用 gitlab 的 ee 版本还是得交钱。另外 gitlab 自带 CI,提供了开发全周期的服务。甚至可以通过 CI/CD 将应用直接部署到云服务器上,比如 gitlab 上修改 CI 的配置文件之后就可以把 gitlab 上的项目直接部署带 AWS 上。