GitHub 与各代码托管平台比较

GitHub

一.优缺点

• 优点：

  几乎拥有全世界最多的开源代码，有众多非常知名的开源项目，也是本文中几个代码库中最出名的一个。支持多人共同完成一个项目，bugs 可以公开。代码开源这一块做的非常好。据说现在可以免费建私有仓库了，并且仓库数量无限制，但是唯一限制的是免费的私有仓库只能同时允许最多三个协作者，这对独立开发者和小开发团队来讲简直是福音。对 markdown 很友好，

• 缺点：

  只提供英文，对于英文不好的人来说可能使用有障碍。只支持 git 格式代码托管，不对 csv，svn，hg 等进行支持。私有库有一点限制，就是对协作者的数量进行了限制。国内对 github 的访问速度可能比较慢。保护分支是收费的

二.托管限制

项目容量限制为 1G，上传文件限制 100M，公有库和私有库数量不受限制，私有库协作者数量限制 3 人

三.介绍与使用

• 介绍：

  分布式管理系统，解决了 svn 的缺点，若任何一个协同工作的机器有故障，可以用任何一个镜像出来的本地仓库进行恢复。与国外的 SourceForge，Google Code 或者中国的 coding 不同，GitHub 独特卖点在于在一个项目上进行分支操作的简单性，为项目贡献代码的操作非常的简单，仅仅就是先点击站点的“fork”，然后将修改加入到 fork 出来的分支中，最后通过组内的“pull request”向项目负责人申请代码合并

