- Coding Methodology
- 第91回 CMS組み込みまでの案件におけるGitルールの例
第91回 CMS組み込みまでの案件におけるGitルールの例
いまやどのような規模のプロジェクトであっても、Gitによるバージョン管理が普及しています。その際に大切なのは、正確で明瞭なルールです。今回は、静的なページの作成と、作成したページをCMS へ組み込む作業が並行するプロジェクトでのGit ルールの一例をご紹介します。
概 要
今回のプロジェクトは、ページを静的にコーディング後、EC 系のCMS に投入していくというもの。規模が大きいので、事故が無く、かつできるだけシンプルに運営することを目指して、Git ルールを考案しました。
参考にしたもの
A successful Git branching model
http://nvie.com/posts/a-successful-git-branching-model/
効率的なバージョン管理を行うため、Vincent Driessen 氏によって開発されたブランチモデルです。
今回は、各ブランチの命名と、運用方法を大まかに参考にしました。
コーディングファクトリーで採用しているGit ブランチ・ルール
開発用ブランチでコーディング後、チェックするための「check」ブランチや、「master」には純粋に完成品＝納品物だけになるようにするなど、CF 内でのGit ブランチ・ルールも参考にしました。
今回のプロジェクトのGit ブランチ・ルール
develop - dev_xxx
開発用ブランチ。コーディング・修正作業の集積場所。
個人ごとのブランチ dev_xxx(xxx は担当者名) で作業し、チェックする時に developにマージする。
check
チェック用ブランチ。
develop の内容をマージして、チェックする。
master
チェック完了後の完成したデータ（最終の check の中身）の置き場所。
release
CMS 登録作業用ブランチ。CMS 登録作業者は、master のデータをここにマージしてソースを開き、CMS 管理画面から流し込む。
hotfix_00( 連番)
システム出力と静的ソースの内容が合わず、表示が崩れてしまうなどCMS 登録時に発見した不整合を修正するブランチ。
作業発生ごとに連番を付与してmaster から新しく作成する。修正後は master と、デグレードを防ぐため develop にもマージする。
運用フロー（上図参照）
- ①develep からdev_xxx を作成、コーディング開始。
- ②ページ完成。develop にマージ後、develop をcheck にマージしてチェック。修正があれば、dev_xxx で修正する。修正完了後、再びdevelop→check にマージ。以後、ページ完成まで繰り返す。
- ③チェック完了！ check をmaster にマージ。
- ④CMS 登録。担当者はmaster のデータをrelease にマージして作業開始。
- ⑤システム出力と静的ソースの不整合発見。hotfix_00 で修正後、master にマージ(⑤-a)。また、修正反映漏れを防ぐためdevelop にもマージ(⑤-b)。
- ⑥CMS 担当者はmaster のデータをrelease にマージ、作業再開。
master とrelease について
今回のプロジェクトの場合、CMS に組み込むことで納品となり、手元に最終版の納品物が残りません。
そのため、 master ブランチには本来、納品物を置きますが、今回は静的コーディングの完了時のデータのみを置くこととしました。
静的コーディングの完了時のデータ＝master ブランチのデータを使ってCMS 組み込みを行っていきますが、万が一何らかの理由でデータを編集してしまっても、master のデータを守るため、CMS 登録の参照用ブランチを作成し、release としました。
今回のルール・ブランチの応用
たとえば、release はクライアントへのプレビュー用としたり、開発が複数社にまたがる場合は、dev_xxx を「dev_( 会社名)」として全社の作業をdevelop に統一すると、master から複数の開発ブランチが伸びることなく、管理がしやすくなります。開発 中にクライアント側で作業が発生し、それを開発側にも反映する場合は、hotfix を使えば、開発側とのデグレードも防ぐことができます。
