Tago · 开发手记

两种情况：1.已经将代码push到远程仓库2.还没将代码push到远程仓库，还在本地的仓库中 这两种情况下的修改大体相同，只是第一种情况最后会多一步下面来说怎么修改 先搞清楚你要修改哪次的提交注释或者哪几次的提交注释 修改最后一次注释如果你只想修改最后一次注释（就是最新的一次提交），那好办： git commit --amend 出现有注释的界面（你的注释应该显示在第一行）， 输入i进入修改模式，修改好注释后，按Esc键 退出编辑模式，输入:wq保存并退出。ok，修改完成。例如修改时编辑界面的图： 修改之前的注释修改之前的某次注释 输入： git rebase -i HEAD~2 最后的数字2指的是显示到倒数第几次 比如这个输入的2就会显示倒数的两次注释（最上面两行） git rebase -i HEAD~2 hint: Waiting for your editor to close the file... pick 36bceb83c [test] 测试2pick c68574f7b [test] 测试1# Rebase 01c82d86d....

产品新人笔记（四）：导航系统怎么设计 **笔记说明：**本文是我观看传智播客（黑马程序员）产品经理基础课程后，结合个人理解整理的学习笔记，不是课程逐字稿，也不是原创理论。导航类型、界面栏位和配图主要来自课程；选择建议与检查清单包含我的个人总结。 刚开始画原型时，我容易把导航理解为“页面上放哪些按钮”。继续学习后才发现，导航真正解决的是三个问题：用户现在在哪里、接下来可以去哪里、怎样回到自己熟悉的位置。 这篇整理三种课程中提到的导航形式，以及状态栏、导航栏、标签栏等常见界面栏位。这里讨论的是通用设计思路，不是要求每个产品都使用同一种结构。 一、先理解导航承担的任务一个基本可用的导航系统，至少应该帮助用户： 识别当前所在页面和层级； 看见主要功能入口； 在核心任务之间切换； 返回上一层或稳定的起点； 预期点击之后会发生什么。 如果一个页面视觉上很漂亮，却让用户不知道怎样离开、怎样返回或内容属于哪个模块，那么导航仍然是不完整的。 二、舵式导航：围绕一个核心动作展开 舵式导航通常在底部中心放置一个更突出的主操作，点击后展开或进入同等级的多个操作入口。它常见于内容发布、创作或拍摄类产...

产品新人笔记（三）：产品设计常用的七条基础定律 **笔记说明：**本文是我观看传智播客（黑马程序员）产品经理基础课程后，结合个人理解整理的学习笔记，不是课程逐字稿，也不是原创理论。七条定律与配图主要来自课程；适用场景、常见误区和检查方法包含我的个人总结。 学习交互设计时，我最初容易把各种“定律”当成标准答案：按钮越大越好、选项越少越好、页面越简单越好。真正整理下来才发现，这些定律描述的是常见规律和设计取舍，不是脱离场景就能套用的模板。 这篇用新人能直接理解的方式，记录七条常见原则，以及它们容易被误用的地方。 一、菲茨定律：目标越容易碰到，操作越快菲茨定律关注目标大小与移动距离。简单理解：目标越大、距离越近，用户完成指向操作通常越容易。 新人可以这样使用： 高频或关键操作提供足够大的点击区域； 移动端主要操作尽量放在容易触达的位置； 不要把两个高风险按钮紧贴在一起； 图标看起来很大时，也要检查实际可点击区域。 常见误区是“重要按钮越大越好”。尺寸只是一个因素，还要考虑信息层级、误触风险和页面整体平衡。删除、支付等操作也不应该仅因为重要就放在最容易误触的位置。 二、席克定律...

产品新人笔记（二）：如何分析产品并确定优先级 **笔记说明：**本文是我观看传智播客（黑马程序员）产品经理基础课程后，结合个人理解整理的学习笔记，不是课程逐字稿，也不是原创理论。课程提供了基础概念和部分示意图；具体例子、验证问题和使用限制包含我的个人总结。 上一篇解决的是“怎样理解一个需求”。继续往下走，新人很快会遇到另一个问题：需求、问题和想法同时出现，到底应该先看什么、先做什么？ 我把 SWOT、用户体验五要素和四象限法则放在一起学习，是因为它们分别回答三个层次的问题：产品处在什么环境里、体验问题发生在哪一层、当前事项应该怎样排序。 一、SWOT：先把内外部情况分开SWOT 包含四个部分： Strengths，优势：产品或团队内部已经具备的有利条件； Weaknesses，劣势：内部能力、资源或体验上的不足； Opportunities，机会：市场、技术、渠道或政策环境带来的外部机会； Threats，威胁：竞争、替代方案、政策变化等外部风险。 对新人来说，最重要的不是记住四个英文单词，而是不要把内部问题和外部变化混在一起。 假设分析一款新人学习工具，可以写成： ...

产品新人笔记（一）：如何理解用户需求 **笔记说明：**本文是我观看传智播客（黑马程序员）产品经理基础课程后，结合个人理解整理的学习笔记，不是课程逐字稿，也不是原创理论。文中配图主要来自课程画面；案例、风险提醒和使用方法包含我的个人总结。如有理解偏差，请以原课程内容为准。 最近在补产品基础课时，我发现新人很容易把“用户提到的功能”直接等同于“用户需求”。但用户说想要一个按钮，不代表真正的问题就是缺一个按钮；同样一个功能，对不同用户也可能有完全不同的价值。 这一篇整理三个理解需求的视角：Kano 模型、马斯洛需求层次和人性动机。它们不是计算答案的公式，更像是帮助我继续追问的三组问题。 一、Kano 模型：不同需求，满意度变化不一样Kano 模型最实用的地方，是提醒我：功能做得更多，不一定就会让用户更满意。 图中的横轴可以理解为功能提供的程度，纵轴是用户满意度。五类需求分别是： 1. 必要型需求没有它，用户会明显不满；有了它，用户只会觉得“本来就该如此”。 例如账号注册能正常完成、订单金额计算正确、支付结果有明确反馈。这些能力通常不是宣传亮点，却决定产品能不能被正常使用。 新人容...