回顾：[Git] 017 加一条分支，享双倍快乐 的 "2.3"

1. "Fast-forward"

• "Git" 在合并分支时会尽可能地使用 "Fast-forward"
• "Fast-forward" 这种模式会使得删除分支后丢失该分支的信息

1.1 丢失的信息

• 目前的情况

• 删除 "conflict" 分支

• 找茬时间

• 上图只展示了一部分

1.2 我打个不大恰当的比喻

• 如果
  • 把非 "master" 分支看作“表演者”
  • 把 "master" 分支看作“观众”
• 那么
  • “表演结束”（删除分支）后
  • 留给“观众”的是“台上一分钟”（最后一次 "commit" 的内容）
  • 而“台下十年功”（除最后一次以外所有 "commit" 的内容），“观众”是看不到的

2. 如何让“观众”看到“表演者”的“台下十年功”？

2.1 “记者”——"merge" 的参数 "--no-ff" 还在赶来的路上

• 创建并切至分支

• 修改 "note_01.txt"

• 添加并提交

• 切回 "master" 分支

2.2 有请 "--no-ff" 闪亮登场

• "--no-ff"
  • 我的出场，意味着禁用 "Fast-forward"
  • 作为一个“记者”，合并这样的事当然要记作一次 "commit"，所以用 "-m" 加一句“注释”

2.3 查看一下分支历史

分析

• 其实上图有三次合并历史
• 我截了张 "reflog" 的图

• 这里再次说明了 "Fast-forward" 这种模式会使得删除分支后丢失该分支的信息
• 加上"--no-ff" 参数合并后能看出来曾经做过合并
• "Fast-forward" 合并看不出来曾经做过合并
• 使用 "--no-ff" 参数合并后删除分支，仍能看出来

3. 补充：分支策略

• 在实际开发过程中
  • "master" 分支需要非常稳定，仅用来发布新版本，平时不在上面干活
  • "dev" 分支并不稳定，因为平时在这里干活
  • 如果要发布新版本，就把 "dev" 分支合并到 "master" 分支上
  • 可能许多人都是从 "dev" 分支上再开一个分支干活；干完活后往 "dev" 分支上合并
• 示意图

• 莫名地想到节点电压。。。