Aaronlam

互联网发展至今日这个样子，TCP 协议脱不了这个“干系”。TCP 协议已然成为我们日常网络生活中必定会接触到的网络协议，因为绝大多数的网络连接都是建立在其之上。而学习过计算机网络基础或对 TCP 协议稍有了解的人应该都知道，TCP 协议在其连接建立之前需要经过三次握手（three-way handshake）。

而对于 TCP 协议三次握手的建立过程，我相信很多 IT 人在准备面试时都一定会先再熟悉一番。但是一般都很少会去深究其为什么需要握三次手？我相信很多人应该都没有办法回答这个问题。所以今天在这里就让我们稍微深究一下其原因，而在深究前，我想先抛出一个对于三次握手错误的类比，这个类比错误的误导了很多人，也包括我在内。而这个错误的类比如下：

1. 你好，请问在不在？
2. 我在的，请问你还在吗？
3. 我还在！

说这是一个错误的类比的原因在于，它只以片面的以相似性解释了三次握手的表层含义，而并没有把其正正的原因从其表面展露出来。而这种类比带来的解释往往就只有这样片面的相似性，它只有在我们想要通俗易懂地介绍事物的特性时才能发挥较大的作用。而文章后面的篇幅会侧面的解释该类比存在的问题，好！那我们就继续往下。

由于我们公司内部的前端项目越来越多并且迭代速度越来越快，项目里的业务系统也精细的进行了不同的划分，那么这些项目之间的公共代码以及公共组件的提取、维护、管理问题就也愈显的突出。所以，最近都在进行公共库的维护以及公共组件的提取工作，然后再把这些公共库和公共组件库以依赖包的形式进行管理，同样的我们使用了 SemVer 来进行版本号的规范化，最后再以依赖包的形式进行发布。这就让我们可以把这些单独“拎出来的代码”能够以 npm install 或 yarn add 的形式来进行依赖包安装，然后再引入到实际用到的每个项目里，这样一旦这些公共库或公共组件库更新了，就不用在每个项目里一份一份的复制粘贴了，直接 npm update 或 yarn upgrade 了事。

但是，对于一些公共库的代码可能会涉及到比较核心的业务逻辑，就导致我们没办法把这些库代码的依赖包以 npm 包的形式发布到公网的 npm 仓库；同时，由于每次前端项目进行依赖包安装时，其安装的速度都依赖于网络以及第三方镜像。所以，这就迫切的需要有一个公司内部的 npm 私有仓库了，也就是 npm 私服。在我研究了目前 npm 私服的几乎所有搭建方式后，总结下来总共有以下几种：

付费：

1. MyGet：9 刀每月，两个账号，1GB 空间
2. NPM Org：每个账号每月 7 刀

免费：

1. DIY NPM
2. CNPM
3. Nexus
4. Sinopia
5. Verdaccio

首先排除付费，根据搭建方式和易用程度来选本来是选择 Sinopia 的，因为其搭建十分简单友好，基本就是傻瓜式的。不过到其 GitHub Repo 页面看到貌似已经放弃维护很多年了，然后再深入调查发现有一群人出了个分支，而这个分支就是 Verdaccio。然后还发现 Verdaccio 延续了 Sinopia 的简单便捷，并且这个库也在积极维护中，看起来就比 Sinopia 靠谱一点。最后就果断的选择了 Verdaccio 来搭建公司内部的 npm 私服。

不过如果公司内部有 Java 技术栈团队的可以尝试一下 Nexus，因为看到他貌似也可以进行 maven/gralde 仓库的统一管理。而我们公司虽然也有 Java 技术栈的团队，但是由于我们部门后端是 .Net 技术栈，遂放弃！

使用 Git 进行项目的版本管理，的确是能让项目代码更加的受控。但是如果能有清晰的 commit 记录以及描述，那将更是会锦上添花。在需求正常开发完后，有时难免会过于兴奋手滑敲错 commit 的描述。但如果对于不经常手滑的同学来说，可能还没研究过如何修改 commit 的描述。所以今天，我就想通过这一篇文章简单的记录一下 commit 描述的修改过程，顺便给自己留作回顾的作用。

修改 commit 描述分为以下两种情况，但这两种情况步骤基本相同，只是第二种需要在最后多加一步操作：

1. 还未将代码 push 到远程仓库
2. 已将代码 push 到远程仓库