20181117

Overview:


Algorithm: 螺旋矩阵

题目

给定一个包含 m x n 个元素的矩阵(m 行,n 列),请按照顺时针螺旋顺序,返回矩阵中的所有元素。

示例1:

输入:
[
    [ 1,2,3 ],
    [ 4,5,6 ],
    [ 7,8,9 ]
]
输出:[1,2,3,6,9,8,7,4,5]

示例2:

输入:
[
    [1, 2, 3, 4],
    [5, 6, 7, 8],
    [9,10,11,12]
]
输出:[1,2,3,4,8,12,11,10,9,5,6,7]

思路

这两道题都比较简单,都可以用四个变量 top,bottom,left,right 代表矩阵的上下左右边界,不断缩小矩阵空间并打印或者修改矩阵即可。因此第二道题不在此列出。

测试用例及代码实现

Review: Why you should stop using Git rebase?

Git 作为一个优秀的版本控制系统,提供了很多强大的功能。其中就比如分支的管理。这篇文章描述了在合并分支时,你为什么不应该使用 rebase,而应该使用 merge。

如果你有一个 feature 分支,打算把它合并到 master 分支上。如下图所示,我们创建一个新的 commit g,代表了两个分支的合并:

但是我们也可以通过 rebase。这样 feature 分支就被重置到 master 分支上:

这样,我们将 feature 分支的父 commit 由 b 变成了 c,然后将 feature 合并到 master 上将会很快,因为只需要移动 master 的 HEAD 指针就可以了。

与合并的方法相比,这样得到的提交历史是线性的,没有不同的分支。由此带来的可读性使得越来越多的人在 merge 前使用 rebase 命令。

然而,考虑这么一种情况,当 feature 被 rebase 到 master 上时,第一次重新应该的提交将破坏你的构建。只要没有合并冲突,rebase 不会有任何问题。第一次提交中的的 bug 将保留在后续所有的提交中,从而导致一系列不正确的提交。只有当 rebase 完成时,才可能在 g 上发现这个问题:

如果在 rebase 的过程中出现了冲突,git 将会暂停在有冲突的提交上,然后需要你去解决冲突并继续提交。

rebase 过程中引入的错误会带来额外的问题。因为 rebase 会覆盖原来的提交历史,如果错误出现在原来的提交历史中,就会被覆盖。这样也会导致用 git bisect 定位 bug 十分困难。因为你可能会在 rebase 之后的数周后才会发现这个错误,从而不得不在特别多的 commit 中寻找真正的问题。这个操作可以使用 git bisect 并通过脚本自动完成。举个例子,如下图所示,我们在 rebase 的时候引入了错误,错误出现的 commit f 上,但 bisect 错误识别到了 commit d 上。

为什么我们一直使用 git?因为它是我们管理代码、追踪 bug 最重要的工具。通过 rebase,我们实现了线性提交历史的愿望。但是有更简单的方法吗?

有!那就是 merge。这是一个简单的一步过程,所有的冲突都在一次提交中得到解决。由此产生的合并提交清楚地表明了我们分支之间的集成点,我们的历史描述了实际发生的事情以及发生的时间。但通过 rebase,你对自己和你的团队撒谎,你假装提交时在今天写的,但实际上时昨天写的,并且基于另一个提交。你已经提交了它们原来的背景,来伪装实际发生的事情。

Technique


This article was posted on my blog and Github using the MIT Open Source License.