• 使用：

  • github 项目概括：右上角我的账户中“Your profile”可以查看你的项目概况

  • Pull requests：上方的“Pull requests”可以用来合并修改的代码，具体是：如有个仓库 A，你想往其中贡献代码，首先要 fork 这个仓库出新的分支，然后你的 github 下多了一个 A2，然后你再 A2 中进行修改 add，commit，push，最后你希望网上的仓库 A 也合并上你的修改工作，你可以在 github上发起一个叫 Pull Request 的请求，司仪是说仓库 A 的所有者从你的 A2 合并分支，你这样就相当于为项目 A 贡献了修改。

  • Issues：上方的“Issues”可以用来跟踪程序 bug，实际上 issues 可以用来跟踪任何你想要跟踪的任务，如待解决的的问题，待办事项，或将要完成的任务目标等

  • github 中 Repositories 和 Projects 关系：一个 repository 仓库可以管理多个工程 project，由于我们个人使用时在 github 中往往是创建一个仓库，在其中存放项目，单个项目会放进一个仓库中，不同项目常常是把他们区分仓库放置

  • Watch/Star/Fork：watch github 中的某个项目之后，可以实现追踪该项目的动态，在自己 github 中会出现该项目的动态信息。star github 中的某个项目之后，表示收藏该项目，可以在自己 github 中的收藏一页中找到该项目，并且某个项目有多少 star 也是记录该项目热门程度的指标。fork 表示分叉到自己的 github 仓库，常用此选项来将 github 上好的项目分叉到自己的 github 中进行开发，之后再 pull request 进行合并到原 github 项目中实现代码提交，某个项目被 fork 的次数越多表示该项目参与开发的人越多

  • Wiki：是一种网络上开放且可供多人协同创作的超文本系统，其实维基百科，csdn 都用的 wiki 超文本系统，其中可以使用 markdown 语法来编辑，github 中也是如此。github 中进入某个仓库的项目中，进入 wiki 标签页中可以查看该项目的描述文档等等。右边那个 Insights 标签可以看到项目中代码合并提交情况和次数

  • SSH：一般大家 clone 项目到本地时经常使用 https url 来 clone，也有较少人使用 SSH url 来 clone 到本地，之所以 https 用的多是因为它方便，而 SSH clone 需要在 clone 之前先配置好和添加好 SSH key，因此你若是想用 SSH url clone 的话你必须是项目的拥有者，因为只有你是拥有者时，才能添加 SSH key。https clone 随意哪个人的项目，push 时候需要验证用户名密码；SSH 需要你是项目的所有者或管理员，然后先添加 SSH key 之后才能进行 clone，push 的时候不需要输入用户名密码，若配置的 SSH key 设置了密码，则需要输入密码，

  • 一些规范注意：尽量项目放上去的时候使用的直接目录就可以看到 src，而不是下级目录。仓库名与项目名一致。

  • 开源项目提交代码方式：若是想对别人好的项目进行添加修改进行多人协作开发，可以 fork 将 github 上好的项目分叉到自己的 github 中进行开发，之后再 pull request 进行合并到原 github 项目中实现代码提交。更详细描述是，你先在 github 上找到比较好的开源项目，然后把它 fork 到自己 github 仓库中，然后从自己账号 clone 该项目到本地（若从原作者项目下 clone 到本是没有权限推送修改的），然后在本地你可以新增功能，然后推送到自己远端仓库，若希望该项目原作者能够合并入你的修改，可以发起一个 pull request，当然对方是否接受你的修改要看对方的审核结果。现在修改并入了原项目，想把 fork 的仓库删除，可以在项目的 Settings 中点击 Delete this repository 即可

  • 自己项目添加成员多人协作方式：若有个自己的开源项目，github 用户都可以拷贝但是对仓库代码没法进行修改提交，除非 fork 提交之后你这边需要同意。可以通过在仓库项目中的 Settings 标签页中，点击左侧的 Collaborations，然后搜索 github 用户，来进行添加项目的协作者，这样该项目协作者就可以 push 代码到项目中去了

  • 多人协作模式：git 主分支默认是 master，自动创建，默认本地与远程 master 统一，主分支用来发版，日常开发在另一个 develop 分支上进行，开发好之后再合并到 master 分支。github 上的多人协作是如何进行的呢？github 上通过 Settings 中的 Collaborations 添加多人协作者，假如有 A 和 B 两个协作者，他们分别把项目 clone 到本地仓库之后，本地都会产生一个 master 分支，远程只有 master 和 develop 分支（若远程只有 master 分支，没有 develop 分支要么在远端切出 develop 分支，要么本地在 checkout -b develop 之后推送到远程，这样远程也产生了 develop 分支），他们会执行命令 git checkout -b develop origin/develop（这个命令的意思是本地创建 develop 分支并且换到 develop 分支并且让本地 develop 跟踪远程 origin/develop）这样本地就有了 develop 分支，相当于是远端 copy 下来的最新的，然后 A 或 B 成员需要开发什么新功能或者修改项目的什么 bug，可以再在本地切功能分支或者 bug 分支，并跟踪远端 origin/deveop 分支，git checkout -b function origin/develop（没有跟踪 master 是因为 master 可能和 develop 版本不一致，develop 是用来开发代码的分支，版本领先），切好分支之后可以在本地 function 分支进行开发了，开发完后就可以切回到 develop 分支，然后合并到 develop 分支了，接着将本地 develop 分支推送到远端 origin/develop 即可，注意一个好习惯是把本地功能或者 bug 分支删除掉还有把本地 develop 分支也删除掉，以后要用在切分支跟踪远端即可，最后 github 上该项目的管理员可以在每次发版之前将 github 上项目每个周期迭代的 develop 分支合并到 master 分支，这时 develop 分支版本和 master 分支版本一致，develop 版本不超前。以后 A 或 B 成员每次用的时候都先 pull 一下最新 master，然后像前面那样切 develop，切功能或者 bug 分支。多人协作可以弄三个分支，分别是 master 主分支，develop 迭代开发分支，具体需求的功能分支，master 用来发版使用即最终版，develop 用来将多人开发的代码统一合并到 develop 中，用完在本地需要删掉，具体需求的功能分支是从 develop 切出来的，不同成员自己创建不同功能分支来开发具体代码，之后需要合并到本地 develop 之后再提交到 origin/develop 上去，要是仅仅是自己一个人维护自己的项目，要是怕麻烦不愿意弄这三类分支，可以只弄两类分支，master 和 develop，每次在 develop 分支开发代码，提交到远端 origin/develop，每次在把 origin/develop 合并到 master 即可

  • 案例分析：这里有个案例，提交发生冲突的案例，假如 A 和 B 需要开发某一需求，其中涉及到某一共同模块的代码，A 在当天 10:00 拉取了 origin/develop，同时从 develop 切了个 functionA 分支来进行需求开发，在当天 10:05 B 也拉取了 origin/develop了，同时 B 在本地也弄了个 functionB 功能分支进行开发，并且在 10:25 B 率先在本地的 functionB 分支上开发完毕，把代码合并到 develop 再推送到远程 origin/devleop，B 最后 push 成功，在 10:30 的时候 A 在本地的 functionA 分支上也开发完了代码，他把 functionA 合并到本地 develop 成功，再把 develop push 到远程 origin/develop 结果发现却是 error，这是因为 A 和 B 拉取的远端 origin/devleop 都可以看成拉取的某一固定结点的代码，暂且将该结点叫做 α 结点，由于二者修改的代码有重合的地方，B 率先 push 到远端 origin/develop 是没有问题的，此时 origin/develop 所在的结点可不再是在 α 结点了，现在是在 α → β，现在是在 β 结点，β 结点与 α 结点不同在于 β 结点新增了代码修改，这个修改的代码模块是 A 和 B 成员都需要修改的模块，但是二者修改是有别的，10:25 B 成功 push 到远端了，现在 origin/devleop 是在 β 结点，到了 10:30 的时候A 也准备提交代码了（实际上 A 在本地的 develop 一直是 α 结点，因为 A 没有在 10:25 时候重新拉取 origin/devleop 分支，相当于 A 在 10:00 ~ 10:30 之间一直在 α 结点进行开发）他再提交上去是 error，他希望 origin/develop 从结点 α 变为 γ，但 A 殊不知他在本地修改代码还没有提交上去这期间 B 已经把 origin/develop 从结点 α 变为了 β，这时提交会显示 error，α 没法跨过 β 变为 γ，除非二者修改提交的部分不同，假使二者修改提交的部分不同 A 最后就不会显示 error，可以成功扩过 β 变为 γ 结点，这很像一个线性结构 α → β → γ（β 和 γ 的修改相较于 α 是不同模块代码的修改），可实际上 A B 二人修改的模块代码是同一块模块代码，这就很像一个倒立的二叉树结构

