きのこる庭

ご無沙汰です。連載企画を書き進めると豪語しておきながら かなり経過してしまいました。連載企画の方は時間を見つけつつ少しずつ書き進めていければと思います、申し訳ございません。
さて、最近周囲の方にGitの解説をする機会が増えてきたため、今回はGitの基本コマンドに関連する説明をします。

対象読者

・何らかの理由でGitを使う事になったが、コマンドが多くてよくわからない方。
・コマンドごとの意味は何となく理解しているけど、イマイチピンと来ない方。
(※「そもそも何故Gitを使う必要があるのか」「バージョン管理とは何か」といった点については ノンプログラマ向けの連載企画として後日記載させていただければ幸いです)

解説するコマンド

git init, git add, git commit, git status, git log, git branch, git checkout, git merge, git clone, git pull, git push, git fetch

他にも remote, cherry-pick, rebase, reset 等 色々ありますが 本記事ではまず 最もよく使うであろう上記コマンドに絞って解説します。

進め方

何かを学ぶ上で 適切な比喩となるものを想起して イメージを持たせる事はとても大事だというのが個人的な考えです。
ので、今回は Gitを「工場」に見立てて、一人の工場管理者を主体にお話を進めていければと思います。

それでは早速見ていくことにしましょう。

1. 自社工場を建てる

git init: 自社工場を建てる

「git init」という呪文と共に 魔法の杖を一振りすると工場が現れました( 「どうみても爆破しているようにしか見えない」とか言わないで下さい )。

これで製品を開発するための環境が整いました(ただし工場の中身はまだ空っぽです)。この工場の下で 製品の開発を行います。

git add: 開発・修正を行った点の届出

製品をつくる上で、工場ではどの部分を修正・追加・削除したかを届出する必要があります。これが git add にあたります。届出をしないと 出荷用の製品を工場内で登録する際に 変更分が登録されないので注意が必要です。

届出後の製品登録は 責任者であるコミットおじさんにお願いをします。コミットおじさんは git add で上がって来た変更分を出荷用製品として登録する役目を担います。

git commit: 出荷用製品の登録

変更の届出も一通りできたので、今度はコミットおじさんにお願いをして 変更した製品を出荷用に登録します。
これで 変更履歴が正式に工場に記録され、今後製品を自社工場から出荷する際は 変更分を加えた製品が出荷されることになります。

git status: 現状の確認

addによる届出忘れを確認したり、どこまで届出したかを確認したりするために使用します。

git log: 製品を変更してきた履歴を見る

これまで工場内でどういう製品の変更をしてきたかを問い合わせます。
git logでは コミットおじさんに登録してもらった製品登録の履歴が残っており、各履歴には特有のIDがついています。
これにより、「あ、ID番号○○の所まで戻したいのでよろしく」というような事が可能になります。

2. 複数の製造ラインをつくる

製造ラインが一つの場合…

工場内でロボットをつくる際、もしも製造ラインが一つの場合 何が起こるか確かめてみましょう。
早速オーダーがきました。どうやら今回のオーダーはロボットに対して角と羽根をつくるオーダーのようです。実際に作り進めていきましょう。

「ぎゃー不具合がでた！」
「一体羽根と角のどっちの変更でこうなっちゃったんだ？？」
「と、とりあえず羽根を一旦元に戻そう」
「ああ、これ羽根じゃなくて角をつくる時にいじった場所だった！」
「もうこんがらがってわけがわからん！」

ということで、複数機能を同時に並行して開発する場合は 機能ごとに製造ラインを増やした方が良さそうです。そこで…

git branch: 製造ラインを増やす・確認する

「角」用の製造ライン
「羽根」用の製造ライン

二つを分ければ 不具合が出た時に どちらが原因か分かりやすいですね。

git branch では、現在いる製造ラインにおける製品をベースにして 別の製造ラインをつくります。
git では、一般的には「master」という名前の製造ラインがデフォルトで使用されます。色々な製造ラインの分け方がありますが、一例を下に示しておきます。

1. master
2. 角・羽根統合用の製造ライン ( masterからつくる )
3. 角用の製造ライン
4. 羽根用の製造ライン

2をつくるのは、角と羽根の製造ラインを再度がっちゃんこした際に問題が発生した場合、統合用の製造ラインがあると問題が発生した際のトラブルに対応しやすいためです。メインの製造ラインでいきなりがっちゃんこしてしまうと 後々問題が発生した際に面倒な事態に陥ったりすることがあります。

新しい製造ラインをつくる場合は「git branch 製造ラインの名前」を使用しますが、「git branch」のみを入力すると 現在の製造ラインの状況を確認することが可能です。

