頼む!ブランチを分けて開発して
2月に対応した内容を4月にリリースすることになったのだが、どうやら同じシステムの5月リリース機能、6月リリース機能をtrunkに対してコミットしながらプロジェクトが進行しているらしい。
僕に「5月、6月リリース分は除外したリソースでjarパッケージつくってね♪」と指示が来たので、「ブランチ分かれていますよね?」と聞くと、「今回は(今回だけじゃないんじゃね??)一緒だよ♪」
これは・・・予想外に面倒だ。
subversionもっと勉強しておくんだった・・・地道にいちリビジョンごと見ていくしかないのか。
ディスカッション
コメント一覧
5,6月分の作業がコミットされる直前のリビジョンをコピーしてまずブランチを作って、そこに4月分の作業をマージして行ってリリースブランチとすれば良いんじゃないですかねー。
その後はリリースのたびにそこに直接マージするか、あるいはコピーを作ってリリースごとのブランチを立てて同様にマージをして行けば…
最低限versionsなりにリリースしたソースを置いておけば、後々(緊急障害対応とか、バグ報告の調査とか)それなりに役に立つんじゃないかと思います。
>uokumuraさん
はじめまして。
ブログもtwitterもみてますよ。
やっぱりコピーして、ブランチ作成ですかねー
現在のプロジェクトのリーダーが、提案すると切れる方なので(笑:自分が一番??)
今後に役立てたいですね。
タグをつけておくんじゃやっぱりまぜこぜになって解決にならないですしね。
versions…知らないですね…メモメモ。
うちの場合、最新バージョンは常にtrunkにコミットしていって、2月版とか3月版とかみたいにリリースの度にtagsにコピーしてタグ付けしていました。
で、リリース版でバグが発生して改修が必要になったら、タグをコピーしてブランチを作り、ブランチで修正した内容をtrunkにもマージするっていう流れで作業を進めていました。
/trunk ←常に最新
/tags
/200903_release ←リリースしたらコピー
/200904_release ←リリースしたらコピー
/200905_release ←リリースしたらコピー
/branches
/200903_release_branch ←200903_releaseでリリースしたバグを修正
>fumokmmさん
なるほど。
開発が重複していない場合には
branchesよりもtagsを積極的に使ったほうがいいんですね。
タグやブランチの名前の例まで挙げてくれてわかりやすい。
参考になりました。