------------β--------γ

--------------↖ ↗

----------------α

（β 和 γ 相较于 α 修改是同一代码模块的修改，因此 α 不可能视 β 修改于不见直接变成 γ 结点，因为系统自己也不知道到底是选择到 β 结点还是选择到 γ，所以只好后提交的吃亏了，若 A 进行了 -f 强制提交操作，那么 B 提交的修改就白写了，α 变成了到 γ 结点，github 中除非特殊情况，禁止 -f 操作）
10:30 A push 之后电脑屏幕显示 error，又不能 -f 来覆盖 B 的代码，A 很是头疼，其实可以这样，A 先在本地的 develop 分支下 git pull（git pull 默认更新的是当前本地分支，依据被跟踪的远端分支来进行更新），会显示 merge conflict，这是肯定的，因为你本地的 develop 相当于从 α 结点变到了 γ 结点，而远端想要 pull 下来的是 β 结点，然而 β 和 γ 本身就是有冲突的，它还会提示你需要手动解决冲突之后再提交 fix conflicts and then commit the result.并展示给 A 冲突的文件，A 可以使用 git status 来比较详细的查看冲突相关的信息，这时候会显示，你现在在 develop 分支上，你的 develop 分支和 origin/develop 分支是分岔的，还会显示两个分岔较原始版的不同点数量，即你想要 pull 下来的 β 版和你本地的 γ 版两个版本相对于 α 版 commit 修改不同点的数量，可以使用 cat 冲突文件名 这样的命令来查看冲突文件中不同分支修改提交的内容，手动修改冲突文件再重新提交到 origin/develop

GitLab

一.优缺点

• 优点：

  国内 IT 公司对 GitLab 的私有库有非常大的使用量。有较强集成 ci/cd 功能，也支持自家 omnibus 懒人包 docker 安装，gitlab 集成 jenkins 和自己设置的 webhook 也很方便。对私有库完全免费

• 缺点：

  gitlab 是 github 的复制品，但是似乎更重一点。gitlab 拓展功能需要收费。gitlab 账号的注册很头疼，因为注册需要验证，这个验证是谷歌的人机验证，所以需要魔法上网来完成 gitlab 的注册，感觉 gitlab 比 github 还要慢

二.托管限制

三.介绍与使用

• 介绍：

  具有 wiki 和 issue 跟踪功能，由 Ruby 写成，使用了 Web 框架 RubyonRails，后来一部分使用 Go 进行了重写，基于 MIT 代码发布协议，需要 gitolite 协同工作。一般企业有自己企业版的 gitlab，你自己在网上创建的 gitlab 账号密码和你在企业中用到的 gitlab 账号密码还不是同一套，自己注册还需要魔法上网

• 使用：

  • 概述:和 github 大同小异，与 github 相比依旧有熟悉的 Issues 和 Merge requests，依旧可以看到 Profile 以及编辑你的状态等，与 github 比较来讲它更注重私有仓库部分，限制远没有 github 多，而且很好集成了 CI/CD，在创建新项目的时候就可以看到 CI/CD for external repo 这样的标签页。目前本人企业上用企业的 gitlab，平常都是用 github

