svnのマージの使い方。

現在、Atmelのマイコンのプログラムファイルの管理をtortoise svnで行っています。

現在自分の使い方としては、trunkフォルダにリリースVersionのプロジェクトフォルダが入っていて、そのプロジェクトフォルダ内のファイルの検証や修正を行うためには必ずbranchフォルダにbranch機能でフォルダコピーしてからそのファイルの修正などを行っています。修正が完了した場合はtrunkフォルダのリリース版のファイルにマージして、branch側のフォルダは削除しています。


だいたいこのサイクルを繰り返しているのですが、共同作業者さんがbranchでの修正が先に終わってtrunkにマージしてリリース版が更新される場合があるのですが、現在の自分のbranch
のファイルはリリース版のものからすると古くなってしまうので、現在の最新のtrunkのファイルを自分のbranchにマージする方法というのはありますでしょうか？


以前trunkのファイルを自分のbranchにマージしたら競合が多発して一部ファイルの更新内容がスムーズにいかなくなってしまったことがあり、現在避けているのですが、良い方法をご存知の方いらっしゃいましたらどうぞご教示頂きますよう、お願い致します。

No.1 ベストアンサー 回答者： Wr5 回答日時： 2015/01/06 12:22

>現在の自分のbranch

>のファイルはリリース版のものからすると古くなってしまうので、現在の最新のtrunkのファイルを自分のbranchにマージする方法というのはありますでしょうか？

運用方針次第ですからなんとも……。


ちなみに私だったら次のような運用でしょうかね。

・機能ブランチはそのまま開発継続する。
・他の機能ブランチがtrunkにマージされていた場合に『自分の機能ブランチをマージ』する場合は、
　切り替えでtrunkに切り替えた後で自分の機能ブランチをマージする。
　※衝突が発生したらそこで対処してからtrunkにコミットする。
・機能ブランチで開発中にtrunkにコミットされた不具合修正が『影響が小さい』場合は手動で取り込む。
　※trunkとマージする際に衝突する可能性があるのでその時に対処する。
・機能ブランチで開発中にtrunkにコミットされた不具合修正の『影響が大きい』場合はtrunkから再度機能ブランチを作って開発中だった機能ブランチをマージする。
　※開発中だった機能ブランチはそのままクローズ(触らない)する。
　※もちろん、新たに機能ブランチを作成する前に開発中のものはコミットしておく。

基本は「trunkにマージする」であって「trunkを機能ブランチにマージする」ではありません。
# ついでに、開発終了した機能ブランチの削除もしません。
# 機能ブランチ削除したところでリポジトリ側の容量は変わりませんし、機能ブランチ作成中の履歴(コミットログなど)も参照しずらくなります。
# Rev指定で覗けるので参照できなくなるわけではないが……。


>以前trunkのファイルを自分のbranchにマージしたら

機能ブランチをtrunkにマージする時にハマりそうですねぇ…。


機能ブランチと書いていますが…バグ修正用にtrunkから切り出したブランチも同様です。

一度trunkから機能ブランチ作成してtrunkにマージした後、その機能ブランチで盛り込んでしまった不具合があった場合は…新たに不具合修正用のブランチを切るか、trunkでそのまま修正するか…のどちらかになります。
# マージ終わった後の機能ブランチは触らない。再マージが面倒になるから。
# マージ時にRev範囲を指定すれば可能…ではあるが、その間にtrunkに入った変更部分で余計な衝突なりが発生するかも知れないので。(基本的には大丈夫なハズ…ですけどね。機能ブランチ開発中に別の機能ブランチがtrunkにマージされた。というのと状況的に一緒ですし。運用方針次第です。)

この回答へのお礼

回答頂きありがとうございます。

trunkが更新されてしまった場合には、そのtrunkの機能ブランチを作って、自分の機能ブランチをマージするというのはとてもいいやり方のように感じました。失敗してもtrunkに直接影響が出るわけではないですしいいですね。

大変助かります。

お礼日時：2015/01/06 13:42