从根本上来讲git是一个内容寻址（content-addressable）文件系统，并在此之上提供了一个版本控制系统的用户界面。
在使用 Git 时，经常会需要克隆仓库，有时候是国内的仓库，有时候是国外的仓库，如果直接强制让终端走代理，那么当克隆国内仓库时，速度可能特别慢。
这个时候其实可以只针对部分域名进行代理设置，而其他域名则不用走代理。
git 对于大家应该都不太陌生，熟练使用 git 已经成为程序员的一项基本技能，尽管在工作中有诸如 Sourcetree 这样牛X的客户端工具，使得合并代码变的很方便。但找工作面试和一些需彰显个人实力的场景，仍然需要我们掌握足够多的 git 命令。
本文整理了一些日常使用 git 合代码的经典操作场景，基本覆盖了工作中的需求。
“变基”命令是git 常用命令中，比较冷门的，一方面是因为这个命令比较“危险”，如果用不好，很有可能会导致代码丢失。另一方面是因为这个命令不像 add、commit、pull、push 属于必须要执行的命令，就算不用它，也能干活。
前言
最近在使用git 时，需要克隆Bitbucket的一个仓库，于是像往常一样打开了iTerm，便放在一边了。
直到一个小时后，我才想起来，想着应该克隆完了，打开才发现百分之一都没下载完。
强大的长城技术对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 工具
如果你有幸正在使用代理，懂得如何科学上网的话，那么访问GitHub、Bitbucket对你来说应该不在话下。
从源代码托管服务平台下载项目最简单的方法就是使用一款图形化界面（GUI）的Git工具。
使用GUI工具方便之处就在于，可以在设置中直接配置是否使用代理。或者直接将代理配置尾系统代理。
http/https proxy
如果你跟我一样，更喜欢使用原生的git命令，喜欢使用在命令行下操作的那种感觉，那么你也可以在命令行下直接配置代理。
这里也有两种方式，根据实际情况自行选择。
http
1 | $ git config --global http.proxy http://127.0.0.1:1087 |
或者直接编辑~/.gitconifg文件
1 | # vim ~/.gitconfig |
socks5
1 | $ git config --global http.proxy socks5://127.0.0.1:1086 |
其中，1087、1086分别是你本地机器的 http、socks5代理的端口号。
另外，如果想取消设置，可以输入以下命令：
1 | $ git config --global --unset http.proxy |
配置完成后，重新 clone一遍，可以看到速度得到了极大的提升。
注意⚠️
上面这种配置方式仅适用于 https协议，如果你在clone时选择ssh协议，那么速度仍然会很慢。
替换域名
如果你觉得上面的方式太麻烦了，或者是你没有代理，那么可以试试下面这种方式。
这种方式简单暴力，替换就可以直接使用，使用规则如下：
1 | # 原地址 |
只需要在github.com后面追加一个.cnpmjs.org就可以了。
以上就是git clone太慢时的各种解决办法。
参考链接
这片文章主要用来讲解git pull命令的一些细节。
虽然每天都在使用Git，但是有些命令太久不使用，还是会忘记，所以这篇笔记的目的就是整理那些Git 常用命令。
最近遇到了一个Git Push 相关的问题，同事不小心把一些错误代码提交到仓库了。
如果每个人直接更新的话，会导致错误代码也更新到本地了。
这个时候想要避免这种情况的发生，唯一可以做的就是将那些错误代码直接覆盖掉。
其实关于这个问题，老早都想整理了，只是一直没有腾出空来，最近刚好有空，索性整理了下。
这里就不过多介绍什么是Git了，本文的重点是Commit Log，如果还不清楚Git是什么，可以看一下我的Git系列的其他笔记。
为什么要关注提交信息
- 加快
Reviewing Code的过程 - 提醒自己或他人，某个提交具体增加了什么功能，改动了哪些地方
- 提高项目的整体质量
Angular 规范的 Commit message 格式
这种格式（规范）是我目前觉得相对其他格式（规范）而言，最容易接受、上手的一种。
其核心是每次提交，Commit message 都包括三个部分：Header，Body 和 Footer。
1 | <type>(<scope>): <subject> |
其中，Header 是必需的，Body 和 Footer 可以省略。
Header
Header 部分只有一行，包括三个字段：type（必需）、scope（可选）和 subject（必需）。
type 用于说明 commit 的类别，只允许使用下面 7 个标识。
- feat 新功能（feature）
- fix 修补 bug
- docs 文档（documentation）
- style 格式（不影响代码运行的变动）
- refactor 重构（即不是新增功能，也不是修改 bug 的代码变动）
- test 增加测试
- chore 构建过程、辅助工具的变动
- perf 提高性能
- typo 打字错误
scope 用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。
subject 是 commit 目的的简短描述，不超过 50 个字符。
Body
Body 部分是对本次 commit 的详细描述，可以分成多行。
Footer
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 | docs: add FAQ in readme file |