2018-05-06

docker-composeを環境別に使い分けたい

経緯

もともと、docker-compose.ymlで開発環境を用意していた。プレビュー環境構築にあたり、諸々の事情により、プレビュー環境では別途新規に書き起こされたdocker-compose.yml、Dockerfileを使うことになった。既存の設定は開発環境で使いつつ、プレビュー環境では新規の設定を使いたい。

やりたいこと

以下のような配慮をしつつ、Docker環境を使い分けたい。

開発用PCでは、開発用docker-composeとプレビュー用docker-composeを適宜使い分けられるようにしたい。
プレビュー用ホストではプレビュー用docker-composeのみを使いたい。
プレビュー用ホストでうっかり開発用docker-composeで立ち上げることは絶対にしたくない。フールプルーフにしたい。
開発PCでうっかりプレビュー用docker-composeを立ち上げてしまうのも避けたい。逆よりはマシだが。

実現案

docker-composeのファイル名を分ける(例: docker-compose.development.yml)
1. メリット
  1. フールプルーフ
  2. ファイル名を見れば用途がわかりやすい
2. デメリット
  1. docker-compose -fオプションでいちいち指定するのが面倒
    1. だからといってよくつかう環境用の設定ファイルの名前をdocker-compose.ymlにすると、他の環境で使用してしまうというオペミスが発生する
    2. 環境変数COMPOSE_FILEで使用するdocker-compose.ymlを指定すれば対処できる参考: suin.io
      1. メリット
        
        一度設定すれば-fオプションが不要
      2. デメリット
        
        環境構築時、知らない/忘れたひとは-fオプション無しで起動してハマる
        
        README.mdに書いておけばいいのでは
        
        特定ディレクトリ下で環境変数を設定するいいかんじの方法が、自分はまだわからない => dotenvがよさそう。他の開発者と共有しやすそうなので。
        
        dotenv
        
        bashrcに記述 https://stackoverflow.com/a/14463040
        
        tmuxinator
ブランチを分ける。追加開発分は適宜プレビュー用ブランチにマージする
1. メリット
  1. -fオプションが不要
  2. 知らないひとがとりあえずdocker-compose upしてイライラすることもない
2. デメリット
  1. フールプルーフでもフェイルセーフでもない。知らないで適当にdevelopブランチをプルしてきてdocker-compose upするとまずい
    1. previewで動かすとき、developブランチで合ってるのかな？というのは普通に気にするよね?
  2. docker-compose.ymlを変更したとき、おそらく変更がマージされてしまう
差分の設定を上書く
1. メリット
  1. 公式の安心感 Use Compose in production
  2. ブランチを分ける必要がない
2. デメリット
  1. フールプルーフでもフェイルセーフでもない。うっかりするとdevelopmentモードで起動してしまう
  2. docker-compose設定の全体像を把握しづらそう
  3. docker-compose設定を変更しづらそう
  4. 今回のケースだと、docker-compose設定が違いすぎるので、向かなさそう
環境ごとにわけない
1. メリット
  1. 環境が分かれていることによるミスが発生しない
  2. じつは公式にも似たようなことが書いてある (The easiest way to deploy an application is to run it on a single server, similar to how you would run your development environment. If you want to scale up your application, you can run Compose apps on a Swarm cluster.)
2. デメリット
  1. 当然、環境別の変更設定ができない

とりあえずの結論

1つ目の案でやってみる。フールプルーフで、かつ環境ごとに変更できるため。環境変数はdotenvを使って設定する。

2018-05-04

Arch Linuxでvim8でdeoplete.nvimがすんなり動かなかった

やりたいこと

vim8でdeoplete.nvimを動かす

やったこと

deopleteのGithubREADMEに従いインストール
- requirmentsに従いpip install neovim

期待してたこと

vim起動時にエラーが出ない
neocomplete.vimを使ってたときのように、適宜補完が効く

実際に起こったこと

