"BOKU"のITな日常

還暦越えの文系システムエンジニアの”BOKU”は新しいことが大好きです。

Gitの標準的運用「A successful Git branching model」について/自己流チュートリアル(2)

GitHubを真面目に使う目的で整理していく第二回目です。

今回は、有名なGitのブランチモデル「A successful Git branching model」を仕事とかでよくあるパターンにあてはめてみて、自分なりに消化してみます。

f:id:arakan_no_boku:20190811144704p:plain

 

GitHubとGitの使い方を3回にわけて整理します。

 

GitHubとGitをもう少し真面目につかうべく、以下の3回にわけて整理しています。

  1. インストールと環境設定
  2. A successful Git branching modelの理解
  3. Gitコマンドを使って一連の作業を実践する

リモートリポジトリは、GitHub、クライアント側は「Git for windows」です。

今回は、その2回目です。 

さて。

A successful Git branching modelとは何かというと、それなりの開発プロジェクトでGitを使う時の、デファクトスタンダード的なブランチの使い方です。

元の記事はこれです。

nvie.com

それを、日本語訳していただいたのがこちら。

qiita.com

Gitを使うにあたって、自分で再発明するのは愚の骨頂なので、先人の知恵は拝借しつつ、わけもわからず型だけ真似るのは最悪なので、自分なりに整理して消化してみようというのが今回の目的です。

なので。

自分の経験してきた実務の感覚と、A successful Git branching modelをつきあわせるアプローチで整理してみました。

結論から言えば、かなり実用的な内容だなと思っています。

 

なんで実用的と思うのかというと

 

実際に関わる状況に、スッキリとはまるからです。

例えば、仕事で開発・運用にかかわっているとします。

すると、頻繁に以下の3つの状況に関わることになります。

f:id:arakan_no_boku:20190814001530p:plain

開発中のものを、いきなり本番稼働に持っていくのはリスクがありすぎます。

なので。

いったん「リリース準備」にまわして、最終的な品質検査(テスト)をしたり、ドキュメントの整備、ユーザへの案内などの準備をするわけです。

それで安全であることを確認してから、本番環境へリリースします。

これが。

パッケージなどの製品を開発するにせよ、社内システムにせよ、システム変更を本番に反映させる際のごくごく一般的な手順です。

他のバージョン管理でも基本的にはこれを意識せざるをえなくて、例えば、Subversionとかだと、開発中が「trunk」で、「branches/releasexxxx」にブランチを作って「リリース準備」して、OKになったら「tags/version-xxxx」にスナップショットを切り出す・・みたいな感じが標準的と言われてます。

だから。

この各状況をGitのブランチモデルにあてはめたのが「A successful Git branching model」だと思えば、とても理解しやすいなと思いました。

つまり。

本番稼働中を保持する「origin/master」。

開発中の「origin/develop」。

リリース準備の「release」です。

orign/とあるのは、役目を終えても消さないブランチです。

releaseは必要なくなったら消す機能ブランチです。

実際の名前としては「release-xxxx」のようにルールを決めて重複しないようにつけることになります。 

図にあてはめてみるとこんな感じですかね。

f:id:arakan_no_boku:20190814215939p:plain

 

本番稼働中の緊急修正の運用もイメージしやすいです

 

実運用で一番困るのは、本番環境で不具合が発覚して、しかも、それが致命的なものだったりして、本番環境を緊急修正しなければいけない時です。

えてして、対象のプログラムは既に次のバージョンに向けて変更されていて、今の本番環境にはもっていけないので、本番リリースした当時のソースをもってきて修正しないといけない・・・。

ちゃんとバージョン管理ができていないとパニックになるパターンです。

かつ。

当時のソースがあってめでたく修正できたとしても、今度はその変更を現在開発中のものにも適用しておかないと、後でバージョンアップした時に同じトラブルを発生させることになります。

そんな時はだいたい、本番環境からリリース準備に切り出して、そこで修正とテストを行い、OKになったら本番と開発の両方に反映させることになります。

図にすると、こんな感じです。

f:id:arakan_no_boku:20190814224800p:plain

A successful Git branching modelでは、そういうケースも考慮されています。

そういう時のリリース準備のブランチは「release」ではなくて、「hotfix」という名前になってます。

まあ。

ブランチを切り出す元になっている環境が違うので、紛らわしくなくていいな・・と個人的には思います。

名前つけとしては「hotfix-xxxxx」って感じで、図におとすと、こんな感じです。

f:id:arakan_no_boku:20190814221503p:plain

 

個々の開発の場合

 

開発者個別の開発のケースを考えます。

いくら「develop」という開発用ブランチを本番とわけているからといって、そこにコミットする時には、ちゃんとコンパイルも通って、かつ、ユニットテストも合格している状態でないと他の人に迷惑をかけるので、少々気をつかいます。

なので。

そのへんを気楽にするため、自分専用開発ブランチを切り出して、そこで作業してOKになってから「develop」にマージする・・という運用をします。

A successful Git branching modelでは、そういう自分専用開発ブランチを「feature」ブランチという名前で呼んでいます。

実際の名前は「feature-xxxx」みたいにしてユニークにします。

f:id:arakan_no_boku:20190814231658p:plain

 

環境の切り替えとか

 

と。

ここで、前提の話でよく話題になることを思い出しました。

DBの接続先とかの設定の話です。

DBの接続先(本番用DBとか開発用DBとか)を直接ソースに書いていて、本番リリース後は本番用DBに書き換えたりしている・・みたいなことをしていると、バージョン管理はとても困難になりますからね。

なので。

本記事の話は、そういうことをしていないことが前提になります。

バージョン管理対象のソースとしては一本で、DB接続先とか環境ごとの違いはUTとかDTとかPRODUCTとかみたいな環境名を記述したバージョン管理外のENVファイルみたいなものを置き換えることで行う・・みたいな工夫がされている。

てな感じですかね。

まあ、そうでない環境って、あんまり見たことはないので、いちいち断るですけど(笑)

 

何となく腹にはまったかな

 

何となく、イメージはできました。

次回は、そのイメージにそって、GitHubとGit for windowsを使って、実際に作業をやってみることにします。

Gitコマンド自体は、A successful Git branching modelにも書かれていますし、それで足らない部分は、GitHub社がまとめていただいたGIT CHEAT SHEETなどを参考にしていこうかなと思っています。

https://github.github.com/training-kit/downloads/github-git-cheat-sheet.pdf

f:id:arakan_no_boku:20190811225017p:plain

ではでは。