netty源码分析(四)Netty提供的Future与ChannelFuture优势分析与源码讲解
上一节我们讲到netty启动服务类AbstractBootstrap的doBind的方法:
上一节我们讲到netty启动服务类AbstractBootstrap的doBind的方法:
上一节说到EventLoopGroup只是对bossGroup和workerGroup的一些初始化,包括线程数量,执行器(命令模式),我们的服务端接下来使用ServerBootstrap对bossGroup和workerGroup进行了包装,整个过程是一个方法链的调用过程,每个方法返回调用者本身:
上一节说到NioEventLoopGroup 的初始化,到了他的父类MultithreadEventExecutorGroup的构造器:
首先我们使用netty建立一个服务端和客户端,功能是相互之间发消息,代码
我们把服务端的主要代码贴出来:
我们新建三个分支分别是master、dev、test,之后在dev分支的test.txt文件新建2个提交,在test分支的test.txt文件新建2个提交。
切换到test分支,然后执行git rebase dev 我们要将dev分支的提交应用到test分支:
rebase:变基,意即改变分支的根基
从某种程度来说,rebase和merge可以完成类似的工作,不过2者的工作方式有显著的差异。
cherry-pick:现在有哦2个分支和dev和master,我们在dev下边进行了2此提交,我们这个时候发现这个2个提交不应该发生在dev分支,应该在master分支进行,于是我们把dev当前修改的内容的文件被备份到其他的地方存储,然后将dev回退到之前没有修改的状态,紧接着切换到master分支,将备份的文件覆盖master上对应的文件,完成修正,这种方法能解决问题,但是效率太低了,并且容易出现问题。此时我们可以使用cherry-pick将这2次提交应用到master分支。
演示:
git submodule弊端:
这篇文章指出了submodule的一些问题: http://www.cocoachina.com/industry/20130509/6161.html
创建裸库:
girl init –bare
在执行git gc之前我们看一下.git目录的一些信息:
refs目录下边有三个文件夹: