SVNの使用法の詳細な説明(ウェアハウスの作成、データの送信、ブランチの作成とマージなど)

GITとSVNは、バージョン管理ツールで一般的に使用されています。今日は、SVNでブランチを作成してブランチをマージする方法を共有します。まず、コンピューターにSVNクライアントをインストールする必要があります(この手順は省略されています)。

コンテンツ

SVNリポジトリを作成する

トランク/ブランチ/タグモード

プルファイル

書類を提出する

更新ファイル

ログを表示する

ローカルでログを表示する

ウェアハウスビューログ

ファイルを復元する

ファイルを削除する

ブランチを作成する

リポジトリのブランチを作成します

ローカルにブランチを作成する

ブランチをマージ


SVNリポジトリを作成する

SVNはバージョン管理ツールです。SVNを介してファイルを管理するには、最初にSVNリポジトリを作成する必要があります。このSVNリポジトリは私たちのデータベースに似ており、私たちが管理するすべてのファイルを保持します。

このリポジトリをコンピュータ上でローカルに作成する場合はローカルリポジトリと呼ばれ、リモートコンピュータまたはネットワーク上で作成する場合はリモートリポジトリと呼ばれます。ローカルウェアハウスは、リモートウェアハウスと同じ方法でアクセスされますが、ファイルをプルするときに、ローカルウェアハウスがローカルSVNアドレスを入力し、リモートウェアハウスがリモートSVNアドレスを入力する点が異なります。

したがって、便宜上、デモンストレーションにはローカルウェアハウス方式を使用します。

ローカルコンピューターの任意のディレクトリ(D:\ items)にいるので、右クリックして以下に示すように選択し、SVNリポジトリの作成を開始します。

作成後、フォルダにすでにウェアハウス関連の初期化リソースがあることがわかります。このとき、SVNは引き続きプロンプトを表示します[翻訳:ウェアハウスが作成されました。デフォルトの(トランク/ブランチ/タグ)フォルダー構造を作成しますか?]、[このフォルダ構造を作成]を選択します。

この時点で、トランク/ブランチ/タグ構造モードのSVNウェアハウスが作成され、最後に[OK]をクリックします。

トランク/ブランチ/タグモード

上記で、トランク/ブランチ/タグのフォルダ構造パターンについて説明しましたが、これはどういう意味ですか?

まず、このモードがないとコードコントロールがどのようになるかを確認できますか?

上の図に示すように、trunk / branchs / tagsフォルダー構造モードが使用されていない場合、ファイルバージョン管理全体がメインプロセスのブランチであるため、Zhang San、Li Si、およびWangWuが開発中の場合は引き続きコードをウェアハウスに送信するため、コードの各バージョンがアーカイブされます。

たとえば、フェーズ1、2、および3のコードの量をカウントする場合、開発全体が1行で行われるため、判別が困難です。

別の例として、3つのバージョン1、2、および3のいずれかにバグがあります。第1フェーズでバグを修正する場合は、コードを10〜09日の第1フェーズコードで変更する必要があります。混同することはできません。コードビハインド。

もちろん、ここに2つの小さなケースがあります。次に、トランク/ブランチ/タグモードの意味を見てみましょう。

彼の意味するところは、SVNウェアハウスのルートパスに、トランク、ブランチ、タグの3つのファイルディレクトリが作成されるということです。

SVNファイル管理を標準化するために、メインプロセスコードをトランクの下に置き、各ブランチコードをブランチの下に置き、各バージョンのコードをタグの下に置くことをお勧めします。

たとえば、アプリプロジェクトを開発する場合、次のようになります。

トランクは、公式環境の最新の安定バージョンのコードをリリースし、そのコード変更はブランチによってマージされ、コードの開発に直接関与しません。

ブランチの下には、機能の反復、人事の変更、バージョンのバグ修正などの要件に従ってトランクまたはタグから作成されたブランチコードがあります。トランクコードトランクを機能的に繰り返す必要がある場合は、開発のためにブランチをトランクから分離し、開発後にトランクプロセスにマージして、バージョンアーカイブを実行できます。バージョンのバグを修正する必要がある場合は、タグの下で対応するバージョンを見つけ、ブランチを分離して修正し、修正後に元のバージョンにマージできます。つまり、コード開発はブランチブランチに基づいて更新されます。

app1.0バージョン、app1.1バージョン、app1.2バージョンなどのタグの下にある各バージョンのアーカイブコードは、通常、読み取り専用であり、書き込まれません。

プルファイル

SVNがリポジトリ内のファイルをプルする方法を示しましょう。

