charlie21

@nadia #143
H&M 店家是因为遇到等待试衣服的太多的情况，店里的试衣间不够用，所以才鼓励消费者别试了赶紧下单，出店

等待试衣，这是消费者成本，但若试了不好再来退，有的消费者会退，有的消费者不会退；选择退货的消费者还要承担退货成本，其中有的人权衡之后会决定即使不合适也算了不会退货。结果就是下次一定会试衣服试好再买。

增加试衣间，可以疏通人满为患的等待试衣服的情况解决这个问题，但这是店家成本，有的店家会增加试衣间，有的店家不会增加试衣间（也就是不觉得这是需要解决的问题）反而大力鼓励消费者别试了赶紧下单，出店

2 天前

回复了 manami 创建的主题 › 生活 › 想要变得酷酷的，有没有什么快捷的办法？

在相对和平的环境里
尊重女性
帮助弱小
绅士风度
给人台阶下
但并不虚伪

2 天前

回复了 manami 创建的主题 › 生活 › 想要变得酷酷的，有没有什么快捷的办法？

系统学习西方中世纪骑士精神

3 天前

回复了 ruiyinjinqu 创建的主题 › Apple › iPad pro2021 怎么让它成为生产力工具啊！

二手卖掉

3 天前

回复了 wangbenjun5 创建的主题 › 知乎 › 如何从逻辑角度解释蛋生鸡、鸡生蛋问题？

它对蛋来说不是问题
它对鸡来说不是问题
它为什么对你来说要是个问题？

4 天前

回复了 wiirhan 创建的主题 › git › rebase 还是 merge？

“次数多了分支线就很乱，怎么办”，如果关注的问题是这个，那么就你需要先列出你操作的分支名，然后会走向两种解决方式：
1 增加分支，**增加一个分支作为 ‘缓存分支’ **，即改变分支策略
2 分支不变，改变 merge 命令

如果是办法 1，那么解决办法会非常简单，你会把 ‘造成分支错乱’ 归因为提交错了分支线。

如果你需要前后三次提交（或无数次提交），将会导致分支错乱的原因是你只有 2 个分支，自己的 branch -> main branch，这样 main branch 会很快被写入；将会导致分支清晰的原因是你现在有 3 个分支，自己的 branch -> develop 分支 -> main branch 。这样因为多了一个分支，所以 develop 分支仍然会很乱（ develop 分支是 ‘缓存分支’，等于为 main branch 作了缓存），故而 main branch 会保持清晰。

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow 图示
https://www.atlassian.com/blog/git/written-unwritten-guide-pull-requests

如果是办法 2，那么，哈哈 ... 这根本不是 merge 命令的问题 ... 你需要重新归因，而不是拿出某个命令来就用。实际上它是 pull request 策略的问题，而不是 merge 策略的问题。它是人员责任划分的问题，不是 git 的问题：是责任划分来指导 pull request 策略和具体 git 操作，而不是相反。相反只有颠覆，而且是盲从般的颠覆

5 天前

回复了 wiirhan 创建的主题 › git › rebase 还是 merge？

为什么 ‘包含完整的提交历史记录’ 会是一个需要避免的问题？你瞎搞之后丢记录了怎么办行为艺术吗

» charlie21 创建的更多回复