gitブランチの名前の付け方2

以前、gitブランチの名前の付け方について紹介したことがあります。

gitのブランチの名前の付け方

実際に定着している名前は、次の4つです。
プロジェクトによっては、master、developだけで済ましてしまうこともあります。

(1) master
製品ブランチ

(2) develop
リリース前の確認用ブランチ

(3) personals/aoki/develop
開発者ごとの作業ブランチです。developからブランチします。

(4) personals/aoki/1
一時的な作業ブランチです。最後の数字はチケット番号です。personals/aoki/developですでに作業中のとき、別チケットの作業をしたいときの一時的なブランチです。developからブランチします。コミットして、developへマージしたら、すぐに削除します。

今は使わなくなった方法も紹介しましょう。

(ボツ1) ブランチ名に機能の名称をつける

チケットにする前の実験的な機能を試したいときに、ブランチ名に機能の名称をつけたことがあります。

例えば、
develop_camera
develop_news

コレという名前を考えるのが面倒でした。チケットを起こしてチケット番号をつけたほうが楽です。そもそも実験的なので放置することも多く、何をやっていたかを覚えていないこともあります。チケットにアイデアをメモしておくと、何をやっていたか思い出しやすくなります。

(ボツ2) 複数の作業ブランチ

gitは簡単にブランチ作成できることもあって、
personals/aoki/1
personals/aoki/2
personals/aoki/3
といったように、複数の作業ブランチを作成していたことがあります。

confictの解決も手間ですが、conflictがなかったとしても、マージ操作自体が面倒でした。

例えば、personals/aoki/1の作業が一段落したら、
personals/aoki/1からdevelopへマージ
developからpersonals/aoki/2へマージ
developからpersonals/aoki/3へマージ
する必要があります。

さらに、他の開発者がdevelopへpushしたら、
developからpersonals/aoki/1へマージ
developからpersonals/aoki/2へマージ
developからpersonals/aoki/3へマージ
する必要があります。

このようにブランチ切り替えとマージ操作が多くて面倒だったので、ブランチを作りすぎるのもどうかと感じました。

「継続的デリバリー」という本では、複数人で開発していても、メインブランチ1本を推奨しています。ブランチ間のマージが面倒になるため、またメイン以外のブランチは自動テストしないことが多いためです。また、少なくても1日に1回、たいていは1日に数回コミットすることも推奨しています。

gitのブランチの名前の付け方

かつてSubversionを使っていたときは、ほとんどブランチを使ったことがない。慣例にしたがってtrunk、branches、tagsを用意するものの、trunkだけを使っていた。ブランチとタグの違いを理解していなかった。ブランチ操作を難しいものと思い込んでいたし、「変更履歴」と「以前の状態と比較できる」だけで満足していた。

gitを使うようになってからブランチ/マージを試してみたら、あっけないほど簡単だった。日常的にmasterブランチと開発ブランチを使うようになった。

するとブランチの名前の付け方を考えるようになった。最初はmasterとwork。次の段階では、チケット番号をつけてwork_1234 や ticket_1234で作業するようになった。この程度のざっくりとした運用で問題はないのだが、標準的なブランチ名の付け方や運用方法があるなら、知りたいと思っていた。

素晴らしい記事を発見した。ブランチは5個あるが、各ブランチの目的と運用方法が明確で迷うことはないと思う。

O-Showさんの日本語訳
http://keijinsonyaban.blogspot.jp/2010/10/successful-git-branching-model.html

Vincent Driessenさんの原文”A successful Git branching model
http://nvie.com/posts/a-successful-git-branching-model/

中央リポジトリ(例 github)

・master 現在の製品バージョン。
・develop 次回リリースの開発用。

開発者リポジトリ

・feature- 新規機能の開発用。developから分岐し、developへマージする。
・release-
 次回リリースの準備用。developから分岐し、developとmasterへマージする。
・hotfix-* 現在の製品バージョンのバグフィックス用。masterから分岐し、developとmasterへマージする。

※このブランチモデルをベースにしたgit-flow というプラグインもある。

gitブランチの名前の付け方2

