微创新

1.基本要求：是否有明确的用户价值，即能否为某些用户在某些场景下的具体需求提供解决方案，如果可以，则具备用户价值 2.基本要求：真实合法，不能欺诈消费者或进行恶意引导 3.进阶要求：和同类产品相比具备差异化优势，这样才能保证在竞争中获得用户青睐 4.高阶要求：设计简洁优雅 举例： 好的产品 微信读书：提供极致的阅读体验 得到：让知识触手可及 抖音：创新的短视频娱乐体验 不好的产品 各种导购类APP，毫无差异化 各种海淘类APP，没有合法明确的资质 来源： CSDN 作者： 青梅竹码 链接： https://blog.csdn.net/weixin_43258908/article/details/103625247

昨天改完release分支的操作（ http://www.jiangyouxin.net/2013/02/13/git_flow_2.html ）。现在只剩hotfix了，当然，之后我发现我改的还是release。 按照原始定义，hotfix其实和release很像，唯一的不同是，release分支基于develop创建，而hotfix基于以前的版本TAG创建。源代码里，git-flow-hotfix明显是从git-flow-release复制了一份，然后作了些许修改，很多地方连注释都还没改过来。其实这哥俩没必要分这么清楚，在我的版本里，是使用release分支来实现原版hotfix分支的功能，只是启动命令稍有不同： git flow release start <version> [<base>] 如果省略<base>，则release分支基于develop创建，代表一个主线版本；如果<base>是一个版本TAG，则release分支基于TAG创建，代表一个修补版本（厂里叫做擦屁股版本）。git-flow-release本来就有基于某个base创建分支的功能，只需要再改两点即可： (1) 修改sanity检查部分，允许多个release分支共存 这是因为以前的git flow是允许一个release和一个hotfix分支共存的。 (2) 结束release分支，向master做-

昨天改了git flow feature的实现，提供一个选项，finish时不再保留feature分支上的提交历史（ http://www.jiangyouxin.net/2013/02/12/git_flow_1.html ）。今天的主题是release分支。 在原版git flow的实现中，release分支与feature分支很像，都是基于develop创建，并在结束时合并回develop。所不同的是，release分支还要合并到master分支并打TAG。注意这里的次序是合并（git merge no-ff）在前，TAG在后，这在两个方面都是有点问题的： (1) 如果master上，存在没有合并到develop和release分支的修改，则会有灾难性后果。 当然，如果所有开发者都严格遵守git flow的规范，这种情况不会出现；但git flow的原版中并没有对此做sanity检查。在准备发布时，release分支上的代码是经过测试的，但这个代码与master（如果master有过修改）的合并结果是未经测试的。在把TAG打在合并结点上，就得保证合并前后代码是一致的，否则就有些草率了。 (2) TAG是极强的标志（在gitk中有醒目的显示），足以区分版本边界；没有必要再单独创建一个merge结点。 在nvie的原文中有一句话，可以用来解释他对--no-ff的偏爱： the

昨天写了Git Flow印象（ http://www.jiangyouxin.net/2013/02/11/git_flow.html ），总体来说这是个不错的东西，与现在厂里的研发模型非常契合。所以打算稍稍做些修改，然后拿到厂里去推广。 今天做的修改（按老周的话，这叫“微创新”），是在git flow feature finish的时候，提供一个选项，可以将所有修改合并为一个commit提交到develop分支上；feature分支本身的提交历史不再保留。 为什么需要这样一个选项？首先当前的git flow在将feature分支向develop合并的时候，使用了--no-ff，强制生成了一个merge结点。见下图（左）： 左图通过merge结点来确定feature之间的边界 —— 如果不使用--no-ff就会形成右图（类似SVN的线性提交历史），日子一久就分不清哪些提交属于同一个feature了。 这已经很好了，但仍不是最好。事实上，feature分支的原始提交历史，很多情况下是无用的。比如说在我厂推广git flow时，feature分支将伴随某个功能“开发 + 测试”的全过程，上面的提交历史体现的是开发和BUG FIX的节奏次序；等合并到develop时，功能基本稳定，只需要合并最终结果，以后也很少会关心这个feature的开发过程中发生了什么事情。 综上