作業中ひまなのでGit良さがわからない問題を分解してみる

深夜帯でとっとと寝たいのだけど、ちょっと長時間スクリプト回していてかつ待たないといけない状態なので、この記事について。

crapp.hatenablog.com

TL;DR

記事への感想としては、

gitの良さがいまだに分からない - 負け犬プログラマーの歩み
[development]

git以前の問題のように思えるので、がんばってください
2016/10/02 12:07

b.hatena.ne.jp

なのだけど、もっと詳しく書くなら以下のように分解できるのではないかと思うし、そういう指摘もブクマにはいくつかある。

gitそのものの難しさ
- gitを使う上で前提となる概念がわかりづらい
- ブランチつくるの便利なの?
- コマンド体系は煩雑、やりたいことがすぐできない
バージョン管理するさいの運用方法
- ブランチのルールとかマージどうすんの?
- コードレビューされないんだよ、どーすんの?
- レビューに時間かかる
- 履歴はきれいにするべきだ?
人の問題
- （人の）レベルが低くてgitなんか使えない
- だれかとだれかが仲悪い

とまあこんな感じかな。で自分が思うにこの分解した内容を解決する順序は3→2→1だとということである。

人の問題

レベルの低さはそういう人はご遠慮いただいて新しい才気あふれる人を……と言いたいところだが、次の運用方法をしっかり守れよ守れなかったら……という感じか。

まあ仲悪いのはしかたないと思うのでてきとーに解決すりゃいいんじゃないですかね。相手を外すなり自分が外れるなり、上から雷落としてもらうなり。

バージョン管理するさいの運用

このへんは基本的にルール作りでしょう。そもそもgit flowというテンプレートそのまま当てはめて万事解決とかいうアホなこと考えてる暇があったら、そのチームにあった運用方法を考えるのが筋でしょう。そのプログラム書いたり仕様作ったりする頭はなんのためにあるんでしょうか。masterの履歴はきれいにするべきかどうかもこのあたりで考えておく。そうする意味があるのかどうかは、プロジェクトとして共通認識あわせておかないと。

ちなみにコードレビューしないとかおすすめしませんよ。仕様をしっかりつくっても、プログラム組む人がどれだけしっかりした人でも作業が発生するということはミスも起こる可能性は存在しますので。なるべくバグの芽は摘み取るのです。あと、前職のSIerのときでも工数にレビューは入れてたので、この記事書いた人の環境は……と思うと涙を禁じえません。

あとレビューに時間かかるということはチェックする範囲がやたらでかい可能性があるんじゃないですかね。もっと細分化できないの? 仕様は適切なの?とかいろいろ考えてしまいますね。放置されてるとかあるときはあるけど、そういうときはルールとして「さっさとレビューせんかー！（意訳）」と圧をかけることにしておけばいいのです。他にもコードだけ出してもそりゃわからんだろうということで、どういう意図でこのコードを書いたのかなどプルリクエストで意図を書いておいたりcommitメッセージに詳しく書いておいたりしておく。

結局のところ、あの記事だと君らなんも決めてないでしょ? という感想になる。

gitそのものの難しさ

gitは難しいとは思います。

なので基本的に地道な作業しかない。今の会社だと最低限のコマンドを使ってcommitからpushしていくマニュアルなんか作ったり、勉強会開いたりしてましたね。やりたいことをすぐ忘れる? もう一度ggれ。ggるのめんどい? チートシートでもつくってディスプレイに貼っておけ。貼るの禁止なら*1、手持ちの手帳にチートシートつくっておきましょう。結局のところ繰り返しやって覚える以外ないと思うし、それはどのバージョン管理システム使っても何も変わらない。SVNが簡単? 馬鹿言ってんじゃないよ、あれもめっちゃめんどくさいやん。

ブランチ周りはバージョン管理の運用方法と関わったりするので、そのへんは好き好きかなと思う。タスクごとにブランチ切ったりしていく運用だったりすると強制的にブランチつくることになるし、その辺はどうにでもなるでしょう。運用方法でどういうふうに使うかというのを考えたほうがいいんじゃないですかね。ちなみに自分の会社だとブランチ切りまくってますし、不意のバグ修正にはstashめっちゃ便利だし……という感じ。