gitの学習コストを下げ、事故を減らす2つのポイント


今やシステム開発において必須ツールの一つとなった感のあるgitですが、未だに初心者への敷居が高いという問題点があります。

私の前いたチームでは、新しくチームに入ってくる人全員が必ず一回はローカルかリモートのブランチを壊しハマるという現象がありました。もはや通過儀礼みたいになっていましたね(´・ω・`)

チームメンバー全員がgitについて正しい知識を持って開発するのが本来はベストなのですが、現実そうもいかない場合も多々あります。

とはいっても、ブランチを毎回壊されたり事故が多発してしまうのもよくないので、何らかの方法で「gitの性能80%を、無事故で引き出す」方法が必要となってくるわけです。

今回は、「gitの学習コストをなるべく下げ、事故を減らす」2つのポイントについて解説します。

1.GUIツールの使用を義務付ける。

SourceTreeがオススメです。

cuiでコマンドを直接叩く方法は自由度が高い分、若干の慣れが必要になるのと、危険なコマンドでも平気で叩けてしまうという欠点があります。

(もちろん、コマンドの挙動を正確に理解したうえで使うのであればなんの問題もないですが、そのようなスペシャルエンジニアだけでチームを組むことは現実には難しいのではないでしょうか。)

グラフや変更履歴も見やすいので、導入してみるとよいのではないのでしょうか。

※ SourceTreeは結構重めなので、できるだけSSD環境&メモリが十分ある環境での使用を推奨します。

2.使用するコマンドを限定する。

いざブランチを壊した時に復旧できなくなるパターンとして、「どのコマンドを叩いてその現象が起きたかわからない」というものがあります。

適当にググって叩いたコマンドが動かなくて、そのエラーを解決するためにまたどこかから持ってきたよくわからないコマンドを叩いて。。。っていうパターンですね。

また、マニアックなコマンドはその挙動について正確な把握をしている人が急激に少なくなるので、やはり万一の時の復旧が難しくなりますし、ググっても解決策が見つからない危険性が大きくなります。

そこで、みんなよく知っているコマンドのみの使用に留めてしまいます。gitのメリットの80%は、gitのコマンドの20%で達成できます。

  1. ソースコードの変更履歴を確定する「コミット」
  2. リモートブランチからチームメンバーが更新した変更差分を持ってくる「プル」
  3. リモートブランチに自分のコミットを反映させる「プッシュ」
  4. ソースコードの変更を、マスターブランチから切り離して影響範囲を少なくする「ブランチ」
  5. 今いる地点を切り替える「チェックアウト」
  6. 違うブランチの内容を取り込む「マージ」

これらのコマンドを覚えておくだけで、だいたいの仕事には困らなくなります。

プラスアルファとして、スタッシュ、リセットあたりが使えれば大丈夫。

これら2つの方法を紹介しましたが、共通点としては「インタフェースを限定してしまう」という点にあります

一見不自由にみえますが、ユーザの自由度を下げることで問題の領域を限定し、発生源を特定しやすくしているわけです。また、そのことによってgitユーザも「これだけ覚えてればいいんだ」と学習コストを下げることができますね。

インタフェースをシンプルに保とうという原則は、プログラミング(特に設計)をしていくうえで重要です。

gitを短時間で習得したい方にはこちらの書籍がおすすめです。記事で紹介したような手法で、いくらかお手軽に事故なく使えるようになるとは思いますが、決して知識ゼロで使えるものではありません。
業務の合間にでも少しづつで良いので知識を拾っていきましょう。