最开始实习的时候是使用svn，之后正式工作就一直在使用git，这样算起来，使用git也有两年的时间了。以前带我的同事，让我在拉代码的时候要我使用git pull --rebase，一直很纳闷为什么要那样做，后来遇到拉代码的时候有许多冲突要解决，然后去查找资料，才了解到其中的一些事情。今天分享一下，顺便自己也梳理一下。
git pull
git pull 是 git fetch + git merge FETCH_HEAD 的缩写。所以，默认情况下，git pull就是先fetch，然后执行merge 操作，如果加--rebase 参数，就是使用git rebase 代替git merge。
more
merge 和 rebas
继续阅读 »
算法原理
归并排序（Merge Sort，台湾译作：合并排序）是建立在归并操作上的一种有效的排序算法。该算法是采用分治法（Divide and Conquer）的一个非常典型的应用。
归并操作(Merge)，也叫归并算法，指的是将两个已经排序的序列合并成一个序列的操作。归并排序算法依赖归并操作。归并排序有多路归并排序、两路归并排序 , 可用于内排序，也可以用于外排序。这里仅对内排序的两路归并方法进行讨论。
算法思路：
1. 把 n 个记录看成 n 个长度为 l 的有序子表
2. 进行两两归并使记录关键字有序，得到 n/2 个长度为 2 的有序子表
3. 重复第 2 步直到所有记录归并成一个长度为 n 的有序表为止。
m
继续阅读 »
Merge
接着上回的Split说，既然有split，那应该对应的有merge吧。然而并没有，也不是完全没有，只是对merge的支持并不像split这么自然，有一些不太稳(kao)定(pu)的工具，可以看[OnlineMerge][1]和[Master initiated automatic region merge][2]。
继续阅读 »
原理
将待排序元素分为前后两部分，分别调用归并排序使它们有序
从头开始逐个比较前后两部分的元素，根据比较结果先后放进新数组，最终返回这个新数组
联想
归并排序用到了递归，递归终止的条件是待排序元素数量小于 2
归并排序比较之后不会交换元素，而是生成新的数组
继续阅读 »
题目
涵涵有两盒火柴，每盒装有 n 根火柴，每根火柴都有一个高度。现在将每盒中的火柴各自排成一列，同一列火柴的高度互不相同，两列火柴之间的距离定义为：$\sum_{i=1}^{n}{(a_i-b_i)^2}$
，其中 ai表示第一列火柴中第 i 个火柴的高度，bi表示第二列火柴中第 i 个火柴的高度。
每列火柴中相邻两根火柴的位置都可以交换，请你通过交换使得两列火柴之间的距离最小。请问得到这个最小的距离，最少需要交换多少次？如果这个数字太大，请输出这个最小交换次数对 99,999,997 取模的结果。
分析
这真是一道好题——断断续续想了几天才完全AC。
事实上，由排序不等式可知：
当$a_i, b_i$从小到大排序时，距离
继续阅读 »
概念
归并排序（英语：Merge sort），是创建在归并操作上的一种有效的排序算法，效率为O(n log n)。
归并操作（merge），也叫归并算法，指的是将两个已经排序的序列合并成一个序列的操作。归并排序算法依赖归并操作。
more
递归法
原理如下（假设序列共有n个元素）：
1. 将序列每相邻两个数字进行归并操作，形成floor(n/2)个序列，排序后每个序列包含两个元素
2. 将上述序列再次归并，形成floor(n/4)个序列，每个序列包含四个元素
3. 重复步骤2，直到所有元素排序完毕
迭代法
申请空间，使其大小为两个已经排序序列之和，该空间用来存放合并后的序列
设定两个指针，最初位置分别为两个已经排
继续阅读 »
更新历史：
20180328，初稿完成
20180403，在我的优化鉴权配置的 PR merge 之后，修改部分内容，并增加录制视频
继续阅读 »
分析：如果点i有一个消防站，那么i到其它各点的最近距离是多少？如果点j又有一个消防站呢？如果用矩阵表示图g，用Floyd算法求出每对顶点的最短距离（直接更新图g），那么g[i]就是i点的消防站到各点的最近距离的向量。如果j点又有一个消防站，则按如下方式把g[i]和g[j]合并起来就得到各点到最近消防站的距离向量（即下面的merge函数）：
继续阅读 »
工作中必备 git 技能详解
绝大多数人对于 git的认识只停留在git status, git add, git push, git pull, 好一点会知道git merge, 那就是全部了。
不信？
继续阅读 »
TL;DR 对已发布到远程仓库的分支进行衍合操作(rebase)，会产生重复的提交记录，本文举例描述这个问题。
git merge 与 git rebase 命令都用来合并代码，如果不需要审查提交记录，两者都可以无脑操作，相互替换；如果要生成有条理的提交记录，前者会记录多条开发分支扰乱视线，因而推荐使用后者。但后者要是使用不当，会生成令人糊涂的提交记录。这点官方文档里有描述，但我嫌它所举例子有点牵强，所以自己举例说明。
继续阅读 »