如果你是一名程序员，或在工作中常与程序员接触，那你一定对 Git / GitHub 不陌生。程序员差不多有一半工作时间都是在 Git / GitHub 上度过，要么在写代码、push commits，要么在 review 同事的代码。
在工作了一段时间后，我发现几个与 Git / GitHub 相关的工作细节被很多人忽视或并不在意，从而给别人带来不必要的麻烦，浪费别人的时间与注意力。
1. 换位思考，减少对别人注意力的消耗
在 review 别人代码时，如何提交你自己的 comments 存在两个选项：
A. Start a review
B. Add single comment
如果你选择 A，那么你的所有 comments 会在最后结束 review 时一次性提交一次，所有 watch 这个 repo 的同事和与这个 Pull Request (PR) 直接相关的人，此时就会收到一封 GitHub 发出的提示邮件。这封邮件会显示你留的所有 comments，干脆利落。
但如果你选择 B 呢，你的每一条 comments 会挨个提交，所有 watch 这个 repo 的同事和与这个 PR 直接相关的人，会不断地收到来自 GitHub 的提示邮件。对于一个改动多的 PR，一个 reviewer 留十来个或更多 comments 也不奇怪，于是所有人就会接连不断地收到十来封或更多提示邮件——每一封邮件内容只有一个 comment。
这确实是一件看起来很小很小的事，但作为习惯于让收件箱未读邮件数归于零的人，时常被这样一长串 GitHub 提示邮件打扰，我偶尔会有点恼火——因为每一次打断注意力的信息量竟如此之低，有时我不得不手动到邮件文末去点 mute the thread 按钮。就算是更改了一部分邮箱收件规则和间隔，也还是避免不了被这样的小事打扰。
其实常常做出 B 选项的人都是固定的几位，来来回回几次，至少给我留下了他们也许不太在意细节、不太会换位思考的印象。当然，作为工作还不到一年的新人，我对别人的职场印象对他们的影响几乎为零，可如果时间比我宝贵得多的老板也像我这样龟毛呢？
2. 先做好自己的工作，再……
在写代码、提交 PR 这件事上，也很容易观察到不同人的工作风格。只有在 GitHub 上开新 PR 时，所有 watch 这个 repo 的人和被加到 reviewer/assignee 列表的人才会第一次收到邮件提醒。在收到这类提示邮件时，我在有些同事的 PR 提示邮件中正文中很清晰地看到一串清晰简洁的 commit history，外加适当的代码改动总结，表示这次提交的主要内容已经完成，同事们可以直接 review 了；在另一些同事的邮件正文中，却只看到一个 commit 记录，没有 PR 总结，并且这次要提交的内容往往还待完成，因此所有在收件列表上的人还会继续收到几次信息量不高的邮件提醒。
我对前一类同事真的很有好感。
3. 举一要反三
在 review 别人 PR 时，比较令我无奈的情景之一是：当我留言指出一个小问题后，原作者快速改掉了，但 ta 只改了我指出的这一处问题，同一 PR 中其余几乎一样的小问题还是纹丝不动。或者我以前曾在 review 中留言指出一个语法错误，但隔了一段时间后，同一位代码作者又写出了一模一样的错误，并且表现出“不知错在哪儿”的茫然表情。
这样的场景除了发生在 GitHub 上外，相信在各种工作场景、各种职业中都不少见。
我觉得职场中大部分同事大都很友好，会愿意通过建议的方式指出问题，但大多数人大概都对反复提醒同一个人的同一个错误缺乏耐心。连孔子作为老师对学生都有“举一隅不以三隅反，则不复也”的要求，同事和老板对你抱有“举一反三”期待，也是非常合理的了吧。
小结
新手写作者容易犯一个毛病（我也常犯）：一下笔就絮絮叨叨啰啰嗦嗦，恨不得把自己脑中想到的一切细节全部倾倒在纸上，生怕不写出来别人就不知道自己的思考有多么严密深入。但读者此时只觉文字拖沓，缺乏简洁有力的筋骨，甚至有时令人云里雾里。当一名写作者终于学会在纸上隐藏脑中走过的中间细节时，ta 必然会同时明白，一篇好作品背后藏了多少作者提前排练过的细节和不为人知的心思。
工作也是如此。看到别人获得一项好业绩，如果你没能达到同样的水平，那你很可能不知道背后包含了多少不会黑纸白字写出来的细节。那些细节究竟是什么，我常常很好奇，因此也很愿意琢磨像这篇短文中写出来的这些小细节。