読み取りファイルの保存場所として別の場所(E:\ my)を使用します。

まず、SVNファイルをプルするためにウェアハウスのアドレスを知る必要があります。次の図に示すように、今すぐSVNに戻り、Repo-browerを選択します。

次に、前述の3つのスキーマフォルダーを確認し、トランクのメインプロセスを選択して、必要なSVNウェアハウスアドレスであるURLをコピーします。

 次に、ローカルの場所に戻り、右クリックして[SVNチェックアウト...]を選択します。

このとき、今アドレスを入力して、[OK]を選択します。

このとき、svnの隠しフォルダーが表示されます。この.svnフォルダーは、SVNの関連するバージョン管理レコードです(削除しないでください。削除しないと、ローカルコードが管理できなくなり、SVNが隠し基本フォルダーを作成します。実際、私はあなたにそれを見せたくありません、あなたがそれを手で削除しないように、ここであなたにそれを見せますが、学習と理解を深めるのに便利です)。

見えない場合は、以下の設定で確認できます。

書類を提出する

上記のウェアハウスファイルをプルした後、SVNベースの構成フォルダー以外は何も表示されなかったようです。作成したばかりのウェアハウスには実際にはファイルがないため、これは正常です。ファイルを送信することもできます。試してみてください。

 Tengwangge poem.txtファイルを作成し、コンテンツを書き込んでから保存します。

 

次に、右クリックして[コミット]を選択して送信します(送信方法を覚えておいてください。後で送信を繰り返すことはありません)。

まず、[バージョン管理されていないファイルを表示する]の前にあるチェックボックスをオンにします。チェックしないと、新しく送信されたファイルを表示できません。次に、送信する必要のあるファイルの前にあるチェックボックスをオンにして、このファイルを送信したいのですが、最後に、このファイルにこの送信の内容を書き込んで、後でログを表示するときに、今回送信した内容が何であるかを理解し、最後に[OK]を選択します。

次のページを見ると、ファイルが正常に送信されたことを意味します。同時に、元のファイルに緑色のチェックマークが付いていることもわかります。これは、ファイルがSVNによって管理されていることを意味します。

次に、ウェアハウスインターフェイスに戻ります。ファイルサイズ、送信時間、送信者、その他の情報など、送信したファイルを確認できます。

更新ファイル

ローカルエリアに戻り、コンテンツを今すぐ更新し、詩の名前と作成者を追加して、[保存]をクリックします。

保存後、ファイルアイコンの緑色のチェックマークが赤い感嘆符に変わったことがわかります。これは、ファイルが変更されたことを意味します。

緑のチェックマーク:ローカルファイルとウェアハウスファイルの内容がまったく同じであることを示します。

赤い感嘆符:ローカルファイルが変更されたことを示します。

引き続き送信し、送信時に更新した情報を入力して、[OK]をクリックします。

再びウェアハウスに入り、ファイルをダブルクリックして開きます。更新されたコンテンツがウェアハウスに同期されていることがわかります。

ログを表示する

ローカルであろうとウェアハウスであろうと、ファイルのすべてのコミットレコードを確認できます。

ローカルでログを表示する

ローカルの対応するファイルを選択し、下図のように右クリックして、[ログを表示]を選択します。

次に、ファイルのすべての履歴コミットレコードを確認できます。

コミットを選択し、右クリックして[以前のリビジョンと比較]を選択すると、このコミットの内容が表示されます。

 下の図に示すように、今回提出されたバージョン(右側)と前回のバージョン(左側)の違いがわかります。

ウェアハウスビューログ

同様に、ウェアハウス内のファイルを選択し、右クリックしてファイルの履歴送信レコードを表示できます。

ファイルを復元する

ここで、子供がファイルの内容をランダムにスクランブルし(下の図に示すように)、それを保存するとします。このとき、彼を倒したいのですが、今一番欲しいのはファイルを復元することです。

このとき、以下のようにファイルを選択し、[元に戻す]を選択して復元します。

 次に、復元したいファイルを選択し、[OK]をクリックします。

この時点で、ファイルが正常に復元されたことを確認できます(緑色のチェックマークが表示されます。これは、ウェアハウス内の最新バージョンと整合性があることを意味します)。

ファイルを削除する

次に、ウェアハウス内のファイルを削除する方法を示しましょう。

まず、先に進み、2つの新しいファイル(1.txtと2.txt)を追加して、リポジトリにコミットします。

次に、2つのローカルファイルを直接削除します。

 次に、空白をクリックして送信します。

 提出記録を記入し、[OK]を選択してください。

 成功したポップアッププロンプトを削除します。

