@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 有个毛线关系。你们自己操作不规范怪谁。

我觉得 Notion 最大问题在于没有离线模式。非 CS 设计，实际上就是个 Web 服务。

> 这是在相同的分支内发生的事情，不涉及到其他的分支啊，所以孤儿分支没什么呢。
@AndyAO 没明白你在说什么。正常分支是要求有共同父节点的。这几个有多个起点，其他几个分支不可能是从主分支创建出来的，必然是多个孤儿分支合并结果。

你没理解分支，这明显是多个分支合并的结果。

1. 创建多个无共同父节点分支，又称孤儿分支。 git checkout --orphan branch-name
2. 合并分支 git merge --no-ff --allow-unrelated-histories branch-name

@rabbbit 算法工作中完全用不到，那玩意儿是用来面试的，跳槽的话可以准备。
框架要研究，一是深入理解、解读困惑，二是避免不了工作中封装、定制框架部分功能。
计算机网络也用不到多少，起码 TCP/IP 层我没用到过。有时间翻一翻《 HTTP 权威指南》，HTTPS 公钥链认证，TLS 握手、协商。再往下还可以熟悉一下 H2，H3 。

个人体会是不要一下子杀到底层，要自顶向下。不要觉得编译器高大上一头就扎进去，标准库都读不顺就上手编译器纯属自取其辱。另外，越是底层的东西反而对你日常代码能力影响越小。

只是一点个人经验之谈，欢迎交流讨论。

淘汰的只是 35 岁的前端切图崽、后端 CRUD boy 、算法调参侠。只要你对框架、技术有深入，都不会被淘汰。