閉じる

Subversionで branch作成、merge等々

Subversionとなっているけど、実際には Windows上の TortoiseSVNでの作業メモ。*1

試験的な機能を入れてみるために trunkのコピーを作って作業、採用方向なら trunkに統合、不採用なら破棄。
ただし、trunk自体も平行して作業される可能性有りというシチュエーション。

  1. branchの作成
    まずはチェックアウトされている trunkのコンテキストメニューから「ブランチ/タグの作成」で branchを作成。(branches/test_func)*2
  2. 作業コピーを branchしたバージョンへ更新
    eclipseのワークスペースを作り直すのが面倒なので trunk作業コピーのコンテキストメニューから「切り替え」でパスを trunkから先ほど作成したパスへ切り替える。
  3. 試験的な機能を実装。

試験的な機能を実装中、平行して trunkにて修正が発生し、その内容は branchに mergeする必要があるシチュエーション。

  1. branch作業コピーのコンテキストメニューから「マージ」を選択し、マージのタイプは「リビジョンの範囲をマージ」
  2. マージ元は trunkの URL、マージするリビジョンの範囲は trunkにて発生し、branchに mergeすべきリビジョンを指定。
  3. マージ実行。*3
  4. 以上で branchの作業コピーに trunkでの変更が mergeされたので、必要なら commitを行うと。

trunkの特定リビジョンから branchし、作業、trunkにマージというシチュエーション。

  1. trunkの作業コピーのコンテキストメニューから「ログを表示」を選択し、branchしたいリビジョンを特定。*4
  2. branchしたいリビジョンのコンテキストメニューから「このリビジョンからブランチ/タグを作成」を選択し、branch先を入力し、branchを実行。
  3. branchをチェックアウトして、作業&コミット。
  4. trunkの作業コピーのコンテキストメニューからマージ-リビジョンの範囲をマージを選択し、URLに branchを指定し、テスト&マージ実行。

branchにおける試験的な機能の実装が終わり、実装を採用することにして trunkへ統合。

  1. trunkのコンテキストメニューにてマージ-ブランチを再統合するを選択。*5
  2. 元の URLに branchを指定し、テスト&マージ実行。
  3. trunkに統合して用済みになった branchはリポジトリブラウザから削除してスッキリ。*6

いろいろなケースがあるけど、「branchはサーバ上で、mergeは作業コピーに対して行う」が基本かね。

branch/merge周りを使っていると「細かい粒度でコミットしてゆくのが大事」という事がわかる。
逆を言えば「まとめてコミットしていると cvsのメリットを生かせない」と言うことか。

もう一つ言えるのは「trunkとの関係を考えること」かね。
trunkに属するべきコミットと branchに属するコミットをごっちゃにしない。
これをごっちゃにしてしまうと trunkのバグフィックスとして独立してマージすることが出来なくなる。
粒度は細かければ細かいほどよいというわけではなく、修正内容を考える必要があると。


*1 開発自体コマンドラインで行うなら svnコマンドバシバシでもいいんだけどね。

*2 この時、「作業コピーを新しいブランチ/タグへ切り替える」をチェックしておくと新たにチェックアウトしたり作業コピーを branchに切り替える必要が無くなる。

*3 実行の前にテストを行ってみるのが無難かと。

*4 予めリビジョンがわかっているのなら直接「ブランチ/タグを作成」を選択してコピー元としてリポジトリ内の特定リビジョンを入力してもかまわない。

*5 リビジョンの範囲をマージとの違いは branchしてからの変更を一括してマージするか選択してマージするかの違いなのかしら?

*6 これは単に非表示なるだけで必要になれば復活できる。

コメントを残す

メールアドレスが公開されることはありません。必須項目には印がついています *

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)