总计可以拿 1750 刀，有额外 250 刀 coupon 需要开通 Team Plan 才能兑换。https://www.ozbargain.com.au/node/654695

错了，用 dnsmasq 应该不是 Windows，总之把 OS 级别的自动代理检测关了。

在没有使用 dnsmasq 之前，操作系统默认拿到的是路由器下发的 DNS 服务器，通常是路由器自己运行了一个转发 DNS 。路由器知道自己 DHCP 服务下有哪些客户端，可能用这些信息作为对 .lan 的响应。如果没有匹配也不会将 .lan 转发给公共 DNS 服务器。

把 Windows 的自动检测代理关了试试？

另外，.lan 属于本地域名，应该配置 dnsmasq 不向上游转发，可能之前你没配置对导致向外部 DNS 转发查询了。

@forgottencoast 你是说那个 B 站视频，我记得本来价值就不大，没有大纲比较啰嗦，倍速随便听听就好。

感觉我回的还是有点歪了，业务上的设计问题，框架、库关系好像也不大。设计好项目还是得参考现成的、流行的同类型项目源码。

方向错了。计算机导论、算法不属于你作为后端的技能点。以前听别人扯淡提到过类似观点， [程序员如何避免青春饭-哔哩哔哩] https://b23.tv/npQo6N

计算机科学导论、编译器原理、TCP 协议等属于底层基础，你干活是应用层的事，中间隔着好几层对于你没有任何影响。
算法属于八股（至少对后端来说是这样），只在面试会用到。考算法和高考、考研没太大区别，考完可能完全用不到，是学习能力的一种考察方式罢了。

设计模式可以读读，但平时写的时候可能想不起来。建议多翻一翻自己常用框架、库的源码，看看行家们是如何设计项目的，能对应到哪种设计模式。近朱者赤，近墨者黑，研究行业大师们写的东西总能混到点经验。注意自顶向下，从应用层往下打。一些反例：研究框架原理直奔 socket 连接创建；研究网络协议直接 TCP 。

关键词 rhinoshield

类图的不知道，关系追踪试试 https://github.com/CoatiSoftware/Sourcetrail

感觉 Outlook 别名账户半残，邮箱号变了但发件人名字强制使用账户资料里的姓名。

未必，Homebrew 只是个包管理工具，软件包本身不支持 arm64 可能它也没辙，仍有少部分包不支持 arm. https://github.com/Homebrew/brew/issues/10152

“m1 的 homebrew”一词本身可能有歧义。在 m1 上，Homebrew 分为 native arm install 和 Rosetta 2 install. 现在默认安装的应该是前者（表现为使用 /opt/homebrew 路径），其安装的包也大多是支持 arm 的。如果遇到不支持 arm 的包，会安装失败。这个时候唯一方案是再安装一份 rosetta homebrew，我的理解就是安装 x86 包，通过 Rosetta 2 兼容运行在 ARM CPU 上。

卸载了重装到 C:\Users\用户名\AppData\Local\Google\Chrome
或者想办法使 IDM 闭嘴

@ospider git flow 是严格了点，实践中未必要严格遵守使用，但其中的分支使用思想经久不衰。鉴于楼主目前遵循的分支使用逻辑是分支合并结果要保留单一直线，我觉的推荐 git flow 正合适。

@Kobayashi 仔细想了一想，之前的长回复应该补充一点。主要是楼主的问题应该从两个角度回答，我只回答了其中一部分。

楼主问题提到“2 个远程分支合并”，是指原来两个分支都和主分支在一条线上，如果一个分支先合并，另一个与更新后的主分支分叉，合并时发生了 merge --no-ff. 按照楼主的理解，分支合并应该是

1. rebase 到主分支，保证分之合并前没有分叉
2. merge --ff，保证分支合并后没有额外 merge commit.

其实这就是 非 Git 版本控制工具 的分支使用逻辑：分支历史必须是一条线，分支起点必须是主分支最新提交。如 SVN.

这个问题实际要分为 2 个部分：

1. 合并分支前是否要 rebase?
2. merge 是否使用 --ff 快速推进，要不要不产生额外的“合并提价”？

我之前的回复其实只针对了 2，介绍了 Git 分支非一条支线的特性，推荐了 --no-ff 合并。

如果只针对 1，可以根据情况：

- 如果向主分支合并时发生冲突，可以合并时解决冲突。或者 rebase 解决冲突，再合并。
- 或者你想让提交历史图（ timeline ）更清晰一点，也可以先做 rebase 一下。如当前分支和合并前主分支时间隔的太久，直接合并后分支线头尾跨得太远，不好查看。或者是不想多个分支线合并后有交叉。（敲完才发现楼上 @msg7086 回复，参考其“理想的 timeline”一图，非常漂亮）
- 或者分支合并前不做 rebase，降低工作流使用门槛。如 Github PR 合并方式：直接给你在网页上整一个按钮，点击后 merge --no-ff.

不管哪种情况，推荐 merge --no-ff 优先。一些特殊情况，如分支上 只有 1 个新提交，可以 --ff 快速推进。

Merge 多出来的提交不是无意义，它记录了一种合并关系，显式表明这个提交来自于一个分支。这也是 Git 分支的一大特性：Git 历史非一条直线，其中可以有岔路，或者说一个提交可以有多个父节点。Rebase 后再 fast forward 合并的话丢失了这种关系记录。

一个好的分支名直接解释了这个分支在做什么，如修复某个 bug 、新增了某个功能。而分支内每个提交则记录了实现的步骤。从这个角度来看，分支也可以视作一个大的提交。

Merge 而不是 rebase + fast forward 。更不要随意 merge --squash，而是根据情况使用。保留多个提交的实现步骤，如果这个功能出了问题，方便以后细分，定位问题。

楼上很多人对 Git 的理解水平真的不大行，只是在把 Git 当 SVN 来用……
建议了解了解 git-flow，理解一下分支。多翻翻 pro git book.

https://nvie.com/posts/a-successful-git-branching-model/
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
https://git-scm.com/book/zh/v2

暂时不可以，以后说不定可以。毕竟非重置版是有支持 macOS 的。

没得救了。建议以后把 noclobber 打开。
Bash set -o noclobber, zsh setopt NO_CLOBBER.
这样使用 > 不会复写原有文件，显式使用 >| 重定向才可以覆盖文件。

自己用的话没什么问题，公司用可能也没问题，豆瓣不都是 Gentoo 吗？
服务器更不容易挂，因为包少了，没有显卡驱动，没有 x11…… 感觉滚挂更多时候是 GUI 的依赖包导致的。

git_prompt_info function 是由 omz 定义，被 robbyrussell 设置。可能是因为你 export 了 PS1 变量，CentOS 默认的 bash 配置导致切换 bash 继承了父级 PS1. （也有可能是 PROMPT 变量，在 ZSH 中 PROMPT 相当于 PS1 的别名）

可能的解决方案：取消 export PS1 和 export PROMPT，只是定义为全局变量。

不过，为什么要手动切换到 bash 呢，有这种必要吗？