GitHub与各代码托管平台比较

一.优缺点

• 优点&＃xff1a;

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

• 缺点&＃xff1a;

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

二.托管限制

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

三.介绍与使用

• 介绍&＃xff1a;

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

• 使用&＃xff1a;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一.优缺点

• 优点&＃xff1a;

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

• 缺点&＃xff1a;

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

二.托管限制

三.介绍与使用

• 介绍&＃xff1a;

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

• 使用&＃xff1a;

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

一.优缺点

• 优点&＃xff1a;

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

• 缺点&＃xff1a;

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

二.托管限制

无限制的私有仓库个数&＃xff0c;无限制磁盘空间

三.介绍与使用

• 介绍&＃xff1a;

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

• 使用&＃xff1a;

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

一.优缺点

• 优点&＃xff1a;

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

• 缺点&＃xff1a;

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

二.托管限制

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

三.介绍与使用

• 介绍&＃xff1a;

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

• 使用&＃xff1a;

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

一.优缺点

• 优点&＃xff1a;

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

• 缺点&＃xff1a;

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

二.托管限制

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

三.介绍与使用

• 介绍&＃xff1a;

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

• 使用&＃xff1a;

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

• 国人使用量&＃xff1a;

  GitHub >> GitLab > Bitbucket&＃xff08;国外代码托管平台&＃xff09;

  Gitee >> GitCafe&＃xff08;国内代码托管平台&＃xff09;

• 国外使用量&＃xff1a;

  GitHub > Bitbucket > GitLab

• 私有库限制方面&＃xff1a;

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

  专注于私有库的独立开发推荐&＃xff1a;

  GitHub > Bitbucket > GitLab > Gitee > GitCafe

• 国内访问速度&＃xff1a;

  Gitee &＃61; GitCafe > GitHub > Bitbucket >&＃61; GitLab

• 开源代码丰富度&＃xff1a;

  GitHub >> GitLab > Bitbucket > Gitee >> GitCafe