Boo's Blog

Stay foolish, Stay hungry

前言

最近在使用git 时,需要克隆Bitbucket的一个仓库,于是像往常一样打开了iTerm,便放在一边了。
直到一个小时后,我才想起来,想着应该克隆完了,打开才发现百分之一都没下载完。

git clone 失败

强大的长城技术对GitHub、Bitbucket 这类源代码托管服务平台网开一面,并没有像Google、FaceBook那样直接一刀切,但是它做了严格的限速,这种折磨简直比无法访问更难受。

上图中git clone的速度从来没有超过 10k/s,这也就意味着一个 100M 的项目,需要近三个小时才能下载完,而且由于网络的不稳定性,下载过程中偶尔会出现断开连接的情况,由于git clone 不支持端点续传,这就会导致前几个小时的下载量完全浪费掉了,只能重新开始下载。

这篇文章主要用来介绍几种方式可以快速的克隆远程仓库。

浅复制

git clone默认会下载项目的完整历史版本,如果你只关心代码,而不关心历史信息,那么可以使用 git 的浅复制功能:

1
$ git clone --depth=1 https://github.com/bcit-ci/CodeIgniter.git

--depth=1 表示只下载最近一次的版本,使用浅复制可以大大减少下载的数据量,例如,CodeIgniter 项目完整下载有近 100MiB ,而使用浅复制只有 5MiB 多,这样即使在恶劣的网络环境下,也可以快速的获得代码。

如果之后又想获取完整历史信息,可以使用下面的命令:

1
$ git fetch --unshallow

或者,如果你只想下载最新的代码,你也可以直接从远程仓库下载打包好的zip文件,这会比浅复制更快,因为它只包含了最新的代码文件,而且zip是压缩文件。但是很显然,使用浅复制会灵活一些。

GUI 工具

如果你有幸正在使用代理,懂得如何科学上网的话,那么访问GitHubBitbucket对你来说应该不在话下。

从源代码托管服务平台下载项目最简单的方法就是使用一款图形化界面(GUI)的Git工具。

使用GUI工具方便之处就在于,可以在设置中直接配置是否使用代理。或者直接将代理配置尾系统代理。

http/https proxy

如果你跟我一样,更喜欢使用原生的git命令,喜欢使用在命令行下操作的那种感觉,那么你也可以在命令行下直接配置代理。

这里也有两种方式,根据实际情况自行选择。

http

1
2
$ git config --global http.proxy http://127.0.0.1:1087
$ git config --global https.proxy https://127.0.0.1:1087

或者直接编辑~/.gitconifg文件

1
2
3
4
5
6
# vim ~/.gitconfig

[http]
proxy = http://127.0.0.1:1087
[https]
proxy = https://127.0.0.1:1087

socks5

1
2
$ git config --global http.proxy socks5://127.0.0.1:1086
$ git config --global https.proxy socks5://127.0.0.1:1086

其中,10871086分别是你本地机器的 httpsocks5代理的端口号。

另外,如果想取消设置,可以输入以下命令:

1
2
$ git config --global --unset http.proxy
$ git conifg --global --unset https.proxy

配置完成后,重新 clone一遍,可以看到速度得到了极大的提升。

git clone 成功

注意⚠️

上面这种配置方式仅适用于 https协议,如果你在clone时选择ssh协议,那么速度仍然会很慢。

替换域名

如果你觉得上面的方式太麻烦了,或者是你没有代理,那么可以试试下面这种方式。

这种方式简单暴力,替换就可以直接使用,使用规则如下:

1
2
3
4
5
# 原地址
$ git clone https://github.com/996icu/996.ICU.git

# 替换成
$ git clone https://github.com.cnpmjs.org/996icu/996.ICU.git

只需要在github.com后面追加一个.cnpmjs.org就可以了。

以上就是git clone太慢时的各种解决办法。

参考链接

Git Clone 太慢怎么办?

其实关于这个问题,老早都想整理了,只是一直没有腾出空来,最近刚好有空,索性整理了下。

这里就不过多介绍什么是Git了,本文的重点是Commit Log,如果还不清楚Git是什么,可以看一下我的Git系列的其他笔记。

为什么要关注提交信息

  1. 加快Reviewing Code的过程
  2. 提醒自己或他人,某个提交具体增加了什么功能,改动了哪些地方
  3. 提高项目的整体质量

Angular 规范的 Commit message 格式

这种格式(规范)是我目前觉得相对其他格式(规范)而言,最容易接受、上手的一种。

其核心是每次提交,Commit message 都包括三个部分:Header,Body 和 Footer。

1
2
3
4
5
<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>

其中,Header 是必需的,Body 和 Footer 可以省略。

Header 部分只有一行,包括三个字段:type(必需)、scope(可选)和 subject(必需)。

type 用于说明 commit 的类别,只允许使用下面 7 个标识。

  • feat 新功能(feature)
  • fix 修补 bug
  • docs 文档(documentation)
  • style 格式(不影响代码运行的变动)
  • refactor 重构(即不是新增功能,也不是修改 bug 的代码变动)
  • test 增加测试
  • chore 构建过程、辅助工具的变动
  • perf 提高性能
  • typo 打字错误

scope 用于说明 commit 影响的范围,比如数据层、控制层、视图层等等,视项目不同而不同。

subjectcommit 目的的简短描述,不超过 50 个字符。

Body

Body 部分是对本次 commit 的详细描述,可以分成多行。

Footer 部分只用于不兼容变动和关闭 Issue。

总结

本来我自己一直使用的方式就是:git commit -am "fix login bug",虽然并没有绝对的对错,但这显然不是最好的方式。

这种东西并没有强制性的规定,只要团队之间约定好,然后按照这个约定协作就好了。

所以我觉得在团队之间commit时,可以不用完全按照Angular 规范的Commit message格式去提交,可以按照以下约定来执行。

  • commit时,只用保留 Header 部分就好。
  • pull request时,才需要 Header、Body、Footer 这三部分。

另外commit时需要注意以下几点:

  • 创建短小而明确的commit,一句话说清楚。
  • 一个小改动对应一次commit,不建议一大堆改动,一次commit
  • 如果添加的代码会使项目发生极大的变化,那么需要及时更新remade文件以向他人说明此次更改。

最佳实践

1
2
3
docs: add FAQ in readme file
feat: increase user login function
fix: fix user login bug

参考链接