デプロイ先を切り替えてgit aws.pushする

【環境】

PC: Windows7、git、AWS Elastic Beanstalk Command Line Tool
サーバー: AWS ElasticBeanstalk

AWS ElasticBeanstalk(以下EBT)はロードバランサーとオートスケーリングサーバのパッケージである。コマンドプロンプトのgit aws.configでデプロイ先を設定し、git aws.pushでデプロイする。

デプロイ先が一つだけなら最初に1回だけgit aws.configをすればいいのだが、デプロイ先として本番環境、ステージング環境、開発環境など複数ある場合、毎回aws.configするのは面倒である。ここではデプロイ先を切り替えてgit aws.pushする方法を説明する。

環境1
AWSアカウント1>EBT>Application=hoge1-app>Enevironment=hoge1-env
環境2
AWSアカウント2>EBT>Application=hoge2-app>Enevironment=hoge2-env

【方法1】

環境1用のgitフォルダD:\hoge1、環境2用のgitフォルダD:\hoge2と別々に用意する。リモートリポジトリを経由してD:\hoge1とD:\hoge2を同期する。

D:\hoge1で開発作業、commit
D:\hoge1で環境1へgit aws.push

D:\hoge1でリモートリポジトリへpush

D:\hoge2でリモートリポジトリからpull
D:\hoge2で環境2へgit aws.push

※リモートリポジトリ
インターネットを介して複数人で作業する場合はgithubが便利である。無料プランは非公開リポジトリを作成できないが、有料プランにすると非公開リポジトリを作ることができる。
一人gitでLAN内作業の場合は、共有ドライブ(ローカルドライブでもよい)が手軽である。エクスプローラ右クリック>Git Create repository here>[Make it Bare]のチェックを付けると、リモートリポジトリが作成される。Git syncのRemote URLに共有フォルダのパス(Z:\gitrepos\hogeなど)を指定すればよい。

【方法2】

1つのgitフォルダ(以下、hogeとする)でデプロイ先を切り替える。

git aws.configは、hoge\.elasticbenstalk\configに設定内容を保存し、git aws.pushはこのconfigにしたがってデプロイする。

hoge\.elasticbenstalk\config

[global]
ApplicationName=hoge1-app
CredentialFile=C:\Users\taro\aws_credential_file
DevToolsEndpoint=git.elasticbeanstalk.ap-northeast-1.amazonaws.com
EnvironmentName=hoge1-env
Region=ap-northeast-1

そこで環境ごとのconfigファイルを用意しておき、バッチファイルでconfigにコピーし、git aws.push する。

まずconfigをコピペして、環境1のconfig-hoge1-env、環境2のconfig-hoge2-envを作成する。AWSアカウントが複数ある場合は、それぞれのaws_credential_fileも用意しておく。

hoge\.elasticbenstalk\config-hoge1-env

[global]
ApplicationName=hoge1-app
CredentialFile=C:\Users\taro\aws\account1\aws_credential_file
DevToolsEndpoint=git.elasticbeanstalk.ap-northeast-1.amazonaws.com
EnvironmentName=hoge1-env
Region=ap-northeast-1

hoge\.elasticbenstalk\config-hoge2-env

[global]
ApplicationName=hoge2-app
CredentialFile=C:\Users\taro\aws\account2\aws_credential_file
DevToolsEndpoint=git.elasticbeanstalk.ap-northeast-1.amazonaws.com
EnvironmentName=hoge2-env
Region=ap-northeast-1

次にバッチファイルを作成する。

hoge\git_awspush_1_hoge1-env.bat

copy .elasticbeanstalk\config-hoge1-env .elasticbeanstalk\config
git aws.push

hoge\git_awspush_2_hoge2-env.bat

copy .elasticbeanstalk\config-hoge2-env .elasticbeanstalk\config
git aws.push

環境1へデプロイしたいときは、hoge\git_awspush_1_hoge1-env.batを実行(またはダブルクリック)し、環境2へデプロイしたいときは、hoge\git_awspush_2_hoge2-env.batを実行(またはダブルクリック)する。