vim起動時、以下のエラーが出る

[vim-hug-neovim-rpc] failed executing: pythonx import neovim
[vim-hug-neovim-rpc] Vim(pythonx):Traceback (most recent call last):
続けるにはENTERを押すかコマンドを入力してください`

解決法

pip install neovimのかわりに、 pacman -S python-neovim すればいいのかな? まったく自信ないです。

参考

調査メモ(読む価値ないです)

python全くわからんが、一応パッケージはインストールされてるっぽい?

~ $ python
Python 3.6.5 (default, Apr 14 2018, 13:17:30) 
[GCC 7.3.1 20180406] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import neovim
>>> import greenlet
>>>

vimでもpython認識してるっぽい

:echo('pythonx') #=> 1
:echo('python3') #=> 1
:echo('python') #=> 1
:echo('python2') #=> 0

vimでgreenletが読み込めない。ファイル開いたらバイナリっぽかった

:pythonx import neovim
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python3.6/site-packages/neovim/__init__.py", line 11, in <module>
    from .msgpack_rpc import (ErrorResponse, child_session, socket_session,
  File "/usr/lib/python3.6/site-packages/neovim/msgpack_rpc/__init__.py", line 10, in <module>
    from .session import ErrorResponse, Session
  File "/usr/lib/python3.6/site-packages/neovim/msgpack_rpc/session.py", line 6, in <module>
    import greenlet
ImportError: /usr/lib/python3.6/site-packages/greenlet.cpython-36m-x86_64-linux-gnu.so: undefined symbol:
 PyExc_ValueError

ほかの普通の?パッケージだとimportできるっぽい

 :pythonx import pycurl #=> エラー出ない

https://bbs.archlinux.org/viewtopic.php?id=232873を見ると、greenletはpacman経由でも入れることが可能で、そちらだと動くっぽい?

sudo pacman -S python-greenlet
:pythonx import greenlet #=> エラー出ない

neovimをpipで入れて、依存してるgreenletはpacmanで入れるって、大丈夫なのか?

なんかpacmanのリポジトリにpython-neovimってあるな。それ入れればいいか。

しかし、既存ディレクトリと衝突し、インストールできないとのこと。ログは以下の通り。

~ $ sudo pacman -S python-neovim
依存関係を解決しています...
衝突するパッケージがないか確認しています...

パッケージ (4) neovim-0.2.2-5  python-greenlet-0.4.13-1
               python-msgpack-0.5.6-1  python-neovim-0.2.6-1

合計インストール容量:  18.82 MiB

:: インストールを行いますか？ [Y/n] Y
(4/4) キーリングのキーを確認                       [##########] 100%
(4/4) パッケージの整合性をチェック                 [##########] 100%
(4/4) パッケージファイルのロード                   [##########] 100%
(4/4) ファイルの衝突をチェック                     [##########] 100%
エラー: 処理を完了できませんでした (衝突しているファイル)
python-msgpack: /usr/lib/python3.6/site-packages/msgpack/__init__.py がファイルシステムに存在しています
python-msgpack: /usr/lib/python3.6/site-packages/msgpack/__pycache__/__init__.cpython-36.pyc がファイルシステムに存在しています
python-msgpack: /usr/lib/python3.6/site-packages/msgpack/__pycache__/_version.cpython-36.pyc がファイルシステムに存在しています
python-msgpack: /usr/lib/python3.6/site-packages/msgpack/__pycache__/exceptions.cpython-36.pyc がファイルシステムに存在しています
python-msgpack: /usr/lib/python3.6/site-packages/msgpack/__pycache__/fallback.cpython-36.pyc がファイルシステムに存在しています
python-msgpack: /usr/lib/python3.6/site-packages/msgpack/_packer.cpython-36m-x86_64-linux-gnu.so がファイルシステムに存在しています
python-msgpack: /usr/lib/python3.6/site-packages/msgpack/_unpacker.cpython-36m-x86_64-linux-gnu.so がファイルシステムに存在しています
python-msgpack: /usr/lib/python3.6/site-packages/msgpack/_version.py がファイルシステムに存在しています
python-msgpack: /usr/lib/python3.6/site-packages/msgpack/exceptions.py がファイルシステムに存在しています
python-msgpack: /usr/lib/python3.6/site-packages/msgpack/fallback.py がファイルシステムに存在しています
エラーが発生したため、パッケージは更新されませんでした。

メモにとってないが、いままでの調査中に、pipやらpacmanやらでneovimとgreenletを入れたり消したりしたような気がしている。衝突の原因はそれな気がする。

どういう副作用が出るかまったくわからないが、/usr/lib/python3.6/site-packages/msgpackディレクトリをmsgpack.bkにリネームした。おすすめしません。その後sudo pacman -S python-neovimしたらうまくいった。

差分は以下の通り。なんか違うね。

/u/l/p/site-packages $ diff msgpack msgpack.bk
共通のサブディレクトリー: msgpack/__pycache__ と msgpack.bk/__pycache__
バイナリーファイル msgpack/_packer.cpython-36m-x86_64-linux-gnu.so とmsgpack.bk/_packer.cpython-36m-x86_64-linux-gnu.so は異なります
バイナリーファイル msgpack/_unpacker.cpython-36m-x86_64-linux-gnu.so とmsgpack.bk/_unpacker.cpython-36m-x86_64-linux-gnu.so は異なります

最後に念の為入れ直す。

sudo pacman -R python-neovim
sudo pacman -R python-greenlet
sudo pacman -S python-neovim

(いま知ったが、pacman -Rには--recursiveオプションがある。sudo pacman -Rs <package>のほうがよかったか。)

以上で完了。vimは期待通り動く。なんかいろいろゴミを残している気がする。でももう面倒だからいいや。

2018-02-18

rubocopでrubyコードのベストプラクティスを学ぶ(Rails + Visual Studio Code)

以下の文章はこんな方を想定しています

vscodeでrailsを書いている。自分のコードをもっと「いいコード」にしたい。が、指導してくれる人間は周囲にいない。

rubocop

github.com

rubyコードの静的解析を行うGem. ベストプラクティスに従っていない箇所を指摘してくれる。ベストプラクティスについてはデフォルトで設定されている。変更もできる。

インストール

公式のインストール方法は以下のとおり。

github.com

自分はbundlerを使いインストールした。

group :development, :test do
+  # コードの静的解析ツール
+  gem 'rubocop', require: false
end

インストール。自分の場合、プロジェクト下のvendor/bundleにインストールされる。

bundle install

以下で解析が走る。(システムにrubocopをインストールされた方は、bundle exec無しの rubocop を実行してください。)

bundle exec rubocop

いい感じの解析ルールを設定する

ネットを見る感じ、デフォルトのルールはそのまま使っているひとはあまりいなさそう。厳しすぎるらしい。

しかし、自分で設定する気は起きない… @onk さんの設定を真似させていただくことにした。

github.com

group :development, :test do
   # コードの静的解析ツール
   gem 'rubocop', require: false
+  # rubocopの解析ルール設定
+  gem 'onkcop', require: false
 end

bundle install
bundle exec onkcop init

自動生成されたファイルを編集する

 inherit_gem:
   onkcop:
     - "config/rubocop.yml"
     # uncomment if use rails cops
-    # - "config/rails.yml"
+    - "config/rails.yml"
     # uncomment if use rspec cops
-    # - "config/rspec.yml"
+    - "config/rspec.yml"

 AllCops:
   TargetRubyVersion: 2.5
   # uncomment if use rails cops
-  # TargetRailsVersion: 5.1
+  TargetRailsVersion: 5.1

rubocop

で走る。解析ルールがrubocopデフォルトから変更されていることを確認する。自分の場合、

- 59 files inspected, 284 offenses detected
+ 58 files inspected, 216 offenses detected

と変化した。(このあたり、間にほかの操作を入れたかもしれません。とりあえず、vim等のテキストエディタでシングルクオートで文字列リテラルを宣言したときに、『[Style/StringLiterals] Style/StringLiterals: Prefer double-quoted strings unless you need single quotes to avoid extra backslashes for escaping.』と怒られるようになっていれば、onkcopのルールが適用されているはずです。)

プロジェクトで動かしてみる

とりあえず試す

bundle exec rubocop で解析結果が出力される。自分が手元のRailsプロジェクトで実行したときは、たしか数百件のアラートが出た。アラートが大量に出るので面食らうが、ほとんどは自動修正できるものか、メトリクス関連(メソッドが長すぎる、など)だった。手動ですぐに直すべき箇所は少ないので、ビビらないでいいと思う。

自動修正する

bundle exec rubocop --auto-correct で、自動修正できるものはしてくれる。自分の場合、アラートは半分以下に減った。修正のほとんどは空白文字関連。自分が面白いと思ったのは以下の自動修正。

&:symbolによる文字数省略

users.map{|user| user.id}
=>
users.map(&:id)

if文(というか返り値があるので式)の返り値を使って代入

if condition
  @user = foo
else
  @user = bar
end
=>
@user = if condition
          foo
        else
          bar
        end

ミュータブルな定数のフリーズ

SOME_CONSTS = %w[aaa bbb ccc]
=>
SOME_CONSTS = %w[aaa bbb ccc].freeze

~~(注: rubyの定数は再代入が可能)~~

(注: rubyの定数はオブジェクトの変更が可能)

【2018/02/20追記 Pocke様からご指摘をいただき修正】

freezeすることで、オブジェクトの変更ができなくなります。上の書き方だと、定数SOME__COMSTSへの再代入は引き続き可能です。変更と再代入を混同し、freezeすると再代入が不可能になるような書き方をしてしまっておりました。修正いたします。

以下、freezeについて調べたメモ。

# 配列をフリーズ
NAMES = %w[yamada sato].freeze
=> ["yamada", "sato"]

# 配列への変更はできない
NAMES.sort!
#=> FrozenError (can't modify frozen Array)

# 配列をfreezeしても、配列の要素の変更はできる
NAMES.map!(&:upcase)
#=> FrozenError (can't modify frozen Array)
NAMES.map(&:upcase!)
=> ["YAMADA", "SATO"]
NAMES
=> ["YAMADA", "SATO"]

# 中身もフリーズすれば、上の操作も防げる
OTHER_NAMES = %w[takahasi akiyama].map(&:freeze).freeze
=> ["takahasi", "akiyama"]
OTHER_NAMES.map!(&:upcase)
FrozenError (can't modify frozen Array)
OTHER_NAMES.map(&:upcase!)
FrozenError (can't modify frozen String)

# freezeしても再代入はできる
OTHER_NAMES = ["bukkowasu"]
(irb):12: warning: already initialized constant OTHER_NAMES
(irb):8: warning: previous definition of OTHER_NAMES was here
=> ["bukkowasu"]
OTHER_NAMES
=> ["bukkowasu"]

【2018/02/20追記 Pocke様からご指摘をいただき修正おわり】

残りを適宜手動で直す

bundle exec --auto-gen で、解析結果のまとめが.rubocop_todo.ymlに出力される。内容を見て、すぐ直せるものは修正していく。メトリクス系(メソッドが長すぎる、等)はおいおい修正したい。

vscodeの設定

vscodeでもrubocop && onkcopが効くように設定する。

プラグインをインストール

以下の公式の記述に従い、Rubyプラグインをインストールする。

marketplace.visualstudio.com

設定ファイルを作成

vscodeの設定にはスコープがふたつある。ユーザーとワークスペースだ。たとえばプロジェクトごとに設定を分けたい場合は、ワークスペース設定を行う。わけなくていい場合はユーザー設定を行う。

以下に従い、ワークスペース設定を開く。

code.visualstudio.com

ruby language settingsを見つける。「設定の検索」欄に『ruby』と入れるとかんたんに絞りこめる。

ワークスペースを適宜設定する。設定は以下に記載がある。

marketplace.visualstudio.com

自分は以下のようにした。

{
    "ruby.lint": {
        "rubocop": true
    }
}

code.visualstudio.com

vscodeを再起動してrubyファイルを開くと、規約に従っていない箇所に緑の波線が入る。たしかにrubocopのチェックが走ることを確認した。指摘のでないかたは、完璧なコードを書いている懸念があるので、おかしなコードをかいてみてください:)

自分はシステムには入れず、プロジェクトのvendor/bundle以下にrubocopを入れているが、特にそれを明示せずともうまく動いた。

2018-01-28

bashの特殊ファイル(.bash_profile, .bashrcとか)のメモ

.bash_profileと.bashrcの違いについてまたグーグル検索。もう何回目だ…

備忘のためにメモしておく。『入門bash』3章、「環境のカスタマイズ」を参考にしました。

以下3つのファイルを意識しておけばよさそう。ユーザーごとの設定。

.bash_profile …ログイン時に読み込まれる
.bash_logout …ログアウト時に読み込まれる
.bashrc …新しいシェルの起動時に読み込まれる

以下のファイルも特殊ファイルとして認識されるが、自分はあまり使う機会はなさそう。これもユーザーごとの設定。ログイン時に.bash_profile, .bash_login, .loginの順に検索される。

.bash_login …Cシェル由来
.profile …Bourneシェル、Kornシェル由来

(.profileについては、他のシェルとの移行|共存がかんたんだよ、ということかな。.bash_loginはCシェル利用者に設計が理解しやすいというだけか?自分はこれらのシェルの設定ファイルを使わないので不要な知識…)

以下はシステム全体の設定。あまり変更することはないだろう。

/etc/profile …ログイン時に読み込まれる

理解が不安な、.bash_profile, .bashrc, /etc/profileの挙動を確認してみた。シャープイコール大なり(#=>)の行はコメント。

#=> まずは.bash_profile, .bashrcの確認
$ echo echo .bash_profile is loaded. >> ~/.bash_profile
$ echo echo .bashrc is loaded. >> ~/.bashrc
#=> bashrc, bash_profileにechoを仕込む。
$ echo $SHELL
/usr/bin/fish
#=> ふだんはfishがログインシェル
$ bash
#=> インタラクティブだがログインシェルではないbashを起動。.bashrcが読まれるはず。
.bashrc is loaded.
#=> 期待通り。
$ bash
#=> bash内でさらにbashを起動してみる。
.bashrc is loaded.
#=> もう一度読まれる。まあそうか。
$ ps --forest
#=> プロセスはこんな状態。
  PID TTY          TIME CMD
18565 pts/0    00:00:01 fish
21358 pts/0    00:00:00  \_ bash
21368 pts/0    00:00:00      \_ bash
21385 pts/0    00:00:00          \_ ps
$ exit
$ exit
$ bash --login
#=> ログインシェルとしてbashを起動。.bash_profileが読まれるはず。
.bash_profile is loaded.
#=> そのとおり。
$ ログアウト
$ echo source .bash_profile >> .bashrc
#=> .bashrcが読まれたら、.bash_profileも読まれるようにする。非ログインシェルでも、ログインシェル立ち上げ時に読まれるコードも読まれるようになる。
$ bash
.bashrc is loaded.
.bash_profile is loaded.
$ echo source .bashrc >> .bash_profile
#=> .bash_profileが読まれたら、.bashrcも読まれるようにする。無限ループになるはず
$ exit
$ bash --login
.bash_profile is loaded.
.bashrc is loaded.
.bash_profile is loaded.
.bashrc is loaded.
.bash_profile is loaded.
.bashrc is loaded.
.bash_profile is loaded.
.bashrc is loaded.
.bash_profile is loaded.
.bashrc is loaded.
.bash_profile is loaded.
.bashrc is loaded.
.bash_profile is loaded.
...
...
#=> 期待通り無限ループ。
^C$ ログアウト
$ vim .bash_profile
$ vim .bashrc
#=> sourceの行を削除して、無限ループにならないようにする。
#=> 最後に/etc/profileの挙動を確認する
$ echo 'echo etc/profile is loaded.' | sudo tee --append /etc/profile
#=> /etc/profile に書き込み。sudo権限が必要なため、このような書き方に
$ bash --login
etc/profile is loaded.
.bash_profile is loaded.
$ ログアウト
$ sudo vim /etc/profile
#=> 片付け。さっきのechoを消しておく
$ vim .bashrc .bash_profile
#=> 片付け。echoを消す

以上

2018-01-01

リファクタリング:Rubyエディション第一章写経してみた

初めて写経というものをやってみた。

ただ本を読むよりも、内容を深く理解できると感じた。

写経すると能動的な頭の使い方になって、内容を深く咀嚼できるのかな。

もちろん普通に読むより時間がかかる。当面は重要な本に絞って写経するようにしたい。

写経の方法は、以下のツイートを参考にさせていただいた。

技術書の「写経」の方法。 1.ローカルで使える SCM を用意 2.「ほんたった」などで対象の本を固定 3.ひたすらサンプルコードを写して実行 4.実行するたびにコミット(コミットログにページ番号を含める) 5.疑問点があったらコミットログや本に書き込む 6.章ごとにタグを打つ
— Takuto Wada (@t_wada) 2010年2月12日

作成したリポジトリを試しに公開してみる。もしほかの方にとって利用価値があるとすれば、テストをRSpecで書いているという点と、個人的に誤記に見える箇所を記録しているという点だと思う。(自分には、公式の正誤表を見つけられませんでした。ご存じの方はご指摘頂けると助かります。)

github.com

2017-11-20

Node.js, npm, electron

Node.js, npm, Electronについて、言葉だけ知っていたが内容や関連がわからなかったので調べてみた。

端的に言うと以下のとおりだと認識した。

JSのサーバーサイド実行環境がNode.js。 Node.jsのパッケージマネージャーがnpm。有名パッケージのひとつがelectron。 electronを使うと、マルチプラットフォームのデスクトップアプリがかんたんに作れる。

以下、もう少し詳しく書く。

Node.jsってなに？

JavaScriptの実行環境。サーバーサイドでJSが動かせるようになる。

$ node
> console.log('hello world!');
hello world!
undefined
> ⏎

npmってなに？

Node Package Manager。公開されているJSパッケージをかんたんに取り込める。パッケージの配布もできる。(自分の場合はインストールの利用が主だろう。) さまざまなパッケージが登録されている。"the world’s largest software registry."とのこと。

npmのコマンドはどんなのがあるの？

このあたりが気になった。

npm -l # display full usage info
npm config list
npm run <command> # Run arbitrary package scripts
npm ls # List installed packages

例えばどういうパッケージがあるの？

electron(デスクトップアプリ作成), Grunt(JSタスクランナー), Webpack(モジュールバンドラー)

electronについてもう少しくわしく

JSでマルチプラットフォームのデスクトップアプリが作れるようになるパッケージ。メインプロセスでうウィンドウを制御する。各ページはレンダラープロセスが担う。

メインプロセスってなに？

プログラムのエントリーポイント。main.jsとかindex.jsという名前であることが多い。例えば、requireされるときにこのファイルの返り値が返される。詳細は下記の通り。 docs.npmjs.com

試しに、インストールしたモジュールの中を覗いてみた。

github.com

上記のelectron-quick-startでnpm installしてから、適当にelectron-downloadモジュールの中を見てみる。 electron-quick-start/node_modules/electron/package.json では "main": "build/index.js", と記載されていた。そして、 electron-quick-start/node_modules/electron-download/build/index.js はたしかに存在していた。

npmに対抗馬はいないの？

yarnがある。npmの欠点を解消すべく作られた。GoogleやFacebookのひとたちも参加してるらしい。 www.webprofessional.jp

余談。yarnは、デフォルトでバージョンのロックファイルを生成する、というのをウリのひとつにしている。 npmでは自動で生成されないということを示唆していると思うのだが、electron-quick-startをnpm installしたら、package.json.lockが生成された。どういうことだろう…npmも自動生成するようになったのか？node, npmのバージョンは下記の通り。

$ npm --version
5.5.1
$ node --version
v9.2.0

以上

2017-06-24

git-flow調査メモ

git-flowとは?

Gitの活用ガイドライン。
Gitは自由。運用方法は強制されない。いろいろ配慮が必要。
リリース準備はどう行う？並行機能開発はどう行う？複雑な並行開発に耐える方法をいちいち考えるのは大変。

2010年、Vincent Driessen氏がブログで「こんな感じで運用したらうまくいったよ」というのを報告。
nvie.com

できがいいので広まった。

メリットは？

規約ができる。考える、決める手間が省ける。

どういう開発を想定？

バージョンを切って、ある程度長い（数週間とか）スパンでリリースする開発。
常に最新がデプロイされているような開発は”GitHub Flow”のほうが向いている。

競合は？

GitHub Flow。プルリクエストを投げるやつ。
常にmasterがデプロイされるような、リリーススパンの短い開発に向いている。

git-flowのデメリットは？

学習が大変。Git自体のコマンドを理解していなければならない。
→　専用ライブラリの導入で楽になる！git flowライブラリ

git-flowの発想は？

master,developがメインのブランチ。feature,release,hotfixがサポート。

メイン
1. master…常に、リリース準備完了の状態を持つ。
2. development…次のリリースのための開発ブランチ。リリースのための開発が完了したら、masterに反映する。そしてタグを切る。
サポート
1. feature…機能開発のためのブランチ。developから分岐させ、完了したらdevolopにマージする。
2. release…開発完了後、本番化直前の最後の微調整を行うブランチ。バグの修正など。リリースブランチが切られたら、次のバージョンのfeature開発に入れる。masterとdevelopにマージする。
3. hotfix…本番化後のバグの緊急修正用ブランチ。masterから分岐させる。修正後、masterとdevelopにマージする。ホットフィックスはマスター、リリースはデベロプをベースにしている。ほかは一緒。

git-flowプラグインの使い方は？

基本的に以下のとおり。操作対象と操作内容の組み合わせ。

git flow [feature|release|hotfix] [start|finish|publish|pull] [name]

疑問

・リモートリポジトリはフォークでなく、共通のがひとつあるだけでいいのか？ →たぶんそう。・ローカルでマージしたdevelopブランチは、リモートにどう反映するのか？ →たぶん普通にプッシュする。

git push origin [ブランチ名]

でプッシュする。
そこは特に専用コマンドはない模様。
release,hotfixで追加したタグは、以下のコマンドでリモートにも追加するのを忘れないようにすること。

git push --tags

（Qiitaで検索すると、リモートへの反映はPull Requestを活用するやり方が紹介されている。元ネタと違うように見えるが派生版か？）

参考

git-flowの考えを発表した元祖の記事 nvie.com

プラグインのGithub リポジトリ(nvie版とavh版がある。以下はaptで導入できるavh版) github.com

プラグインの解説記事 jeffkreeftmeijer.com チートシート
 http://danielkummer.github.io/git-flow-cheatsheet/index.ja_JP.html
チーム開発の運用ワークショップ d.hatena.ne.jp