方向错了。计算机导论、算法不属于你作为后端的技能点。以前听别人扯淡提到过类似观点， [程序员如何避免青春饭-哔哩哔哩] 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 呢，有这种必要吗？

0. 我也退过，不过非计算机相关专业。挫败感也有吧。部分是失恋、课题因素，落户政策导致不能直接落户是一个直接原因。考虑到入行已经 26 、27 岁，循规蹈矩赚钱别想了。目前目标是避免 35 岁失业，研究框架源码中。是否继续考验给不了意见，身边的确有同学混完研究生准备读博，但我也听说过有人普通本科运营转开发跳到了大公司。
PS：个人没有游戏瘾，对做开发至少现在很有兴趣。
1. 找工作是找工作，和你退学没什么关系。无非两条路：直接面试、边学边工作。或者自学一下再找。直接工作可能比较痛苦，学习能力强可以上。
2. 自学一段时间可以起点高一点再就业。
两条路其实差不多，都是对方看你有培养价值也有意带新人就给你 offer 。

又想了一下，bash 自己肯定是实现不了，有可能受底层 readline 限制。
集成 fzf 替代补全倒是个思路。原来本论坛有人推广过 fzf-tab，不过是个 zsh 插件。确实有类似插件支持 bash，https://github.com/lincheney/fzf-tab-completion

楼上那那个 fzf 启用 cd ** 补全就不要试了，那个只针对补全当前目录下文件。可能还能补全 ssh **，但并不是针对所有命令，只能补全几个命令。

这不是 shell completion menu，而是 vim 编辑时的补全，补全来源 "[File]", "[Dir]" 字段很好的说明了这一点。参考视频 https://www.semicolonandsons.com/episode/vim-autocomplete-overview 1 分 10 秒左右内容。

shell 补全显示方式做不到。唯一一个例外是 upterm，这个 terminal emulator 自己实现了弹出式补全的效果。

另外我比较犯贱：
1. zsh fish 设计时额外考虑了交互式 shell 的功能，bash 连个完善的钩子系统都不存在，有些功能 bash 就是做不到：钩子、字节码编译、懒加载（大多数补全都是懒加载）、右 prompt，更强的行编辑器（ ZLE ）……
2. Bash 流行主要取决于 GNU Bash，即 GNU 亲儿子。写脚本绝对是 Bash，适用性更广。交互式 shell 不需要和脚本运行的 shell 同一，装俩就行。
3. 从名字上看，fish 好像更专注于交互使用。但从生态上看，zsh 好比编辑器界的 vscode，框架、插件管理器、插件数量完爆其他 shell 。zsh 现在连任务队列回调都玩儿出来了，算是异步了。https://github.com/unixorn/awesome-zsh-plugins
4. bash 迁移有个毛的成本，一般人根本不用考虑这些。如果你的 bash 配置连千行都没有，那可能就是一般人。

我选择 hammerspoon

这和 shell 、chsh 有个毛线关系。你们自己操作不规范怪谁。