masterブランチへのマージについて

2013年2月あたりから、GitHubでの運用を進めてきたが、
NC2.4.1.0リリースの区切りがついたため、一度GitHubの運用を考えてみたいです。

2013年5月現在、masterブランチとdevelopブランチが存在する。
これは、

• masterブランチはリリース毎にマージする。
• developブランチは開発用のリポジトリとする。
• コラボレイターは、developブランチをクローンして開発し、修正したものをプッシュする。
• コラボレイターでない人は、Issuesでリクエストをあげる。

くらいで始めたのが、そのままになっている感じです。

途中から リポジトリ管理について で意見があがって、

• コラボレイターでない人は、自分で修正し、pull request をあげる。

という流れもありました。 pull requestについては、実際に試してみて頂いたところ、うまくいっているようですので、
今後もpull requestで進めていきたいと思います。

で、もう1つ考えたいのは、ブランチについてです。
http://git-scm.com/book/ja
などをちょこちょこ見てみると、なんかやり方が違うような気がします。
まずは、案を少し考えてみます。

参考（分かりやすかった）
http://kotas.hatenablog.jp/entry/2012/11/22/000046

Case１：リリース毎にdevelopブランチをmasterブランチにマージ（Fast-Forward）する
　　developブランチを削除すると直接masterにコミットするのと変わらない。
　　　　→じゃー、developブランチいらないのでは？？
　　　　→そもそも、developブランチを削除しちゃいけない？？

Case２：リリース毎にdevelopブランチをmasterブランチにマージ（Non Fast-Forward）する
　　いい感じがする。
　　　　→そもそも、developブランチを削除しちゃいけないとすると、Fast-Forwardマージと変わらない？？

Case３：リリース毎にdevelopブランチをmasterブランチにリベースする
　　コミット情報が変わってしまう。
　　　　→うーん。。なんかダメっぽい。

developブランチをリリース毎に作り直すイメージで考えていたのですが、
これが、間違っていた気がします。

• developブランチは現状のまま、開発用ブランチとして継続する。
• masterブランチは、リリース毎にdevelopブランチをマージする。
• masterブランチにdevelopブランチをマージした後、リリースバージョンのタグを付ける。

というやり方でいきたいと思います。

そうすると、

• 最新版が欲しい場合：developブランチのソースを取得
• 最新リリース版が欲しい場合：masterブランチのソースを取得
• 過去のリリース版が欲しい場合：バージョン毎にあるタグのソースを取得

ということになります。