なお、製造ラインを分けた後の作業は、一つの製造ラインでしていた事と一緒で、基本的には開発作業 → add → commit のサイクルとなります。

git checkout: 作業を行う製造ラインの移動

僕達は人間なので、一般的に一度の時間で一つの作業にしか着手できません(言い換えれば、右手でタスクAを進めながら左手でタスクBを進めるようなことは一般的にできません)。

つまり、一度に一つの製造ラインにしかつけない事になります。
ここで、製造ラインを分けた際、別の製造ラインに移動する方法が必要になります。

git merge: 別の製造ラインの変更をがっちゃんこ

「角」も「羽根」もできたので、あとはくっつけるだけです。こういう時には git merge を使用します。git merge では、ある製造ラインの製品に別の製造ラインの製品をがっちゃんこすることができます。

修正箇所が衝突した場合

例えば、もし角がこんな感じで背中にくっついている…という仕様だった場合どうでしょう。

角の部分と羽根の部分がもろ被りです。
このままではがっちゃんこできない…こういう状態を「衝突(コンフリクト)」と言い、お互いの製造ラインが話し合いをしてうまくがっちゃんこできるようにすることを「衝突(コンフリクト)を解消する」と言ったりします。

コンフリクトの解消に関しては本記事の題意を越えてしまうため割愛させていただきます。

3. 複数の支社間で連携する

規模が大きくなってくると自社工場だけでは生産・開発のサイクルを回すのが難しくなってきます。
そこで、いよいよ複数の工場を立てて連携する必要が出てきました。

こんな感じで、異なる開発作業を支社ごとに分けて それぞれで 開発を進めて 本社で変更分を統合する形にしましょう。

git clone: 本社から工場の環境をそのまま引っ張ってくる

「git clone」という呪文を唱えると、clone元(この場合本社工場)の環境(製造ライン・製品)がそのまま再現された新たな工場が建ちます。
git init では中身が空っぽの状態の工場が建ちましたが、これが git init と git clone との違いです。

引っ張ってきたら あとは個人で作業していた時と基本的には一緒です。
建設した支社工場の中で製品の追加機能をいじったり 製造ラインをがっちゃんこしたりします。

git pull: 本社の製造ラインから最新の製品を取り寄せがっちゃんこ

本社の特定の製造ラインから最新の状態の製品を取り寄せます。さらにその上で自分の工場にある特定の同様の製造ラインの製品にがっちゃんこ(つまり merge)します。
複数の工場で分担して作業をする場合、本社の一つの製造ラインに必ずしも一人だけしかつかないとは限りません。
つまり、あなたが支社工場の特定の製造ライン(Aとしましょう)で作業している最中にも、誰か他のメンバーが本社工場の製造ラインAに最新の製品を登録しないとは限らないということです。
そこで、基本的には 自分の工場で製品を開発した後は 一度 pull して本社の最新の状態の製品とがっちゃんこする必要があります( なお、この際も勿論 衝突が発生することがあります )。

なお、ただ闇雲にがっちゃんこするのではなく「どの機能をいつ開発したか」など順番を意識してがっちゃんこする際には git pullに加えて「--rebase」という重要なオプションがありますが、こちらでは本記事の範囲を超えてしまうため 触れるのみに留めておきます。

git push: 本社の特定の製造ラインに 自社で開発した製品を出荷

git pushを行う事で自分の工場の特定の製造ラインでつくった出荷用製品を本社に送ります。基本的に、宛先となる工場の場所と製造ラインを指定して送ります。

git fetch: 本社の製造ラインから最新の製品を取り寄せる

本社から最新の状態の製品を取り寄せます。ただし、がっちゃんこはしません。( 言わば、git pullは fetch + merge を同時に行うコマンドということになります )

—

これで一通りコマンドの解説が終わりました。ここまで読んで下さりありがとうございました。間違っている点・アドバイスなどございましたらどしどしご指摘いただければ幸いです。よろしくお願いいたします。

最後に、それぞれの作業工程における比喩の意味を解説して本記事を終えたいと思います。

比喩の意味

1. 自社工場を建てる

自分の開発環境でバージョン管理を始めること。

2. 複数の製造ラインをつくる

複数の機能を並行してつくること。実際、Webサービスを運用する場合、つくるものが同じ時期に1つの機能だけとは限りません。
そういう時に、作業内容がこんがらがらないような仕組みが必要です。

3. 複数の支社間で連携する

これは実際のチーム開発に他なりません。
開発メンバーは各自の開発環境で機能の開発を進めていき、自分の環境で機能がうまく動く状態をつくったらそれを一箇所に集めます。
こうして複数のメンバがそれぞれ異なる開発をしても規律の取れた開発体制が実現できるようになります。