ブランチを作成する

いわゆるブランチの作成とは、元のデータをバックアップしてから新しいブランチを形成することを指します。元のデータが影響を受けないように、ブランチ上のファイルを変更できます。通常のブランチはブランチであり、コードのバージョンはタグブランチと呼ばれます。2つの作成方法は同じですが、名前が異なります。以下は、タグブランチの作成例です。

リポジトリのブランチを作成します

 倉庫に入り、トランクトランクを選択し、右クリックして[コピー先...]を選択します。

このとき、URLを入力するように求められますが、通常はコードのバージョンをタグの下に保存し、バージョン番号を識別パスとして使用するため、ここではURLを.... /tags/に変更します。 1.0(以前のルートディレクトリはMoveではなく、トランクをtags / 1.0に変更します)。これは、バージョン1.0のコードファイルが以下に保存されていることを意味します。

 対応する備考欄にご記入の上、【OK】をクリックしてください。

 ルートディレクトリを選択し、[更新]を右クリックして更新します(コピーには時間がかかるため、ファイルが多い場合はしばらく待ってから更新してください)。

更新後、メインコードのフォルダーとファイルがバージョン1.0に正常にバックアップされていることがわかります。

ローカルにブランチを作成する

ローカルルートディレクトリにいるので、空白部分を右クリックして、以下のように[ブランチ/タグ]を選択します。

 1.0バージョンが作成されたばかりなので、ここでは、デモとして1.1バージョンを保存します。まず、ブランチのパスも入力し、リポジトリでHEADリビジョンを選択して最新バージョンがコピーされたことを示し、最後に[OK]をクリックする必要があります。

次のページが表示されている場合は、正常に作成されていることを意味します。

ウェアハウスに再び入ると、バージョン1.1のタグブランチも作成されていることがわかります。

ブランチをマージ

開発するバージョン2.0の新しい要件があると仮定すると、新しい開発の分岐点として新しいブランチを作成できます。したがって、次の図に示すように、手順9に従って、トランクからブランチに基づいて2.0-devブランチを作成できます。

次に、2.0-devのURLをコピーし、そのデータとファイルを別の新しいローカルスペース(E:\ my2)にカットします。

 

 コピーしたURLを対応する入力ボックスに入力し、[OK]をクリックします。

この時点で、SVNリポジトリの2.0-devブランチのファイルはローカルにダウンロードされています。

 次の図に示すように、この新しい開発に123.txtを追加し、Tengwanggepoem.txtを変更したとします。

 次に、コメントを入力し、ファイルを確認し、[OK]を確認して、すべてのファイルをSVNに送信します。

 ウェアハウスを開くと、2.0-devに最新のデータファイルが既にあることがわかります。

 この時点では、トランクはまだ前のファイルです。

したがって、開発が完了したら、ブランチのコードをトランクにマージして、トランクのコードが次のリリースで新しい機能を持つようにする必要があります。

ローカルトランクのルートディレクトリに入り、空白を右クリックして[マージ...]を選択し、マージを開始します。

注:コミットやマージなどを行うときは、最初に[SVNUpdate]で更新することを忘れないでください。

最初のマージを選択し(最初のブランチはマージされる同じソースの2つのブランチを参照し、2番目のブランチは異なるツリーをマージできます)、[次へ]をクリックして次のステップに入ります。

次に、ブランチのパスを入力し(間違って入力するのが怖い場合は、右側の3つのポイントから選択できます)、次に示す順序で選択します。

次に、次のページに移動します。マージする前に、[マージのテスト]をクリックして、正常にマージできるかどうかをテストできます。テストが失敗した場合は、最初に戻ってトランクを更新または復元できます。更新または復元後にテストマージが失敗した場合は、競合を解決する必要があります。

次のようなインターフェイスが表示され、赤い競合プロンプトが表示されない場合は、マージを実行できることを意味します。

 この時点で、[マージ]をクリックして実際にマージできます。

 同様に、このインターフェースの外観は、合併が成功したことを意味します。

マージ後、ブランチ2.0-devの123.txtファイルがローカルトランクに到着し、別のファイルも変更が発生したことを示していることがわかります。

現在、マージはローカルでのみ実行されます。リポジトリをマージしたままにする場合は、マージされたローカルトランクの送信をリポジトリにプッシュするだけで済みます。

 OK、現時点では、マージ操作後のデータもウェアハウスに保持されています。

 このとき、ウェアハウスに移動して、マージされたファイルを確認します。

おすすめ

転載: blog.csdn.net/sunnyzyq/article/details/122533854