Windows環境でSubversionによるバージョン管理を行いたい場合に便利なのが、GUIでリポジトリにアクセスできるTortoiseSVNだ。本記事では、TortoiseSVNの導入から基本的な使用方法までを解説する。 図1 TortoiseSVNTortoiseSVNをインストールする TortoiseSVN(本家)は、Windows 2000/XP/Vistaで動作す … Updated: 2017-12-05 / Reading time: 11 minutes, あなたの現場では、バージョン管理システムは何を使っていますか?Git?Subversion?VSS?まさかCVS?, GitHubスタイルの運用方針があるのであれば、大変結構です。しかし、SIerの現場ではSubversion(以降、SVN)による運用がまだまだ多いように思います。更に、コミット・ルールはあるけどブランチ運用はされておらず、みんなでtrunkに格納しているとか。, ここでは、SVNを使った場合の運用方針を定義したいと思います。これをベースとして、現場ごとにカスタマイズして運用方針を定義すると良いと思います。, git-flowを参考にブランチ運用方針を定義します。SVN標準フォルダ構成(trunk、branches、tagsフォルダ)の上に定義するため、git-flowと次の相違点があります。, SVN標準フォルダ構成に比べて増えています。次に、フォルダごとの役割を説明します。, SVNリポジトリを作成直後は、基本フォルダ構成が作成されていると思います。作成されていなければ、手動で作成してください。さらに、trunkから分岐してbranches/developを作成します。branches/releasesは直接作成します。結果、次のようなフォルダ構成になります。, フォルダ作成後、SVNリポジトリにアクセスするユーザーを作成します。Apache HTTP Serverであればhtpasswd管理、Visual SVNであればGUIからユーザーを作成するなど、プロダクトごとに対応してください。, ユーザー作成後、フォルダに読み書きできるユーザーを限定するため、権限を設定します。これは、trunkやbranches/developに不用意にコミットしてしまわないようにする処置です。なので、権限設定がメンドウであれば、運用で気を付ければよいと思います。, 最後に、一番重要ですが バージョン管理運用方針を策定し、文書化 します。現場ごとの書式で文書化すれば良いと思いますが、おおむね次の構成になると考えます。, 作業ごとにブランチを作成します。基本的にbranches/developをbranches/xxxにコピーすることで、ブランチを作成します。xxxの命名規則は現場ごとに決めれば良いですが、作業はWBSやチケットやバグ票で定義されるはずなので、WBS番号やチケットIDやバグ番号でブランチを作成すると良いでしょう。こうすることで、そのブランチが何のためのブランチなのかが分かりやすくなります。, 例えば、「WBS番号 2-3-5-8 発注画面」という作業を行う場合、次のようにブランチを作成します。, 先ほど作成したブランチで作業を行います。このブランチは作業専用のブランチであり他作業者に影響はないので、作業中のコードをコミットしても良いですし、なんなら一時的にビルドが壊れてしまっても良いです。作業が少しでも進捗したら、気軽にコミットしましょう。, 開発者が作業を終えたらbranches/developにマージしますが、その前にもちろんレビューを行います。プロジェクトごとに品質基準があるでしょうし、チームごとにもあるかもしれません。それらの品質確認をパスしたコードのみ、branches/developにマージして良いです。次のような基準が良くあるのではないでしょうか。, 自動化できることは自動化してしまいましょう。CIサーバーで、静的チェックを実行、コード設計の問題報告、テストまでは実行してしまいたいです。, ソースコードの内容確認は、ブランチの最初から最新までの差分を表示することで行います。まずは、ブランチがどのリビジョンから派生したのかを確認します。--stop-on-copyオプションを指定してログを表示することで、派生したリビジョンから最新までのログが表示されます。, 派生したリビジョンが確認できたら、そのリビジョンから最新までの差分を表示します。例えばリビジョン35813が派生したリビジョンだとした場合、次のように実行します。, 「マージが失敗しないこと」は、--dry-runオプションを指定してマージすることで確認します。例えば、先ほどの2-3-5-8ブランチがマージに失敗しないことを確認するには、次のように実行します。, 実際にはマージを行わず、マージを行った場合にどうなるかがシミュレーションできます。ログにファイルパスとともに記号が表示されます。記号は次の意味を持ちます。, コンフリクトするとマージに失敗するので、解消する必要があります。解消するには、コンフリクトしているファイルを修正したり、branches/developから逆マージを行います。マージ時にpostpone(競合を後で解決)を選択してから修正してresolved(競合を解決)しても良いです。, 開発して、テストして、レビューしたら、いよいよbranches/developにマージします。マージ作業は、--dry-runオプションを指定せずにマージを実行します。, マージ後のブランチを削除するか放置するかは、どちらでも良いです。branchesの下が見づらいと思えば削除すれば良いし、メンドウであれば放置してもさほど問題はないはずです。ただ、後で作業ログを確認するかもということであれば、放置したほうが良いでしょう。, 開発が進み、いよいよテスト環境や本番環境にリリースする時が来ました。リリース作業にどの程度の時間がかかるかはプロダクトによって異なりますが、リリース作業中も開発作業は進むでしょう。そのため、リリース作業はbranches/releasesで行います。, まず、branches/developからbranches/releases/xxxにコピーします。xxxはバージョン番号を付けます。バージョン番号の付け方はプロジェクトごとに異なると思いますが、特になければ日付でもつければ良いと思います。, リリース作業が完了したら、branches/releases/xxxをtrunkにマージします。, 同時に、tags/xxxも作成します。tags/xxxはtrunkをコピーすることで作成します。, リリースを繰り返すと、きっと、「xxxバージョンのアプリに致命的バグがあるので緊急で対応してほしい!」という状況が来るでしょう。この時、通常の作業と同様にbranches/developから分岐すると、xxxバージョン以降のソースコードも入ってしまいます。なので、特定バージョンに関連する緊急バグ対応は手順が少し異なります。, 緊急バグ対応の場合、tags/xxxからbranches/xxxに分岐します。例えば、「バグ管理番号 1123 受注画面の確定ボタンをクリックするとクラッシュする」に対応する場合、次のようにブランチを作成します。, 通常の開発と同様に、開発、テスト、レビューを行い、問題がなければリリースを行います。緊急バグ対応のリリースの場合、branches/xxxからbranches/releases/xxxに分岐します。, リリース作業が完了したら、branches/releases/xxxをtrunkにマージして、trunkをtags/xxxにコピーします。, また、開発中のソースコードにも反映する必要がある場合(普通、反映する必要がありますが)、branches/developにもマージします。, branches/releases/xxxをマージするとリリース先環境用の設定が入ってしまい困る場合、branches/xxxをマージすると良いでしょう。, もしtrunkのみで運用しているのであれば、ブランチ運用方針を文書化して周知したのちに、運用手順を最初から実行すると良いでしょう。ぜひ、導入してください!, 一つ注意としては、SVNユーザーは(私の観測範囲では)ブランチの扱いに慣れていないことが多いです。ですので、ある程度の学習コストは必要となるでしょう。また、ここではSVNコマンドで説明しましたが、WindowsにはTortoiseSVNとWinMergeという最強コンボがありますので、それらを使うべきです。, 運用手順でも説明しましたが、作業ごとにブランチを作成します。安全な作業のためですので、多少のメンドウは受け入れましょう。この時、1作業の作業量が多くなりすぎないように注意してください。生存期間が長いブランチは、マージでコンフリクトする危険性が高まります。ここら辺は、マネージメント技術やアーキテクトの分野ですが。, VSSではもろにコピーするので容量をバカ食いしますが、SVNのコピーはSVN内部で「コピーした」と記録されるだけですので、容量は(ほとんど)消費しません。気にせずどんどんブランチを作成しましょう。, ただ、SVNリポジトリ全体をチェックアウトしている人はブランチやタグを全てチェックアウトしてしまうため、自PCの容量を消費してしまいます。必要なブランチのみをチェックアウトして、他ブランチを見たい場合はswitchで切り替えましょう。, 例えば、自分の作業ブランチはbranches/1123なのに間違えてbranches/1124をチェックアウトして作業してしまった!というケースですが、これはさすがにチェックアウトするときに気を付けてくださいとしか言えないです。気を付けてください。, はい、メンドウです。正直、GitHubやGitLabが使えたら、SVNコマンドで説明していることのほとんどがWebブラウザでポチポチして終わる話です。GitHubやGitLabを導入できるよう、がんばりましょう。, ある程度開発が進んでから、「xxxの場所にトレース・ログ出力処理を追加すること」のようなポリシーができた、「xxx共通部品を作成したので、yyyという処理は全体的に修正」のようなケースです。プロジェクトによって、「1人が全て対応する」「作業者それぞれが対応する」に分かれると思います。, 「1人が全て対応する」場合は、branches/xxxを1個作成して対応を行い、branches/developにマージします。この時、他作業者(他ブランチ)が作業しているファイルも対応範囲である場合、コンフリクトに注意してください。, 「作業者それぞれが対応する」場合は、作業ごとにbranches/xxxを作成して対応を行い、branches/developにマージします。この方法はコンフリクトの危険性が非常に低い代わりに、ブランチを複数作成しなければならないメンドウさがあります。, CIサーバーでデプロイを行っているのであれば、CIサーバーのログを確認することで特定できるでしょう。そうでなくても、何らかの手段でバージョンを特定することができるはずです。実行ファイルのファイル名、ファイルのプロパティ、APIが返すバージョン、など。特定さえできれば、バージョンに対応するタグをチェックアウトすることで、ソースコードを確認することができます。, リリース後に、画面文言のスペルミスを見つけてしまった!修正したいけどブランチ運用は面倒だからtrunkを直接修正したい!といったケースです。, 慣れるまでは少々メンドウかもしれませんが、引き換えに気軽にコミットできる環境ができます。このメリットは想像するよりはるかに大きいでしょう。ぜひ、あなたの現場にも導入してください。, Tags:

