Gitのお勉強第n+1幕 - ReAge’s diary

今回も引き続きGitの話です。

とはいえ前回まで(個人的に)細かく書きすぎたので今回はさっくりまとめたいと思います。

内容的にはシンプルだけど大事なお話であるGitのワークフローについてです。

いきなり初心の話ですが、Gitはバージョン管理ツールであり、その目的は共同作業をサポートするための役割を大きく担っています。

共同作業をするということは多かれ少なかれ複数の人間が携わることになるため、運用に当たって一定のルールというものがあります。

ただ、Gitというものは性質上とてもオープンなものなので、あくまでGit自体に制約があるわけではなく、Gitを採用しているプロジェクトで固有にルールを定めています。

ただそのルールもある程度のベースがあり、それをプロジェクトに合わせてアレンジして使っていたりするらしいです。

(この辺は自分で参画してみないとわからないですね)

で、そのベースというのが有名なところで"git_flow"と"GitHubフロー"というもので、検索するとそれなりに出てきます。

この2つは色々と違いがあるらしいですが、『核となるブランチがいくつあるか』が大きな違いといえます。

具体的には、git_flowでは常に完成リリースのみをマージする"master"ブランチと、そのリリースに向けて実装作業を行う"develop"ブランチの2つがあります。

※名称はプロジェクトによって異なるかもしれません。要は役割が異なる2本のブランチがあるということが重要です。

git_flowでは下記のように開発～リリースの流れを組むことになります。

※途中参画の場合は1からになりますが、一応そこができるまでの流れも記載しています。

0.　そもそもリポジトリ自体新しく作る場合

まず"master"と"develop"のブランチを作る必要があります。

リポジトリのルートディレクトリで"--allow-empty"スイッチを付けてコミットします。

これで何もない空コミットが作成できるため、ここをスタート地点として新たに"develop"ブランチを作ることができます。

1.　作業用のブランチを作る

"develop"ブランチを作成できたら、今度はそこから自分の作業用のブランチを作成します。

あくまで"develop"はリリースに向けての共同作業用ブランチなので、そこからさらに個々のブランチを作成する必要があります。

ブランチの名前はプロジェクトによって規約があると思いますが、慣例としては"feature/[対応名称]"という命名になることが多いようです(要調査)

2.　個別ブランチを"develop"ブランチにマージする

さて、実装作業が一通り終わったらリリースの準備です。

前の手順でブランチを分けていたということは、リリース用に再度マージする必要があります。

ここで重要なのが、マージの際に早送りマージを許可しないということです。

早送りマージをしてしまうとコミットの時間をすっ飛ばしてしまうことがあるため、それを避けるために意図的に抑制してあげる必要があります。

早送りマージの抑制には"--no-ff"スイッチを使用します。

後は普通のマージ作業です。

3.　"develop"ブランチから"release"ブランチを作る

"develop"に全てマージが終わっても、いきなり"master"にマージするわけでありません。

まずは"release"ブランチを作成します。

この際、ブランチの名前にはリリースするバージョンを明示します。("release-1.0"など)

4.　対象のファイルのバージョンを更新する

ブランチを作成したら、リリース対象のファイル内で記載管理しているバージョンをリリースバージョンに合わせて更新し、それをコミットします。

またテストやバグ修正もここで行いますが、"develop"にはこの段階では戻しません。

5.　"master"にマージする

ここまで準備ができたら、ようやく"master"にマージができます。

色々と段階を踏んできているので、ここですることは本当にマージだけです。

6.　バージョンを示すタグをつける

マージが終わったら、ブランチ内をログで追いかけやすいように、バージョン名を示すタグを付けます。

また、この時のコミットコメントにもバージョンリリースの旨を記載します。

7.　"develop"にマージする

リリースが終わったら、それを"develop"にもマージしましょう。

これで"develop"側も最新の状態に同期できます。

8.　"release"を削除する

全て最新でリリースしたら、"release"ブランチは不要となったので削除します。

使わなくなったブランチは削除してクリーンにする、というのがgit_flowの大事な部分です。

ここまでがgit_flowの流れです。

少し面倒な部分もありますが、これにより作業ログは必要なものだけでクリーンになるという大きな効果があります。

GitHubフローの場合

GitHubフローは、核になるブランチは"master"1本しか持ちません。

また、各ブランチを作る際には"master"から直接派生させ、完了後はそのままマージします。

ブランチの削除も行いません。

GitHubフローによる大きなメリットは、迅速性に特化しているということです。

"master"に対して直接マージを行っているため、変更はすぐに反映されます。

それこそ実運用をしているものを直接更新しているわけですから。

git_flowに比べてかなり説明は短くなりますが、それぐらい手順がスキップされているということになります。

それぞれ一長一短なところもありますし、あくまで今回出した2つのフローはほんの一例とのことなので、調べればもっとたくさん出てくると思います。

(今回はできるだけ早い習得のためなので私は割愛してますが...)

Gitはまだまだ奥が深いということを痛感させられる次第です。

あ、結局長くなっちゃいました。

短くまとめるのって難しいですね...。