タオルケット体操

サツバツいんたーねっとでゲームとかガジェットのレビューとかをします

どっちでもいいんだけどGitはCUIの方が楽じゃね

Sponsored link

某R社と出会って5日で即脱退みたいなエントリで、内容とは関係ないけどちょっとひっかかった発言

「コマンドライン使えないとエンジニアじゃないよ」

んなことねーっしょ、とおもいつつもGitに関してはコマンドラインの方が便利だよなとおもった日記。

CUIとGUIのどっちが良いのか

そもそもの「Gitが難しい問題」の主な理由は

  1. ソースコードの管理というタスクが本来持つ煩雑さ

  2. それらをカバーするために発達したGitの仕組みが(初学者にとって)微妙に直感的ではない

  3. 機能が多すぎるし、コマンド体系がわかりにくい

  4. sshよくわかんない

の3つ(+ 1)であって、そのうち1と2が占める割合がほとんどである。また、3に対してはCUIであっても補助的なエイリアスやスクリプトを作ればカバー出来る。
というか、その特性上コマンドラインの操作をそのままメニュー化せざるをえないGUIクライアントも3の問題をそのまま受け継いでいる*1

なのでGUI, CUIといったインターフェースのそのもの違いは、プログラマーがGitを習得する上で誤差程度の問題であるとしか言いようがない。

4はまぁ、頑張れ。

だから結論から言えば別にどっちでもいいじゃねえかみたいな感じになるのだ。

では何故、僕は初心者にCUIで習得することをお勧めしているのか。

ひとつには、これは教える上の都合なのだが僕がGUIクライアントに詳しくないというのがある。
僕がプログラミングを始めた頃には、まともに使い物になるGitのGUIクライアントというものは存在しなかったので必然的にコマンドラインで操作する必要があった。これでは良くないとSourceTreeなども触ってみたのだが、結局のところコマンドで操作する代わりにマウスでポチポチ出来るというだけでなんの機能的メリットも存在しておらず、かゆいところに手が届かないので使うのをやめてしまった。
なのでGUI特有の問題について質問されても困るのである。

次に、上であげた理由からも明らかなように、そもそもどちらのインターフェースを使おうがGitが簡単になったりはしないのである。
そしてGitはそもそもがCUIで作られたツールである。であれば、仕様変更や機能追加に追随しやすく、またGUIクライアント特有のバグに悩まされる可能性のないオリジナルのインターフェース(つまりCUI)を使うのが合理的であるというのが僕の判断の根拠だ。

オリジナルのインターフェースを利用することのメリットは他にもある。
世の中に存在するリファレンスはその殆どがコマンドラインでの操作を前提として書かれている。なので初心者がGUIクライアントを使う場合、まずコマンドラインでの操作方法を探して(覚えて)から、それを自分が使っているGUIでの操作に翻訳するという作業が必要になる。これは大変に面倒くさい作業である。
どちらにしろコマンドラインでの操作方法を覚える必要があるのならば、そのままコマンドを打ち込めば良いのではないか。

またhubコマンドのような便利ツールだとか、シェルスクリプトを組み合わせた自動化との相性の良さなどの存在はCUIの利点である。

CUIのデメリット

CUIのデメリットとは、CUIがCUIであることに尽きる。
「プログラミング初心者がGitの使い方を覚える」という状況化で、さらにCUIの使い方まで覚えさせるのは若干気がとがめないでもない。
「黒い画面」にアレルギーのある人間というのはおもった以上に多いようだし、デザイナーに教えるとなるとCUIの存在は割と致命的だったりする。

ここはまぁ好きにすれば? としか言いようがない。しかし……正直なところコマンドライン程度の物事を学習するだけでガタガタ言うようだと、この先プログラマーとしてやっていくのはあんまり楽しいことにならないからやめた方が良いのではないかなーとおもわないでもない。ずっと勉強してなきゃいけないし、タスクは無茶ぶりばっかだし。

とりあえずこの問題に対処する個人的な指針としては

環境がWindows → 仮想とかでLinuxを入れさせるか、SourceTreeを使ってもらう

相手がプログラマー → 教えてる間はCUI。べ、別に余裕出来たらアンタの好きなやつ使えばいいじゃない!

相手がデザイナー → SourceTree使って、コミットとプッシュの操作だけ暗記してもらう

みたいな感じ。

時々勘違いしている人がいるけど、CUI, GUIは新旧とか表裏とか対立する概念とかじゃないんだから両方を使い分けるのが大事なんじゃよっていうことをよく考えますね。

GUIのメリット

GUIのメリットもGUIがGUIであることに尽きるんじゃあないだろうか。
黒い画面が嫌いな人はそれだけでGitの学習が嫌になるかもしれないし、そういう人にとっては悪くない。
グラフとかの情報も、ショボいアスキーアートじゃなくてグラフィカルでキラキラしててかっちょいい。

先ほどのデザイナーに使ってもらう例でも書いたように、GitをVCSではなくてただの「ぼうけんのしょ」的なものとしてしか使わないと割り切ってしまうのであればGUIの初期の障壁の低さは大きな魅力になるんじゃあないだろうか。
ただ以前のGitExtensionだか亀Gitなどがそうだったんだけども、よくわからんオリジナルコマンドみたいなボタンがついていたりして、そういう余計な親切機能が提供する抽象化は危険だ、と僕は考える。

まとめ

  • Gitをある程度以上ちゃんと使おうとおもうならば仕組みの理解は必須。

  • クライアントを変えてもGitの仕組みを理解するために払うコストは変わらない。

  • だったらオリジナルのUIで、リファレンスが多くて、ユーザが多いので他人の知見にタダ乗りしやすいCUIの方が効率良いとおもうよ。

っていうのが個人的な意見。


現状だとGUIクライアントには「黒い画面が嫌いな人のためのはけ口」程度の魅力しか感じないんですけども、これは僕の使い込みが足りない可能性もあるので知見おなしゃす。

なお「GUIだと簡単に使えるよ!」っていう人は、何か勘違いをしているか、CUI慣れしていない人。だけど後者のタイプにはGUIクライアントは有効ではなかろうか。

おしまい!

入門git

入門git

Web制作者のためのGitHubの教科書 チームの効率を最大化する共同開発ツール

Web制作者のためのGitHubの教科書 チームの効率を最大化する共同開発ツール

*1:大量のメニューやチェックボックスがそれを物語る