.

L2tp Ipsec Ssl Vpn 違い 9, 長崎 モントレ 事件 8, 放置 自転車 撤去 警察 6, ユニバーサル スタジオ フロリダ キャラクター 4, 糸 試写会 北海道 5, あすみ 名前 イメージ 17, 2020年 受験 日能研 ブログ 56, スタバ ネイバーフッド 閉店 30, 北見 アンサー カフェ メニュー 21, Youtube フリー音源 ダウンロード方法 6, 黙れ 英語 汚い 4, 作りながら覚える 3日で作曲入門 Rar 14, Pubg 起動オプション 2019 5, 吉本新喜劇 アキ 座長 5, 犬 生まれる 順番 5, プリキュア 悪役 名言 51, Complex 日本一心 再販 8, 仁王 焼き直し テーブル 21, 西武 ショート なんj 12, 吉田ちか コンサル どこ 5, 日 向坂 46 ラグーナ セトリ 4, バイオハザード コードベロニカ 攻略 7, Outlook 会議室 予約 空き 状況 16, ホスファチジル セリン 眠気 副作用 37, Spoon 配信 マイク スマホ 33, 東海村 美容室 コネクト 22, 曲線の長さ 証明 大学 6, 世界一 くだらない 話 11, 本音で はしご酒 ヒカキン 見逃し 16, ライアンギグス 背番号 歴代 41, 近くの Toto Big 売り場 10, 輸入 関税 計算 例 4, ハイパワー スプリング エア ライフル 19, Ufo 嫁島 イベント 4, 松戸市 地図 町名 7, コウノドリ 今橋先生 娘 9,