こんな状況

結構あると思われる以下のような運用の流れ。

1. 修正依頼
2. 対応
3. テストアップ
4. クライアント確認
5. 本番公開依頼
6. 本番公開

テストサーバで確認して本番に上げるフロー。
そしてこういう依頼が何本も同時進行しているような状況を想定します。

発生する問題

上記のように依頼が何本も走っている場合、
別々の依頼で同じファイルの別の場所を変更したりする場合があります。
例えばひとつは本文の修正で、もうひとつはサイドメニューの修正だったり。

この場合、テストアップだと両方修正されていても大丈夫ですが、本番公開依頼が片方だけだと一方のみ修正を反映させた状態で公開しなくてはなりません。

テストアップしたファイルとは別のファイルを用意しなきゃいけないとか・・・本当に無駄で手間ですね。

そこで、なるほどココでコレかという機能がGitにあります。

ブランチ（branche）

Gitはブランチによって、本流（master）とは違う別の軸を持つことができます。（図1参照）

コマンドだと以下の様な感じでブランチ作成。

$ git branch hogehoge #hogehogeという名前のブランチを作成

ブランチの切り替えを行うには、

$ git checkout hogehoge

こうすることによって、本流を汚すことなく本流のコピーで修正作業を行うことができます。

先程問題になっていたひとつは本文の修正依頼でもうひとつはサイドメニューの修正依頼というような場合には、以下（図2参照）のようにブランチをきって

図の「branche1」では本文の修正、「branche2」ではサイドメニューの修正という具合にしておけば、
お互いに修正した部分はお互いに影響を与えることなく別々のファイルを用意できます。

ブランチを利用した運用フロー（考えてみた）

ブランチを利用して運用していく場合、一定のルールを設けないと余計に管理が難しいです。
なので自分なりに運用フロー（？）的なものを考えてみました。

僕なりのポイント

• 公開用ブランチと修正用ブランチを分ける。
• 公開用ブランチは公開するデータの管理のみ。ファイルの修正等はしない。（マージはする）
• 修正用ブランチは修正を行うのみで、このブランチを公開することはしない。

ポイントを図で表すと以下（図3参照）のようになります。

上の図ではマスターを公開用ブランチとしています。
修正依頼が来たらマスターからブランチを作成しそのブランチ内で修正をします。公開する場合はそれをマスターへマージさせてマスターブランチから公開作業をします。

なぜこんなことを

色々と考えてみたのですが、やはり本流をひとつ確定させておかないとどこが最新のデータか分からずに、結局先祖返りなどが頻繁に発生してしまうことになると思います。
確実なデータだけをマスターにマージしてそれを公開するのが一番安全と考えました。

さらにテストサーバも組み込む

上記の運用にさらにテストサーバでの確認もプラスすると以下（図4：テスト公開用ブランチも含めた公開までの流れ）のようになります。

テスト用の公開ブランチをひとつ増やすだけで、やっていることは変わりありません。

マスターからブランチを作成し修正、テストへマージしてテストアップ、公開の許可が出たブランチをマスターへマージして公開します。

このように運用することで、問題だった同じページヘの別々の修正も許可の出たものから順番に公開することができます。

まとめ

この運用の流れは、以前に知り合いから聞いた「1チケット、1ブランチ」という言葉をヒントに考えてみました。
「チケット」はRedmineなどで使われる表現ですが、ざっくり言うと「依頼」とか「タスク」だったりってことだと思ってます。

このフローの問題としてはまだまだ、

• マージが頻繁に出てくるのでマージ慣れしなきゃならん
• ブランチも頻繁に出てくるので、ネーミングルール、削除のタイミングなどを整備する必要がある
• もうこうなったら「tag」も使っていきたい

とかっていうのが考えられます。
このあたりはもしやろうっていう流れになった時に話しあったりして行きましょう。

しかし、Redmine使いたいですね。

※何か書いてきたことの穴だったり、間違っていることがあったらご指摘ください。