1.alert 的方法，抽象一些参数出来封装一下
2.数据持久化可以有专门的类来处理，所以也可以封装一下
3.这些确定的字符串用常量来定义比较好
4.这些带 block 的方法已经不用再封装了，但是如果 其他类也要复用的话，可以抽象一下。

我如果碰到这种事情，我在电话中就会直接说不干了。
事后也想都不会想什么对与错的问题，老子就是不干了。
吵我睡觉的人， 我拿胡萝卜都能把他捅死。


不过，冷静来说，我还是会具体看看到底是出了什么大问题，至于这种时刻联系到我。

真如楼主所说这种情况下，公司采用这种做法明显就是太不尊重员工了好吧，甚至完全就是轻视。


看看今年的 WWDC keynote，视情况继续了解一点

git 的口号是 everything-is-local

例子：

在 master 上开出两个分支 A 和 B

merge A

A 先被合并到 master 之后，master 指针已经前移了一步骤指向了 A，这时候你要合并 B 到主线上去的时候

merge：

merge 操作是把**当初分裂出 A、B 时刻的 master 分支（共同祖先）**以及**先一步合并的 A**和**你现在要合并的 B**进行一个三方合并。

rebase :

主线是 A 的提交之后向前移动了一步，你切换到 B 分支，执行 rebase master

这个操作，找到是**当初分裂出 A、B 时刻的 master 分支（共同祖先）**，用来和 B 对比，把 B 上面的所有提交（补丁）提取出来，同时会将最新的进度指向**最新的刚合并完 A 的分支**之上

然后，你还需要单独切换到 master 分支之上，进行直接合并操作 checkout master，merge B


----
这两种方式得到的结果没有任何差别

只是说，能让提交历史在查看的时候是一条直线没有分叉

-----
那有什么用呢？

这里就是涉及到远程合作的事情了，以上都是在本地自己玩。

当你 PR 别人的代码，并且想要提交的时候，最好不要直接 merge 到本地
master，直接 push

你应该，先回到分叉的那个点开始，没有 mergeA 和 B 的时候，拉取一下 master，然后 checkout 到 A 或者 B，rebase 一下 master，然后 checkout master 合并一下你的分支 A 或者 B，然后再 push

这样以来 远程 repo 合并你的代码的时候就不需要进行三方合并而导致，提交历史分叉

-----

如发现有错误请各位指出

rebase 是这个意思和具体执行过程？感觉你的说明和英文的说明对不上啊？

我擦，怎么会有 2300 颗星星，unbelievable

车公庙爆炸，不知是不是今天的图片和视频，还是往年的。

@dtysky 厉害了我的弟

还没用，感觉和漂流瓶一样。如果想撩，可能就直接聊微信了，如果不想撩，不会专门去写日记的吧。毕竟这东西很私密

你真这么做了的话，简直比我们公司 HR 还恶心了，我司 HR 让人走都知道要搜集证据再摊牌。

你想到耍阴的只是你根本没证据，说不定人家工作也没有大的纰漏。

@shashashameme 试着更改 markdown 语法的参数或者用 html 标签的方式 6 次以上吧，都有各种问题（ chrome 和 safari 下），看了一些成熟的开源库中这个 gif 显示的做法都是牺牲了图像品质的。所以我还是改回去了，只不过用了更小一点的图，进去加载会快点。

不过还是那么大 嘿嘿嘿。

有没有路过的教我几招，感谢。

@sobigfish 感谢指出。不过我其实并不想动手写的那么复杂，主要目的就是把那个点击动效的一种实现方式写出来给人做参考。

@shashashameme 哈哈哈哈 我看看 readme 能不能改改

我观察过很多同学和我自身的经历，得出一个结论：基本上你开始讨厌某个老师，这个老师所教授的这一科目就不可能拿好成绩。

楼主只是来泄愤、和罗辑思维做一个了断，虽然我几年不看罗辑思维是因为瞧不上它，但是没有必要这么上纲上线的怼人家。

人家写文章不至于像写教科书那样，那所有前提、基础定义、简称等东西全部罗列清楚再来和你讲后述的内容。都有个 context 的，自己发现歧义能修正就行了。

如果小白们自我修正不了，受了，这是罗辑思维和小白们共同的失败。

罗辑思维大体上确实是不是什么好东西，不过要有自己发现好东西的积极心态和眼光，同时我们大可不必这么喷。

居然干直接亮明 PM 的身份，我很欣赏你。
你可以 Google 一些 iOS 的交互动画等，其中可能有一些适用你业务场景的列表展示方式