可以

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

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

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

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

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

二手卖掉

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

“次数多了分支线就很乱，怎么办”，如果关注的问题是这个，那么就你需要先列出你操作的分支名，然后会走向两种解决方式：
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 操作，而不是相反。相反只有颠覆，而且是盲从般的颠覆

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

非常好的提问方式。你看看这个如果你直接问 iPhone iOS 通话录音问题，就会招致这样的回答
/t/782725
/t/794353

呵呵，男人

不要跟这些人讨论问题就可以了，因为他们关注的点很奇怪，比如 magic 不 magic，这个谈资和语法糖味道是一样的，都是无用的谈资

too simple sometimes naive

还不如______好看

特别在意别人的看法，怎么破
/t/794311

程序员群体因为出身底层，所以更加对底层劳工抱有同情之心，从来不为难快递员啥的，只会去挑战更有难度的对手

跑步群，马拉松爱好者群，这个属于较为健康的兴趣爱好

各方压力

你搞原子弹开发都可以买 mbp M1