2014 Git AdventCalendarに掲載した記事で誤解と混乱を生んだ件について
どうもお久しぶりです。こじてぃです。
Qiitaに投稿した記事で誤解と混乱を生んでしまったので、ブログにてお詫びと補足をしたく投稿します。少し長文になりますが、呼んでいいただけると嬉しいです。
今回の背景
- 「Git AdventCalendar 2014」の1日目の投稿をしました。
- 内容は、「Git 作業における commit と push の頻度について」
- commitとかpushの頻度に、あまり意識がない方にもう少し意識を向けてみて欲しい。という想いから書きました。
- しかし結果としては、価値ある情報の発信というよりは、「混乱」を産んでしまった。
問題の記事はこちら
数日かけて、はてブやTwitterでのコメント
作業が中途半端でも安心のため細かくコミットはしてる。けど粒度低すぎるのは後から見づらいので適宜amendやsquashしてる – AdventCalendar – Git 作業における commit と push の頻度について – http://t.co/ZE1USW4vTQ
— 山本 裕介 (@yusuke) 2014, 12月 4
頻度を訴えたいのはわかるんだけど、それならブランチの意義も合わせて書いて欲しいなぁ。期待された使い方とか書くなら尚更。それどこの SVN ?な話に聞こえる。タグの相性とかのとことか、全体的に雑な感じが… / “AdventCale…” http://t.co/nu8ht59x2T
— Yusuke Ikeda (@yukung) 2014, 12月 4
commitとpushの頻度揃えるなら逆にgitの意味なさそうなんですがそれは / AdventCalendar – Git 作業における commit と push の頻度について – Qiita http://t.co/oG9k8irp6B
— けーえむ@無能マン (@kamekoopa) 2014, 12月 4
的確なご指摘ありがとうございます。Twitterやブコメだけでもある程度反応があったので、かなりの混乱や誤解を生んでしまったと思います。
冗談じゃなくて、本気でSNSがあってよかったと思いました。コメントしてくださったみなさんありがとうございます。
この記事で伝えたかったこと
まず、みなさんがくれたコメントなどに対する補足の前に、私が今回この「AdventCalendarで伝えたかったこと」を補足させてください。
対象は「Git知っているし使っているけど詳しくはない」という初心者 ~ 中級者程度の方々のつもりでした。
このブログの文頭でも書きましたが「commitとかpushの頻度に、あまり意識がない方にもう少し意識を向けてみて欲しい。」という想いから書きました。
それはなぜかというと、頻度を意識して改善することで、より便利にgitを使うことができますし、チームでも個人でもgitの恩恵を受けやすくなるから。ということが伝えたかったのです。
その意識があった上で、Branch運用方法(PR/WIP/Forkモデル)とか、commitの整理(rebase -iなど)の活用などの「GitやGithubをより便利に活用する方法」が活きてくると考えていたので、今回はその前段階の話がしたかった。ということになると思います。
ですが今回それを文章にする際に、「余計な情報は混乱を招くかもしれないから省いたほうがいいな」と思って、Push時のコマンドを簡潔にしたり、Branchの説明や状況の補足などを省いたりしたことが問題でした。
結果として、逆に伝えたいことも不明確なまま混乱を産んでしまったことをお詫びいたします。
主に指摘やコメントいただいた点について
はてブやTwitterでの反応や社内での反応をみていて、主に以下の3点を補足すればある程度混乱も解消されると思ったので補足させていただきます。
commitやpushが同じ頻度である必要はない
これは本当仰るとおりで、「commitしたら必ずpushしろ!」ということではありませんでした。
- commit頻度は高い方がいい
- pushもpushできる状態であればガンガンpushしてみよう
- ただし、頻度を高くしすぎて整理できていないcommitが乱立している場合は、rebaseコマンドなどを利用して整理してからpushしよう
- pushしてから push -fなどで強制的に整理するのだけはやめよう(たとえ個人で管理しているリポジトリだとしても)
上記みたいなことがいいたかった(コレもうまく説明できているか若干不安ですが)のですが、上から2つくらいだけ書いてしまったので混乱を生んだと思っています。すみませんでした。
GitやGitHubの特徴を活かせていない
補足にも書きましたが、GitやGitHubの特徴を活かすような部分をあえて省いて説明してしまいました。(馬鹿でした)ちなみにnanapiでは、forkモデルやWIPが主流で開発しており、Pivotalを使っているチームでは基本的にStory1つが、featureブランチになっていると補足させていただきます。
Gitおじさんと呼ばれている
大変ありがたいことに、こんな私ですが会社では「Gitおじさん」として扱って頂いてます。Gitのプロフェッショナルという訳では決してありませんが、一応得意分野のひとつとして、会社のGit運用方法の相談とかにのったり、提案したり一緒に悩みながらGitやGithubをより便利に使えるように挑戦している一人としてやっています。もちろん、一緒に仕事をしているメンバーが大変優秀で助けて頂いている。というのもあります。
今回、「アウトプット」するということで意識向上するためにもあえて「Gitおじさん」と呼ばれていることを書きましたが、「こんな記事を書く人がGitおじさんで大丈夫か?」みたいな余計な混乱を生んでしまったのは、本当に申し訳ないです。
今回の一件で学んだこと
「アウトプット大事」ってよく言いますが、当たり前なんですが「アウトプットすることの責任」という点も同じくらい重要視されるべきだと実感しました。「文章構成力が低い」なんて言い訳にしかならないので(実際下手ではありますが)、「見られる・影響を与える」という意識が足りなかったと反省しています。良い機会をいただいたと思って、今後も励んでいきたいと思いますので、これからもどうぞよろしくお願いします。
混乱と誤解を産んでしまい申し訳ありませんでした。みなさんコメントなどくださってありがとうございました。
Comments are closed, but trackbacks and pingbacks are open.