Bitbucket

一.优缺点

• 优点：

  对于小团队使用可以使用无限量的免费存储库，不限容量，但是限制 5 名成员。集成 Jira 工具，通过集成的错误跟踪组件，Jira 自动更新有关检测到的问题的信息。提交大文件速度很快。拥有灵活的权限管控，可自定义域名，支持 wiki 等

• 缺点：

  使用群体和代码量可能不如 GitHub，国内使用私有仓库的托管平台可能不及 GitLab。系统不够稳定

二.托管限制

无限制的私有仓库个数，无限制磁盘空间

三.介绍与使用

• 介绍：

  采用 Mercurial 和 Git 作为分布式版本控制系统，同时提供商业计划和免费账户，同时支持 http/ssh，支持 wiki，权限管控较为灵活， RSS 修改记录输出

• 使用：

  • 概述:与 github 类似有 Issues，Pull requests 等其他。推荐小型团队或者独立开发者使用 Bitbucket 代码托管平台

Gitee

一.优缺点

• 优点：

  比国外代码托管平台访问速度快很多，因为是国内代码托管平台。支持 issue，wiki，私有仓库免费使用，保护分支是免费的。可以在线 IDE，仓库可以自动备份，禁止 git 强推，支持访问 IP 限制，敏捷开发管理，自动代码质量分析，代码克隆检测，自动生成 Javadoc，关联微信。国内代码托管平台中使用应该是最多的

• 缺点：

  每个仓库有 1G 的容量限制，把 Unity 项目弄上去一下就超了

二.托管限制

限制 1000 个仓库，不限制公有私有，单个仓库容量限制为 1G，单文件大小限制 100M（与 github 很类似），用户总仓库容量 5G，公有仓成员数量不限，私有仓成员数量 5 人上限

三.介绍与使用

• 介绍：

  码云，国内非常好用的 git 代码托管平台，私有免费，功能限制上类似于 github 平台，应该是国内托管平台中使用人数最多的一个

• 使用：

  • 概述:同样也是 GitHub 类似，感觉功能上比 GitHub 少了很多，但确实对于国人来讲非常好用，还有个引人注意的几点是，它支持绑定 GitHub 并且从 GitHub 上导入项目，二个是每年它会进行最火的 Gitee 项目排行，可以让更多用户使用热门的 Gitee 项目，再就是全面支持中文，国内用户数量也是较多的，私有仓库限制比较少，这些都是值得注意的地方

GitCafe

一.优缺点

• 优点：

  比较新颖，有较好的用户体验，小巧便捷精简，国内访问速度快

• 缺点：

  新成立不久，比较小型，代码量不多，更多功能需要在企业版付费使用，普通会员仓库容量为 128M，限制 5个项目

二.托管限制

依据会员等级不同而定，最低普通会员，限制 5 个项目，每个项目 128M 的仓库容量

三.介绍与使用

• 介绍：

  coding.net，基于代码托管服务打造的技术协作与分享平台，该平台祈愿是希望解决国内 IT 行业以及 IT 教育领域诸多问题，代码托管仅仅是核心业务之一。gitcafe 与一般托管平台按月付费的方式不同，它采用按天、私有项目个数以及项目协作人员个数来进行收费，其还引入了虚拟货币——gitcoin 来支持付费，与人民币汇率比是 30:1

• 使用：

  • 概述:此平台给我最大的感受就是非常精巧，但是限制颇多，不论是容量还是私有库方面，功能也偏少，名气也远远不及前面几个平台，是最近几年显现的代码托管平台，主要功能差不多，它也有它吸引人的地方，但是博主可能不推荐使用该平台

小总结

• 国人使用量：

  GitHub >> GitLab > Bitbucket（国外代码托管平台）

  Gitee >> GitCafe（国内代码托管平台）

• 国外使用量：

  GitHub > Bitbucket > GitLab

• 私有库限制方面：

  貌似现在这几个代码托管平台都可以免费建自己的私有库，但是精致的 GitCafe 容量最小并且私有库限制个数，然后再是现在 GitHub 私有库限制协同者 3 人，其他三个代码托管平台对私有库限制比较少了

  专注于私有库的独立开发推荐：

  GitHub > Bitbucket > GitLab > Gitee > GitCafe

• 国内访问速度：

  Gitee = GitCafe > GitHub > Bitbucket >= GitLab

• 开源代码丰富度：

  GitHub >> GitLab > Bitbucket > Gitee >> GitCafe