git-flowで開発をしていて、master, develop, 各フィーチャーブランチというような状況で、
大きな変更、たとえばRails3.2からRails4系に上げるなどをした場合に
通常のdevelopにマージするより、featureブランチをdevelopにしたほうがよい。

理由はこんな感じ

developで別のエラー修正をしてcommitが先に進んでいるなんてあると、マージ時にデグレード起こす危険性がある
develop進んだ部分のマージはdevelopからフィーチャーブランチに対して、ローカルで丁寧に1ファイルずつ確認するするのが安全

今回はrails3.2のdevelopのプロジェクトを、feature/rails4.2というRails4.2版のFeatureブランチをdevelopにするのを例に上げる(例に上げるというか、最近それやっただけだけど)

前提条件

動作環境

クライアント: Mac OS X10.10
リモートリポジトリのホスティング先: Github
リポジトリのスタイルはgit-flowで開発
※ gitでリモート管理していればだいたいどの環境でも大丈夫だろう

求めるbranchの形

旧	新
develop	rails3.2
feature/rails4.2	develop
master(旧developと同じcommit番号)	master(新developと同じcommit番号)

作業一覧

ローカルgitブランチのリネーム
2. developをrails3.2にする
3. rails4.2のフィーチャーブランチをdevelopへリネームする
リモートgitブランチのリネーム
3. 新rails3.2(旧developブランチ)ブランチをリモートブランチに置く
4. 新develop(旧rails4.2ブランチ)ブランチをリモートブランチに置く
リモートmasterブランチをdevelopと同じにする

ローカルgitブランチのリネーム

developをrails3.2にする

# developをrails3.2へリネームする
> git branch -m develop rails3.2 

# リネームされていることを確認
> git branch | grep rails3.2
rails3.2

rails4.2のフィーチャーブランチをdevelopへリネームする

> git branch -m feature/rails4.2 develop

# リネームされていることを確認
> git branch | grep develop
develop

##リモートgitブランチのリネーム

ローカルのgitブランチ内ではリネームは完了しているが
リモートgitブランチはまだ以下の様な状態である

remote側には、rails3.2ブランチがまだなく、
developには古いRails3.2版のブランチがいることになる

新rails3.2(旧developブランチ)ブランチをリモートブランチに置く

> git push origin rails3.2 

> git branch -r | grep rails3.2

新develop(旧rails4.2ブランチ)ブランチをリモートブランチに置く

# -f オプションを付けて強制的にpushしないと、別ブランチなので怒られる
git push origin develop -f

> git branch -r | grep develop

# リネーム前のfeature/rails4.2リモートブランチを削除する
git push --delete origin feature/rails4.2

リモートmasterブランチをdevelopと同じにする

git masterのブランチも

ローカルのmaterブランチを削除して、developからmasterブランチを作る

> git branch -d master
# developブランチをに移動して 
> git checkout develop
# master ブランチを再度構築する
> git branch master

masterブランチを、リモートのmasterブランチにpushする

# masterブランチへ移動
> git checkout master
# ローカルのmaterブランチを、リモート監視させつつpushするが、既存のmasterブランチがあるため-f　オプションを付ける
> git push -u origin master -f

参考文献

ref:リモート操作
ref:[Git] ローカルとリモートのブランチ名を変更する