honoka

honoka 查看完整档案

填写现居城市  |  填写毕业院校  |  填写所在公司/组织填写个人主网站
编辑

每次编码都想象自己在写诗的透明小码农,ller 一枚

个人动态

honoka 回答了问题 · 2016-04-27

npm安装webpack问题

webpack-dev-server包需要单独安装

关注 5 回答 4

honoka 回答了问题 · 2016-04-27

解决react 例子

Github 搜索 awesome-react

关注 7 回答 6

honoka 回答了问题 · 2016-04-27

解决react手册里说使用...传递,为什么浏览器提示错误

... 是 ES6 新增的语法,要配合 babel 之类的预编译器编译为浏览器支持的语法(如 ES5)才能运行

关注 4 回答 3

honoka 发布了文章 · 2016-04-26

闲谈 git merge 与 git rebase 的区别

前言

相信大部分使用 Git 的朋友都会遇见相同的疑问,并且也从网上搜索了不少资料。那么,为什么我还要写这篇文章呢?因为我想尝试从自己的角度解释这个问题,如果能给到大家灵光一闪的感悟,便善莫大焉啦。估计点进来的朋友也对 merge 和 rebase 有了一定了解,所以我也就不浪费篇幅再去详细介绍 merge 和 rebase,让我们直入主题吧。

merge 与 rebase 的区别

merge(以下说明都基于 merge 的默认操作)

现在假设我们有一个主分支 master 及一个开发分支 deve,仓库历史就像这样:

初始仓库历史

现在如果在 master 分支上 git merge deve:Git 会自动根据两个分支的共同祖先即 e381a81 这个 commit 和两个分支的最新提交即 8ab7cff696398a 进行一个三方合并,然后将合并中修改的内容生成一个新的 commit,即下图的 78941cb

merge 合并图

rebase

rebase 是什么情况呢?还是一个初始的仓库历史图:

rebase初始仓库历史

如果是在 master 分支上 git rebase deve:Git 会从两个分支的共同祖先 3311ba0 开始提取 master 分支(当前所在分支)上的修改,即 85841bea016f64e53ec51,再将 master 分支指向 deve 的最新提交(目标分支)即 35b6708 处,然后将刚刚提取的修改依次应用到这个最新提交后面。操作会舍弃 master 分支上提取的 commit,同时不会像 merge 一样生成一个合并修改内容的 commit,相当于把 master 分支(当前所在分支)上的修改在 deve 分支(目标分支)上原样复制了一遍,操作完成后的版本历史就像这样:

rebase 合并图

可以看见 master 分支从 deve 分支最新提交 35b6708 开始依次提交了自己的三个 commit(由于是提取修改后重新依次提交,故 commit 的 hash 码与上面的85841bea016f64e53ec51 不同)。

rebase -i

rebase 操作加上 -i 选项可以更直观的看见被提取的 commit 信息。

仍然在 master 分支上 rebase deve 分支,不过这次要加上 -i 选项,即 git rebase -i deve,然后我们可以得到这样一个文本信息框

rebase -i信息

  • A 区域内的信息说明了这次 rebase 操作提取了哪些 commit 记录(f9a7673edb2ba2),会连接到目标分支的哪个 commit (9c86a5c)后面。可以根据 B 区域中的命令说明修改 pick 为其他命令,对该次提取出来的 commit 做额外的操作

  • B 区域内说明了本次 rebase 操作可以选用的命令

  • 通过 :wq 保存退出后,就会按照刚刚在 A 区域内设定的命令处理 commit 并 rebase。

冲突处理策略的不同

  • merge 遇见冲突后会直接停止,等待手动解决冲突并重新提交 commit 后,才能再次 merge

  • rebase 遇见冲突后会暂停当前操作,开发者可以选择手动解决冲突,然后 git rebase --continue 继续,或者 --skip 跳过(注意此操作中当前分支的修改会直接覆盖目标分支的冲突部分),亦或者 --abort 直接停止该次 rebase 操作

总结:选择 merge 还是 rebase?

  • merge 是一个合并操作,会将两个分支的修改合并在一起,默认操作的情况下会提交合并中修改的内容

  • merge 的提交历史忠实地记录了实际发生过什么,关注点在真实的提交历史上面

  • rebase 并没有进行合并操作,只是提取了当前分支的修改,将其复制在了目标分支的最新提交后面

  • rebase 的提交历史反映了项目过程中发生了什么,关注点在开发过程上面

  • merge 与 rebase 都是非常强大的分支整合命令,没有优劣之分,使用哪一个应由项目和团队的开发需求决定

  • merge 和 rebase 还有很多强大的选项,可以使用 git help <command> 查看

最后:一些注意点

  • 使用 merge 时应考虑采用默认操作,还是 --no-ff--ff-only 的方式

  • rebase 操作会丢弃当前分支已提交的 commit,故不要在已经 push 到远程,和其他人正在协作开发的分支上执行 rebase 操作

  • 与远程仓库同步时,使用 pull 命令默认进行了 git fetch + git merge 两个操作,可以通过加上 --rebase 命令将 fetch 后的 merge 操作改为 rebase 操作,或者仅仅 'git fetch remoteName',然后才思考采取哪种整合策略 git merge(or rebase) origin/master

  • 开发与 commit 时注意自己此时在哪个分支上

  • 当有修改未 commit 时,不能进行 rebase 操作,此时可以考虑先用 git stash 命令暂存

参考

查看原文

