Git Rebase


分支合并,有两个选择,一个是 merge,另一个是 rebase。

  1. merge 和 rebase 合并后的结果是一模一样的,形象的说,二者是殊途同归。
  2. 使用 rebase 后的 commit 与之前的 commit,它们的 SHA-1 值不同,Git 会把它们看成两次提交。

现在社区中推荐的主流 Git 合作方法,也是利用 Rebase 命令,即 Fork 一个代码库后,保留一个 remote 分支用来跟近主库进度,另开一个 feature 分支来打 patch,当 patch 打好后,在本地同步一下 remote 分支上的代码,保持与主库一致,如果在你打 patch 这段时间,主库发生了变化,那么你就需要在本地预先做一次 rebase 操作,以保证你的改动是构建在主库最新代码之上的。这其实相当与你帮助作者在本地处理好了冲突,这样作者再合并你的代码时候,也就能比较轻松了。换个角度,其实使用
rebase 这个过程也是一个自我检查的过程,可以强制你对改动进行 Review,从而减轻贡献者和所有者之间的工作量。因为没有人比你更熟悉你的代码。

git pull —rebase,这个命令在实际使用中的出场率还是很高的。
我们先从 git pull 说起,git pull 完整的应该是 git fetch + git merge FETCH_HEAD,默认时候 git pull 会先拉取代码,再进行 merge,上面说了使用 merge 会多出一条合并的 commit 以及一条分支线来,如果 commit 和 merge 频繁的话,可能会出现下图这样的情况,但是 rebase 则不同,其会保持线性,这样提交记录看起来就会整洁许多,使用 —rebase 就是这个意思用 git rebase 取代。
git-rebase-1.png

阅读全文

Git 删除分支


查看已有的本地及远程分支:

git branch -a

删除远程分支:

git push origin --delete Su-modify

删除后,可再次查看分支情况:

git branch -a

删除本地分支:

git branch -d Su-modify

若分支有修改还未合并,会提示你还没合并。
强行删除本地分支:

git branch -D Su-modify
阅读全文

github fork 同步源的更新


首先要先确定一下是否建立了主 repo 的远程源:

git remote -v

如果里面只能看到你自己的两个源(fetch 和 push),那就需要添加主 repo 的源:

git remote add upstream URL
git remote -v

然后你就能看到 upstream 了。

如果想与主 repo 合并:

git fetch upstream
git merge upstream/master
阅读全文

Git 放弃本地修改 直接 pull 代码


git reset --hard HEAD    
git clean -f -d    
git pull

先 reset 然后清空
同时可以解决如下问题:

error: Your local changes to the following files would be overwritten by merge:
        test/main.go
Please, commit your changes or stash them before you can merge.
阅读全文

深入浅出 Kafka(四)Kafka 简介


Kafka 特性:

  • 具有近乎实时的消息处理能力 顺序读写磁盘
  • 支持批量读写磁盘 并且会对消息进行批量压缩
  • 支持消息分区 可以在线增加分区,为每个分区创建多个副本,只会有一个 Leader 负责读写,其他副本与 Leader 同步。
  • 支持水平扩展

阅读全文

深入浅出 Kafka(三)稀疏索引与稠密索引


聚集索引:在一张表中,如果一个索引有如下特性,数据的物理顺序与键值的逻辑顺序相同。

稠密索引和稀疏索引都属于聚集索引。

1.稠密索引
定义:它是由键值和指针(指向记录本身地址)组成的一系列存储块,该存储块的键值与文件的逻辑顺序一致。
特性:每个存储块的每一个键对应的指针都指向每个数据块每一条记录,当要查找指定键 K 时,采用二分查找即可找到键K对应的记录,复杂度为 log2n。

2.稀疏索引
定义:它是由键值和指针(指向记录本身地址)组成的一系列存储块,该存储块的键值与文件的逻辑顺序单调性一致。
特性:每个存储块的每一个键对应的指针都指向每个数据块的第一条记录,当要查找指定建 K 时,先采用二分查找找到 <=K 的键 S,如果 S=K,则命中记录,如果 S<k,则顺序查找 =K 的键,复杂度大于 log2n,小于 n。

比较:

  • 稀疏索引占用的索引存储空间比较小,但是查找时间较长;
  • 稠密索引查找时间较短,索引存储空间较大。
阅读全文

深入浅出 Kafka(二)磁盘的基本概念


在谈这俩概念前、先来说说大 I/O 与小 I/O。通常,我们把 <=16KB 的 I/O 认为是小 I/O。而 >=32KB 的 I/O 认为是大 I/O。

当前大多系统使用的都是传统的机械磁盘。因此,整个系统设计要尽可能顺序I/O。避免昂贵的寻道时间和旋转延迟的开销。随机小 I/O 消耗比顺序大 I/O 更多的处理资源。随机小 I/O 更在意系统处理 I/O 的数量,即 IOPS,比如 OLTP。而顺序大 I/O 则更在意带宽,即 MB/s,比如 OLAP。因此,如果系统承载了多种不同的应用,必须了解它们各自的需求,是对 IOPS 有要求,还是对带宽有要求。

传统机械磁盘最大的问题在于读写磁头,读写磁头的存在可以让磁盘既能顺序 I/O、也可随机 I/O。但是,随机 I/O 需要花费昂贵的磁头旋转和定位来查找。因此,顺序 I/O 访问的速度远远快于随机 I/O。

顺序读写 = 读取一个大文件

随机读写 = 读取多个小文件

顺序读写比随机读写快的原因:

  1. 顺序读写 主要时间花费在了传输时间,而这个时间两种读写可以认为是一样的。
    随机读写 需要多次寻道和旋转延迟,而这个时间可能是传输时间的许多倍。
  2. 顺序读写 磁盘会预读,预读即在读取的起始地址连续读取多个页面。
    随机读写 因为数据没有在一起,将预读浪费掉了。
  3. 文件系统的 overhead 读写一个文件之前,得一层层目录找到这个文件,以及做一堆属性、权限之类的检查。写新文件时还要加上寻找磁盘可用空间的耗时。对于小文件,这些时间消耗的占比就非常大了。
阅读全文