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] ローカルとリモートのブランチ名を変更する