缘起

前一阵子，在一个旧项目上开发新功能。按照新规范，到了提测阶段，需要新建一个分支，如 test/v3.0，把所有这个阶段开发的功能合进去测试。

在本地能创建这个分支 test/v3.0 ，但不能推送到远程，提示远程已经有 test 分支，不能创建 test/v3.0 分支。

简单来说就是：

如果有了 A 分支，就不能有 A/B 分支，反过来也一样。

至于为什么，在网上搜了好久，没有找到一个明确的说法。大多说这是 git 内部的限制。

只好自己动手找原因，最后算是找到问题的答案了。

正文

在解决这个问题不久，刚好公司内部让报名搞一次分享，于是就趁机做了个 keynote 。在这里(需要翻墙)。

本文的重点不在分析上面这个问题——有兴趣的可以看看 keynote ——而是扯扯自己怎样做一次分享，做这次分享的一点感想。

没有什么好分享的

我想，不少程序员大多数时候没有什么好分享的。

对分享的人来说，工作大部分时间是在写业务代码，稍微接触到新东西，都是拿来直接用，不比那些刚接触的人有多少深入理解。

对听分享的人来说，有工夫听人家讲 PPT ，不如埋头看代码、看文档、动手敲敲代码。

在这种状况下，还要被安排分享任务，无论对讲的人还是听的人来说，都是一种折磨。

怎样找到分享的点

在分享这件事上，怎样才能做得更好呢？

我想，好的分享是对自己、对他人有价值的东西：可以是一种思路、可以是一个发现。

这意味着要找到值得分享的东西就得做好：

  1. 不时总结经验、寻找更好的解决问题的路径
  2. 保持好奇心、留意一些不痛不痒但又没有答案的问题

这次分享的来源就是第二点：当时完全可以换个分支名就解决问题：把 test/v3.0 改为 test_v3.0 。

划定分享范围

有时候解决一个问题，只需要知道几个知识点，但解决问题是一个探索的过程——不是去上班——总会绕很多路，间接地知道很多其他知识。

比如这次分享，其实问题的答案只是：同一目录下不能有两个同名文件。

但是我看了 pro git 第 10 章整章，还花了 5/6 个小时翻 Git 的源码、动手验证了好几轮。

如果只讲问题的答案，显然没什么好分享的，但要是讲所有这些接触到的知识——有的成体系、有的很零碎——又有点无从下手。

所以得花一番心思划定分享的范围，让分享涉及的范围尽量窄，而且有一条清晰的、由浅到深的主线。

分享时的几个经验

这次分享有几个经验（思考）：

  • 照顾听众的感受：
    • 提前告诉他们分享的目标（听了之后会有什么收获）
    • 适时逗乐一下听众、向听众提简单的问题
    • PPT 的字数要少，字尽量地大，可以利用 mac 的放大镜辅助功能
    • 分享时间尽量在 30 分钟以内
  • 好好利用 keynote 的「演讲者注释」功能，有了它再也不怕忘词卡壳了
  • 提问环节如果没有人有问题，会很尴尬；如果有人问一些其他多数人不感兴趣而且耗时严重的问题，又该怎样应对呢？