こんにちは。りまりま団のもふもふです。
最近、もふもふちゃんは新卒なひよこエンジニアの人を教育するかかりを仕事にしております。1
これで次の同人誌のネタも安泰だぜ！…ではなくてですね、Gitを使って働いてるんですね。 研修課題のプログラムもGitにブランチ切って共有してね、とかやってます。
なので、大半のひよこエンジニアな人はGitを初めて触るんですよ。
もふちゃんはひよこなエンジニアの人（これ以降、ひよこちゃんとします）にGit研修をやっています。
それと合わせてわかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉を読むとクライアントツールの操作方法・Gitの基本的な用語が理解できるよ、と本をオススメしています。
GitクライアントはSourceTreeを利用しています。ひよこちゃんはCUIを利用する場面が少なかった人が多いです。なので、ただでさえ難しいGitにCUIを足したらもう覚えるのは嫌になっちゃいますよね。
というわけで、ブランチの流れを追いかけやすい＆GUI操作で完結するSourceTreeを利用しています。改行コードの設定とか、.gitignoreの設定とかは罠が多い気はしますが、ひよこちゃんにはとってもありがたいツールだと思います。もふちゃんもSourceTreeを通してGit操作の基本を覚えました。2
最初は「概念とかはもふちゃんが口頭で説明して、実際の操作とかはわかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉を渡しておけばなんとかなるやろ！」と思っていました。
しかし、そうもいかないぞ、と最近は思っています。
あ、本が100%悪いとか言っているわけじゃないんです。そこんとこはよろしくです。
そもそもオススメしても本を読んでくれない
だれか〜どうしたらいいんですか！
みんな本をオススメするときってどうやってオススメしてるの？押し付けになるのはよくないと思うのですが、「読んでみるといいよ〜」って言って読んでくれるのは時間をかけて勉強すれば自律的にGitを覚えられそうな人が多いんですよ。本当に必要な層（よくわかんないけどコピペで操作してリポジトリ壊しちゃうタイプ）は本立ち読みもしてくれないんですよ。先輩かして〜とかもないんですよ。
そういうとこやねんぞ！っていうとStaticおじさんになってしまうので、いい感じにやんわりと本を読んでもらう方法をだれか教えてほしい。だれか〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜3
indexにステージする所のイメージが持てない
ここからはわかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉だけで理解してもらえなかったユースケースを挙げていきます。章の順番に合わせてユースケースも挙げていきますね。
本ではindexへのステージを
撮影台に（変更点を）載せるイメージ
と解説していました。
でも、本を見せながらひよこちゃんに説明してもイマイチ反応が悪かったんですよ。（たまたまかもしれないけれど）
その時は図を書いて説明し、理解してもらいました。
- ねこちゃんはtest01.mdに3つ変更点を加えた
- Gitさんは「変更点、加えましたか？」と聞いてきている
- 加えた変更を勝手にコミット（記録）されたら困るから、ねこちゃんがコミットするものを選ぶ必要がある
- indexにステージしたものをGitさんはコミットしてくれる
- だから、ここでindexにステージする操作が必要
お好み焼きの説明で理解してもらえなかった理由を考えてみました。
最近は撮影台に載せて写真を取らない
説明に例えを使うの、本当に難しいですよね。例えを利用してわかってもらうためには、
- 普段の生活で馴染みがあるもの
を利用しないと伝えたいことが伝わりにくいのかなと思いました。
というのも、ひよこちゃんに本を見せながら「撮影台がね…」みたいな話をしたら「？」って表情だったんですよ。今はスマホで写真がすぐ撮れちゃう時代ですからね。そりゃ撮影台って言われてもピンと来ないよね。ってあとで思いました。
なので、SourceTreeの操作画面は本を見せつつ、ねこちゃんの話を一緒にすることで理解してもらうように心がけています。大事なのは本の説明の良し悪しではなく、相手の反応をみながら説明方法を変更して対応することなのかなと思います。手数は大事ってことですね。
Masterブランチの追いかけ方がわからない
本ではリモートリポジトリのmasterブランチからローカルリポジトリのmasterブランチへpullする方法が解説されています。これは基本中の基本ですし、SourceTreeの画面キャプチャも載せてあって丁寧に解説されているなと感じます。
ただし、仕事をするときはリモートリポジトリのmasterブランチに変更を加える場合、Pull Request（またはMerge Request）を挙げてレビューを受ける形になります。そもそもリモートリポジトリのmasterは直接pushができないようにロックされていることが多いです。
ということは、開発用にブランチを1つ作成し、そちらにコミットを作る→pushするフローになります。これを図で表すと、次のようになります。
このシチュエーションを整理すると
- 開発用ブランチ
developをローカルリポジトリに作成した。4/1に実施。 - リモートリポジトリに
developをpushした。 developブランチにコミットを作った日は4/10が最後。- 今は4/20。4/20時点でリモートリポジトリの
masterには20コミット追加されている。
ローカルリポジトリのmasterにどうやったらリモートリポジトリのmasterの変更を反映すれば良いかわからない
リモートリポジトリに変更が反映されていたら、ローカルリポジトリに変更内容をダウンロード＝pullする必要がありますよね。まずひよこちゃんはここでつまづきます。なんでか？それはローカルリポジトリにブランチが2種類あるのでどちらのブランチに変更をpullすれば良いかわからないからです。
こういうときは、まず
- リモートリポジトリにあるブランチと同じ名前のローカルリポジトリのブランチ、2つの状態を合わせる
という話をします。
今回の場合、リモートリポジトリのmasterとローカルリポジトリのmasterを合わせた方が良い、と判断できます。
よって、操作的には次の図のようになります（青字の部分）。
本の例はブランチが1本しかないので、この考え方を伝えることが難しいです。毎回4本線を書いて、「今はどうなってる？」と聞いて理解させる工程を踏んでいます。
ローカルリポジトリのmasterからローカルリポジトリのdevelopに変更を反映させる方法がわからない
ローカルリポジトリのmasterの更新ができているひよこちゃんでも、この部分を自力でやって〜というとお手上げになる人が多いです。もふちゃんも最初は理解できませんでした。
これも図を書いて見せていきます。
まず、本にもある通り
マージ（merge）はブランチを統合することができる
という話をします。
次に、今回やりたいことをひよこちゃんに説明させます。
developブランチは4/10から4/20までにmasterブランチに追加された変更は反映できていません。
だから、ローカルリポジトリのmasterブランチの変更点（20コミット分）をローカルリポジトリのdevelopに反映させたいですよね。
よって、developブランチへmasterブランチをmergeします。
この操作を図に書くと、次のようになります（緑線）。
この考え、戸惑う人が多いのですが、本では解説されていません。良い説明が見つかるまでは、毎度線を書いて一緒に動作を確認するしかなさそうです。だれか〜いい説明あったら教えて！です。
コミットログにWhyを書きましょうと言っているのに、操作例ではWhatを書いている
本の75ページでは、
なぜ、毎回コミットメッセージを書かないといけないのでしょうか？ それは「なぜ変更したか」を記録するためです。 コミットすると、自動的に次の事柄が記録されますね。 「When......いつ変更したか」 「Who.......誰が変更したか」 「What......何を変更したか」 ところが、「Why.....なぜ変更したか」は自動的には記録されません。 修正を加えた本にしか知り得ないからです。よって、コミットメッセージで書き表す必要があるのです。
もうほんとこれは名言でめっちゃいいこと書いてあるんですよ。「なんでこの実装にしたの？」とか「この変更点の意図は？」とかやりとりするのはお互い消耗するので嫌なんですよ。だからこの解説は最of高なのです。
…が、「コミットしてみよう」の章のコミットログ例をよく見ると
お好み焼きのタネを作成 具材を追加 隠し味を追加
..etcとなっています。ま て や 。
この例、全てWhatのコミットログです。こちらが知りたいのは
- なぜお好み焼きのタネのレシピを書こうと思ったのか？
- なぜ具材を追加したのか？なぜこの具材なのか？
- なぜ隠し味を追加しようと思ったのか？なぜコーラなのか？
です。これがWhyなんですよ。コラムで超いいことが書いてあるのに、本編にそれが反映されていないと台無しです。実際、ひよこちゃんには100回以上
- 変更点を書くな、変更の意図を書いて
と言っています。これめっちゃ時間取られるんですよ。もふちゃんはいいんですけどね、普通に働きながらひよこちゃんの面倒を見る人は辛そうです。
せめて
- お好み焼きが食べたいのでレシピを共有する
- 歯ごたえが欲しいのでキャベツも追加
- 美味しいもの同士なら混ぜても美味しくなるだろうから、美味しいコーラを追加
というように、変更点の理由をコミットログに含めて欲しかったです。
コミットの作り方
本ではコミットの作り方（単位を小さく）やpushのタイミングは解説がありません。もうこれは他の人のリポジトリを読んだり、自分で巻き戻しができない（泣き）となって覚えてもらうしかないと思います。誰か良い解説記事を知っていたら教えて欲しいです。
ひよこちゃんの感想
…とまあわかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉ではカバーできていない部分ばかりあげてしまいました。あ、Disってるわけじゃないんですよ？
実際購入したひよこちゃんに感想を聞いてみると
用語（commit/pushなど）の意味がわかりやすく書いてあった
という声が多いです。基本操作はしっかりとカバーできるし、画面キャプチャが多いので本を横にみながらスムーズに操作できるのではと思います。
まあ、仕事でバッチリ使うシチュエーションとわかばちゃんのシチュエーションは全然違うので、ギャップが出るのも致し方ないかなとは思います。
ひよこちゃん、頑張って一緒にGitマスターしていこうな！