赞 13 收藏 39 评论 3

honoka 回答了问题 · 2016-03-16

解决前端如何百分百还原美工图?

不要想着百分百还原,多和美工沟通一下,找到双方都能接受的程度。

PS. 这是多好地泡美工妹子的机会啊(雾)

关注 17 回答 12

honoka 回答了问题 · 2016-03-16

解决论前端模块化与组件化的区别?

简而言之:

  • 模块化解决了分而治之的问题

  • 组件化解决了代码复用的问题

关注 7 回答 4

honoka 回答了问题 · 2015-12-30

编程中经常看到上下文,这个上下文指得是什么?

上下文是指系统完成某个动作的过程中,需要提供给系统的关联信息。
举个例子说明:

  • 比如你入职的时候,公司需要你的姓名、专业等个人信息。那么个人信息就是对于入职这个动作而言的上下文。

  • 入职后会拥有自己的工号,每天上下班要凭工号打卡。那么对于打卡这个动作而言,工号就是所需的上下文。

然后上下文又分两种:

  • 一种是必须的(required context),还是刚刚那个例子,如果不提供个人信息,公司就不会让你入职,则个人信息是必须的上下文。

  • 一种是可选的(optional context),假设入职的时候,你可以自由选择想去的部门,部门就是可选的上下文。

参考:Stackoverflow

关注 23 回答 13

honoka 回答了问题 · 2015-12-30

编程中经常看到上下文,这个上下文指得是什么?

上下文在不同的语言、框架中可能会有不同的含义,但一般是指完成动作的过程中,需要提供给系统的标识符信息。

举个例子吧:

- 比如你入职的时候,公司需要你的姓名、专业等个人信息,对于入职这个动作而言,姓名、专业等个人信息就是上下文。
- 入职后你会拥有自己的工号,每天上班要凭工号完成打卡记录,那么,对于打卡这个动作而言,工号就是上下文。  

然后上下文又分两种:

- 一种是必须的(*required context*),还是刚刚那个例子,你不提供个人信息,公司就不会给你办入职,所以个人信息就是必须上下文。
- 一种是可选的(*optional context*),假设入职的时候,会让你自行选择想去的部门,选择部门后才会给你工号,那么部门就是可选上下文。

关注 23 回答 13

honoka 发布了文章 · 2015-12-29

《写给大家看的设计书》阅后感受与思维导图分享

最近发现每次讨论页面如何设计的时候,自己总会干坐在那儿,一副 “我是标准理工男,不知道怎样才能好看,设计都交给你们了” 的样子。虽说术业有专攻,我们不一定要成为程序员中设计最好的家伙(笑),设计就应该交给一名真正的设计师,但是基本的美学设计思维还是要有的。知道美是如何产生的,才能更好地理解设计,方便与设计师交流沟通。引用书中的约书亚树的故事:

很多年前的一个圣诞节,我收到一份圣诞礼物,是一本关于如何认识各种树的书。当时我住在父母家,所有礼物都打开后,我决定出去走走,认一认邻居家的树。出去之前我读了书的一部分。其中提到的第一种树是约书亚树,只需要两个线索就能认出它。由于约书亚树相当怪异,所以看到书中它的照片时,我对自己说:“哦,北加利福尼亚绝对没有这种树。这种树太怪异了。如果我见过,肯定应该有印象,可我以前从来没有见过。”

之后我拿着这本书走出家门。我的父母住在一个小巷子里,这里共有6家住户。其中4家的前院里都赫然立着约书亚树。我住在那里已经有13年了,此前居然从未注意过约书亚树。我在这个街区转了转,发现似乎每一家布置新居时都会到苗圃买约书亚树,至少80%的住家前院都种有约书亚树。而我在此之前居然从来没有注意过!在我知道了这种树之后,我是说在我能够说出它的名字后,它就无处不在了。这正是我要强调的:一旦能够说出什么东西的名字,就会很容易注意到它。你就会掌握它,拥有它,让它受你所控。

作为设计方面的入门图书,我认为《写给大家看的设计书》是非常值得推荐的,整本书生动形象地讲解了作者总结出的几大设计原理,通过一个个实例让人消化吸收。

读完全书,就会发现原来设计也是一门模式化、标准化的技术。通过数十年的总结,设计师们知道人们喜欢什么样的色彩搭配,什么样的整体布局,什么样的字体,形成了一整套科学实用的理论。经常看着书中的例子时突然发现,啊,原来感觉设计非常不错的网站是用了这个原理,原来我看见这个设计时的心理感受是这样描述的。这种眼前一亮的感觉处处皆有。

灵感不是设计的全部,设计应该在基础理论上加上自己的演绎完成的事物。看完这本书,连我这种直线都画不直的战五渣也有了一种对于设计莫名的自信呢。

以上便是个人对于这本书的阅后感受,分享一下阅读时完成的思维导图读书笔记,主要罗列了一下整本书的大纲,以后看一下导图便能回忆书中内容了,希望对大家有所帮助。

《写给大家看的设计书》思维导图-百度网盘

查看原文

赞 1 收藏 3 评论 0

认证与成就

  • 获得 16 次点赞
  • 获得 1 枚徽章 获得 0 枚金徽章, 获得 0 枚银徽章, 获得 1 枚铜徽章

擅长技能
编辑

(゚∀゚ )
暂时没有

开源项目 & 著作
编辑

(゚∀゚ )
暂时没有

注册于 2015-08-18
个人主页被 608 人浏览