クリスマス・イブ特に予定ないからAdvent Calendar入れたんですけど、体調崩して遅刻です。
デザイナーにもgit使ってもらおうということでこの記事を書きます。
タイトルの通りというか自分自身がデザイナーで、自分がどうやって使えるようになったかというのが参考になるんじゃないかなと思っています。
git歴は1年5ヶ月程度で、今の会社に来てからです。まあ自分がどの程度使えているかという部分で怪しい部分はなきにしもあらずですが、一応git使ったことない人にいろいろと教えるまでにはなっているので、そういう部分でのノウハウも込でまとめます。
運用編
割と重要な考えだなと思っているのが、だいたいの場合においてデザイナーはそのプロジェクトにgitに導入する人じゃないということです。
なので導入編といったものはこの記事に書くつもりがないです。
最初は特に使うものだけ紹介する。
add, commit, push, pull, merge, fetch, branch, checkout, status, logあたりがぶっちぎり使いますし、cherry-pick, stash, revert, resetあたりを上手く使えたらスムーズに仕事できますよねっていう認識があります。
とにかくここらへんの説明にチカラを注ぐべきです。
さらーっと説明するものは本当にさらーっと終わらせましょう。
たとえばの最初gitを導入する際にgit initするじゃないですか。でも別に導入する立場にない人が知ってたって意味ないから別に知らなくていいんですよ。(個人の主観です)
プロジェクトに途中から参加する人ならgit cloneするじゃないですか。でも一度使ったら次のプロジェクトまで使う必要ないので別にそんなの最初にこのコマンド叩いてねで終わるから知らなくていいんですよ。(個人の主観です)
段階的に説明する
便利な使い方まで含めてまとめて教えるのはキャパオーバーになる可能性高いです。段階的に教えましょう。
たとえば、addはバージョン管理にするaddは個別に指定できるって説明するんだけども、最初の運用の段階はすべてバージョン管理にするよねってことでgit add .ってさせるのがよいかなと思っています。コミットはよい感じの粒度に保つのがいいと思っていますが、使いはじめる前の段階の人にその良い感じの粒度を理解してもらうのはなかなかに骨の折れることだと思うので、運用していく途中で言うのが良いのかなと思いました。レビューの都度、このコミットってうんぬんかんぬんって言ってあげましょう。
段階的に気を付けたいのはオプションについてです。
はじめにあんまりオプションを覚えてもらうのツラいので、使い続けて定着したコマンドのオプションを徐々に紹介していくのがいいと思います。
私も最初はgit branch hogeしてからgit checkout hogeってやってました。git checkout -b hogeでいけるよって最初に言われたとしても「何のコマンドにハイフン何だっけ？」ってなって基本操作さえまともにできていなかったのではないかと思います。
コミットメッセージに絵文字を入れさせる
あくまでもオプション的な考え方なんですけど、こういうかわいいことするとたのしく作業できます！たのしさは習得を促進します！
ちょっと教えてみましょう。
だけでもなんでもいいんです。そのあとで絵文字チートシート紹介しましょう。他に何があるんだろうって興味を持ってもらうのを待ってそれからチートシートです。
[参考]
Gitのコミットメッセージを絵文字から始める
GUIツールを使う。
なぜならターミナルを一度も使ったことがない生き物だからです。
抵抗を持たれないようにGUIツールを使ってもらうのはなかなかよいです。
私が最初に使ったのはIDEに入っているものでした。
GitHub DesktopやAtlassianのSourceTreeが人気で、そういうものはぐぐったら情報が手に入りやすいので、勧めるのはそっちの方がよいだろうと思います。
GUIツールとgitコマンドを徐々に結び付けさせていく。
ずっとGUIツールを使わせていると、ふぬけます。
ふぬけるは言い過ぎだとしても、問題発生に対応するのがあんまりうまくない状態になります。(そんな気がしてるだけです)
使えるようになった！って言っておいて問題発生したらすべて相談きます。(個人の体験談です)
一日何回gitの質問するんだ！って思うんですけど、GUIで操作しているものがgitコマンドで何をしているかの理解がないと、これはどうすればいいんだろう？っていうのが出てくるのは仕方ない気もします。
それで初歩的なことばかりミスしたりします。何回も何回も質問対応することになります。
GUIツールは結局のところしくみみたいな部分を隠してしまっていて、それはそれで実際に使えるようになるからいいよねってお話も正しいと思うんですけど、git自身のしくみとGUIツールでどうやって実現するかの2つを覚えなきゃいけないので、かえって学習コスト高いと思います。
なので、コマンド覚えた方が作業が早いということを認識させていくことがたいせつです。
Pull-Requestをターミナルから送らせる。
あくまでも個人の意見ですが、トラブル解決力なるものがターミナルから操作することで身につくならカンタンなことからターミナル使ってもらうべきです。デザイナーをgitやGitHubに、そしてターミナルに慣れさせる一番のポイントかなと。
初期設定だと呼び出されるエディタがnanoになっていることがあるのでvimに設定変更しておきましょう。vimmerにしておきましょう。
ちなみに、私はvimmerにするとか無理でしょとか思って、Atomを呼び出すようにさせて、パッケージでemoji補完するようにさせてコミットメッセージをたのしくできるようにしています。
git config --global core.editor vim
これでvimになります。別のエディタ指定したければvimってところを別のエディタに変更してください。
設定編
以上のような運用をするので、基本的な設定は先にしておいてあげた方がいいです。
引数なしのgit push
currentにしてます。めんどうなことをしたがらないので、だいたいpushに引数つけてくれたことはないと思います。
git config --global push.default current
force pushを防ぐ
GitHubの設定でできるようになっているので、やっておきましょう。
これができる前までは、間違えてやってしまった人は 極刑 だったのですが、今ではこの設定をしていないGitHubリポジトリのAdminが 極刑 ということになりました。
githubの特定ブランチへのgit push --forceをprotectしてエンジニアの精神崩壊を防ぐ( ꒪﹃ ꒪)ﾌﾞｸﾌﾞｸ
GitHubのメール通知をオフにする
驚くなかれ、メールがたくさん来るから嫌い！って言う人が出てくる。いや言わなくても潜在的に思っていたりする。
「自分で設定変更するだろう？」「自分でメーラー側でフィルターかけるだろ？」って思っているようではデザイナーとの距離は縮まらないのは悲しいですが世の常です。
あれもこれもgitを推進するエンジニアがわるい！ってなりかねない。
人は本質とはまったく関係ないところで何かを嫌いになったりするっていうのはここ最近での学びですのでぜひみなさまが同じ轍を踏んだりしないことを祈るばかりです。
せめて通知が来るものを本当の本当に最小限にさせるくらいにはしておきましょう。
用語編
言葉がごちゃごちゃになるので、ここらへんの明確な区別を
gitとGitHubの違いを超明確にする。
gitは自分のPCに入っています。自分のPCでバージョン管理をします。
でもみんなで作業するので、そのためにWebサービスのGitHubを使います。
gitのpullとGitHubのPull-Request
上に通じますが、初心者にありがちなミスです。
なぜかgit pullとpull-requestを混同します。
場合によってはpullをpull-requestの省略形だと思いはじめます。かわいいですね。
心得編
カンタンって言わない。
基本です。
「カンタンだよ！できるよ！」っていうのはたいていの場合はあんまりよい効果が出ません。カンタン！って言われてできなかったことを思い出すので、その時点で抵抗が出ます。「カンタンだよって言ってたのに私にはカンタンじゃないです(ブチ切れ)」ってなるのは割とままあることです。
それ相応の学習コストがかかるけど、きっちりサポートするからよろしくねと言いましょう。
バージョン管理の必要性を説くのに力説しない。
自分の周りのエンジニアを見ていて思うのですが「バージョンを管理するためにgitが必要なんだ！(ry」って力説するエンジニアが多いです。
デザイナーが返す言葉はこれです。「え？なんかDropboxでいいんじゃないの？」
差分が見られる！
コミットメッセージがうんぬん！
branchの統合がどうたらこうたら。
そういうの使ってみないと理解できない層なんだと思います。
なのでそういうこと言うのやめましょう。
「エンジニアにとって違いが大きいのでどうしてもgitなんだ。その理由を説明するには およそエンジニアの作業の大半を理解してもらう必要性があってそれでも理解したければ説明するけどどうする？ 」
と聞くと、「あー使います。説明は今は大丈夫だと思います！」ってなる気がします。
学習コストかけたくないなって思ったデザイナーという生き物は、およそ駄々っ子と変わらないのです。
gitはノンエンジニアでも使えることをアピールする
これが難しいです。
git使ってるというと社内でエンジニアって呼ばれるくらいで、結構キレそうです。
カンタンと言わずに、でも誰でも使えるツールだという認識を持たせる天才的な方法知りたいです。
学習編
正直なところ学習に対してやる気さえ持ってもらえれば別に困ることはないんですよねー。
ということで、どんなのがいいだろうっていう記事をまとめました。
おすすめ記事編
このあたりは定番で、どこの誰であろうとこれさえ理解できればと思います。
ちょっと深く知ってもらおうと思ったときに以下の2つとかおすすめな気がしますが、だいたいそんな場面ないのかなと思います。
おすすめWebチュートリアル編
ドットインストールは定番ですね。
CodeSchoolは比較的わかりやすいと思います。途中から有料なのが玉にキズですが、割とていねいなのでtry-gitだけでも理解してもらいやすいと思います。
英語です。ごめんなさい。
おすすめ書籍編
GitHub実践入門
定番なんですけど、ちょっと古いのが玉にキズです。gitは問題ないとして、GitHubのインターフェースが変わっていて「これどこのことですか？」って聞かれます。Web制作者のためのGitHubの教科書
教科書シリーズです。シリーズ全体の人気が高い(ようにみえる)からか割と抵抗なく読めるようです。Gitが、おもしろいほどわかる基本の使い方33
読んだことないのですがちょっと気になります。SourceTreeベースで話を進めているらしいです。
あとは個人的にはWEB+DBとかで特集やったりしているのも有効なものが多いと思います。
うちの会社では定期購読しているのでバックナンバー込で見れますが、そうじゃないところもあると思いますしわざわざバックナンバー手に入れるのも大変だと思うので、どの号がなどといった紹介はやめておきます。
以上ですかね。ちょっとあらためて読んでみると当たり障りのなようなgit入門するためにみたいな記事になってしまいましたが、gitに抵抗を持っている人が周りにいるなどといった場合はこの記事が役に立つことを祈ります。