【gitをソフト開発で使いこなそう!:第8回】gitを実際の場面で使ってみよう

次回の記事

terapotan.hatenablog.jp

前回の記事

terapotan.hatenablog.jp

連載記事一覧

terapotan.hatenablog.jp

具体的にどうやってgitを使うんだ?
実例1:メモ書きを管理する
実例2:そんなにソフトの規模が大きくないソースコードを管理する
実例3:規模が大きいソフトのソースコードを管理する
次回予告
う－ん、よく分からん！
参考文献

具体的にどうやってgitを使うんだ?

これまで7回に渡って、gitの操作方法について説明してきました。
ですが、これだけだと「こういう機能があるのは分かったけど、実際どうやって使うの?」となってしまうかもしれません。

そこで今回は、具体的にどうやってgitを使うのか見ていくことにします。

Column:チートシート

この連載で見てきたように、gitにはたくさんのコマンドが存在します。使う頻度が低いのも含めれば、数えきれないほどのコマンドがあるでしょう。
当然すべてのコマンドを覚えきるのは不可能ですし、覚えても何か月か経てば忘れてしまいます。

コマンドを忘れた時は、検索して使い方を調べればいいのですが、忘れる度に検索するのは少し面倒です。よく使うコマンドだけでも、一枚の紙にまとまっていれば便利です。
このカンニングペーパーのようなものをチートシートと呼びます。
チートシートはgitだけでなくC#やBlenderなど様々なものに対して作られています。

「いちいち検索するの面倒だな」と思ったら、自分でチートシートを作ってみるのもいいかもしれません。

実例1:メモ書きを管理する

パソコンに保存したメモ書きをgitで管理することを考えてみましょう。

メモ書きの内容

自分用のメモ書きを人に見せることはまずないでしょう。
ですから、ブランチの機能を使わずひたすらコミットしていくだけでいいのではないでしょうか。
ブランチの内容

これだけでも、

間違ってメモ書きを消してしまってもすぐに戻せる
変更前のメモ書きに戻したい時にすぐ戻せる
どこをいつ変更したのかが、すぐに分かる

といったメリットを得ることが出来ます。
実例2と実例3では、ブランチの機能を使う方法を紹介します。
ですが、自分だけで気軽にgitを使いたいのならこういう管理方法もありだと(個人的に)思います。

実例2:そんなにソフトの規模が大きくないソースコードを管理する

今度は、あまりソフトの規模が大きくないソースコードを管理することを考えてみましょう。
先ほどと同じように管理してもいいですが、今回は少し違う形で管理してみましょう。
実例2のブランチ説明図

先ほどの例では、内容に変更を加える時はmasterブランチにコミットしていました。
しかし、今回の例では、developブランチをmasterブランチから新たに作ってそのブランチに変更をコミットします。
機能の追加が終わったら、developブランチをmasterブランチにマージします。

何個かの機能の追加を一緒に進めたい時は、その機能ごとにブランチを作成します。
例えば、「〇ボタンを押すとキャラがジャンプする」という機能と「△ボタンを押すとキャラが自爆する」という機能を一緒に(同時並行で)追加したいとします。

この時二つの機能を一つのブランチで追加しようとせずに、それぞれ別のブランチを作って追加します。
上の例であれば、「jumpChar」と「suicideChar」というブランチをmasterブランチから作成します。

このような運用にすることで、次のようなメリットがあります。

機能を追加している途中でも、完成版のソースコードを取ることが出来る
今どの機能を追加しているのか、機能の追加はどれくらい進んでいるのかが一目で分かる

実例1の方法でやろうとすると、今ソフトに機能を追加している最中なのか、機能の追加が終わって完成したのかわからなくなってしまいます。(全て1つのブランチで管理しているため。)
また、完成したソースコードを取ってこよう!と思っても、完成したソースコードに既に変更が加えられている場合、取ってくるのは簡単ではありません。(HEADを前のコミットに戻さないといけない。)

今回紹介した方法を使えば、今何をやっている最中なのか一目でわかる上に、masterブランチに移動するだけで機能を追加し終わった(完成版)のソースコードを取ってくることが出来るようになります。

実例3:規模が大きいソフトのソースコードを管理する

実例3では、規模が大きいソフトをgitで管理する方法を考えていきます。
下の図は、実例3で解説する運用方法の表した図です。図の左側にあるmaster、develop…はブランチ名を表しています。

規模が大きいソフトの管理方法

…どうでしょうか。実例2と比べてブランチの数が増えている上に、矢印もいっぱいあってなんだか複雑そうです。
このブランチの管理方法は、git-flowと呼ばれています。(私が考えたものではありません。)

実際複雑なため、これを簡単に行えるようにするgit-flowという専用のツールがあります。(git-flowは管理方法の名前でもあり、ツールの名前でもあります。)

今回の記事では、git-flowの大雑把なやり方のみを紹介します。
詳しい解説やツールの導入について知りたい方は、このページの下にある参考文献をご覧ください。

Column:実例2でいくのか、実例3でいくのか

git-flowは、先ほども言った通り複雑です。
それだけでなくツールの導入も少し癖があり、ある程度慣れていないと難しいでしょう。
まだgitの操作に慣れていないうちは、実例2の方法で管理して、慣れてきたらgit-flowのやり方を少しずつ導入してみるのがいいでしょう。

タイトルの1～7の番号は、図の①～⑦と対応しています。

各ブランチの役割

masterブランチは、公開用のソースコードを指しています。
masterブランチにまだ公開してはいけないもの(まだやりかけの機能追加)はコミットしてはいけません。
developブランチは、開発用のブランチです。
featureブランチは、機能追加用のブランチです。実際の機能追加はこのブランチで行います。
releaseブランチは、ソフトのリリース(公開)の準備のために使うブランチです。
hotfixブランチでは、現在動いているソフトのバグの修正を行います。