Plastic SCM - GitSync ガイド

すでにご存じのとおり、Plastic SCM は完全な機能を備えた DVCS（分散型バージョン管理ソフトウェア）です。さらに、Plastic SCM は Git ネットワークプロトコルで対話することもできます。

Plastic SCM は任意のリモート Git サーバーに直接、変更をプッシュ/プルできます。これは、Plastic が変更セットのプッシュとプルの両方に対して https:// プロトコルと git:// プロトコルをサポートしているからです。

この機能により、Plastic SCM が即座に、Git との完全な互換性を備えた DVCS へと変わります。その利点は、Plastic または Git を自分のワークステーションで使用して、引き続き Git プロジェクト（GitHub、CodePlex、その他）に参加できるという点です。

まずはこれを理解してください。GitSync は、GitHub に接続されたネイティブ Windows DVCS です。つまり、これを使用することで、Plastic SCM は本格的な Git 用 Windows クライアントになります。

たとえば、あなたが GitHub（あるいは Bitbucket や CodePlex など）を使用している開発者だとした場合、クラウドベースのリポジトリによるコード開発や、Windows での開発など、気に入っている点もあるでしょうが、CLI が必須であったり、便利な GUI ツールがなかったりと、不満な点もあるでしょう。

そしてあなたは、Cloud リポジトリや、DVCS の利便性、Windows 用の優れたツールなど、すべての希望を叶えたいと願うことでしょう。

それを実現するのが、GitSync なのです。

GitSync の機能は次のとおりです。

• 直接プッシュ/プル - すべてのコミット、コメント、ブランチ、マージの追跡、タグを含みます。
• ファイルの追加/削除または移動 - 両側とも制限は一切ありません。
• 完全なマージの追跡 - Git 側でマージ可能で、Plastic がそのマージの追跡を認識します。Plastic 側でのマージも同様に Git 側で追跡されます。これが Plastic SCM と Git が完全な DVCS であるメリットです！
• 競合管理 - 同じブランチに対して Git 側と Plastic 側で同時に変更を加えることができます。Plastic がデータ交換を処理し、変更をプルして、ユーザーにマージを実行するようリクエストを出し、解決された競合をプッシュします（完全な Git セットアップを使用していた場合と同じです）。

1 枚の画像は 1,000 語に匹敵するため、全プッシュ/プルプロセスを段階を追って説明します。

Git リポジトリがあり、それを Plastic にプルします。その結果、Git 内のブランチとコミットを含む正確なクローンが Plastic に変換されます。この処理の最も優れた点は、ブランチエクスプローラーへの表示が可能になることです。

次の画像は、新規コミットが Git 側で作成されるとどうなるか、そして Plastic SCM からのプルによってそれがどのように取得されるかを示します。

単にシンプルな変更を行う代わりに、図は big_feature ブランチの master へのマージを示します。次のように、Plastic SCM の結果は Git 側で発生した処理を模倣し、Plastic のブランチエクスプローラーにマージリンク（緑の線として表示される）が追加されます。

次のステップは、Plastic SCM で変更を行い、その変更を Git にプッシュします。より完全な例を作成するために、新規変更セットを作成するだけでなく、マージも行います。

変更セット 6 と 7 は Plastic 側で作成されてから、Git にプッシュされます。以下の図に示すように、Plastic から Git にマージ情報（Git リポジトリ上の複数の親）も送信されます。

ここまで、変更はどちらか一方で行われましたが、両方で同時には行われませんでした。

次の図は、複数の開発者が同じブランチで同時に作業した場合に何が起きるかを示したものです。Git で 1 件の新規コミット（緑）が作成され、Plastic でも新規コミット（オレンジ）が作成されています。

Plastic の開発者が Git へのプッシュを行おうとすると、競合する変更が存在するため、エラーが表示されます（完全な Plastic セットアップや完全な Git セットアップで同じシナリオが発生した場合も、同じことが起こります）。これを解決するには、次の手順を実行します。

1. まず、Git から変更をプルします
2. 新しい「サブブランチ」が作成され、88ffa 変更セットが正しく配置されます。
   

3. 次のステップは、Plastic SCM 側でのマージ競合を解決し、プッシュを完了することです。
   

インタラクションが完了すると、両方のリポジトリが同じ内容になり、両方の側の開発者が一緒に作業できるようになります。

GitSync 設定ファイル（gitsync.conf）を使用すると、GitSync での操作時に自動的に使用される情報を保存することができます。

この情報は、2 つの Plastic SCM オブジェクトと Git オブジェクト間でのマッピングに関連するものです。

• ユーザーアカウント
• Xlinks/サブモジュールの情報

gitsync.conf ファイルで、Plastic と Git 間の（電子メールの）マッピングを定義できます。この情報が、Git にコミットするときに作成者とコミッターとして使用されます。

この情報は、次の形式で email-mapping セクションに追加します。

plastic_user = git_email_address

gitsync.conf ファイルの例を以下に示します。

[email-mapping]
asalim = asalim@mymailprovider.com
ubuntu = ubuntu@linuxprovider.com

Git サブモジュールは単に、別のリポジトリ内のコミットへのポインターです。サブモジュール間の操作の伝播やリポジトリ間のブランチングの処理は行わないため、サブモジュールの作業を行うにあたっては、根幹となるこの基礎情報を知っているだけで十分です。

Plastic Xlink オブジェクトは Git サブモジュールよりも複雑です。ユーザーはこの Xlink を使用して、相対サーバーの設定、ブランチ拡張のためのルールの設定、Xlink が書き込み可能かどうかの定義を行うことができます。

大まかに言えば、Git サブモジュールと Plastic Xlink の目的は同じであり、別のリポジトリ内のコミットをポイントすることです。そのため、次のものの間に直接マッピングを作成できます。

• Git コミット ↔ Plastic 変更セット
• Git リポジトリ URL ↔ Plastic リポジトリ指定

GitSync を使用すると、ユーザーは Git サブモジュールから Plastic Xlink を作成することも、その逆を行うこともできます。GitSync を使用して、Git サブモジュールと Plastic Xlink を次のように同期できます。

• プル操作時に、Git サブモジュールが Plastic Xlink に変換されます。
• プッシュ操作時に、Plastic Xlink が Git サブモジュールに変換されます。

Xlink/サブモジュールを含んでいるリポジトリを同期する前に、ターゲットリポジトリを同期する必要があることに注意してください。

Xlink/サブモジュールを含んでいるリポジトリを同期するには、gitsync.conf ファイルにマッピング情報を追加する必要があります。この情報は、次の形式でサブモジュールセクションに追加します。

git_repository_url -> plastic_repository_spec [writable:true|false] [relativeserver:true|false]

• Git サブモジュールを書き込み可能な Plastic Xlink に変換する必要がある場合は、writable フィールドを writable:true に設定して含める必要があります。writable フィールドが省略されるか false に設定された場合、Xlink は読み取り専用として作成されます。
• Git サブモジュールを相対サーバーを使用した Plastic Xlink に変換する必要がある場合は、relativeserver フィールドを relativeserver:true に設定して含める必要があります。relativeserver フィールドが省略されるか false に設定された場合、Xlink は Plastic リポジトリサーバーに対して（非相対 Xlink として）作成されます。

有効な設定の例を次に示します。

[submodules]
git://localhost/code -> code@localhost:8084 writable:true relativeserver:true
git://localhost/doc -> doc@localhost:8084 writable:false relativeserver:true

GitSync を使用する際に制限されている Git の操作は、次の 2 つです。

• rebase コマンド
• merge（ファストフォワード）コマンド

これらの Git コマンドは、ユーザーが加えた変更の履歴を考慮しません。ユーザーは並行して作業できますが、Git は履歴を一直線上にあるようなものとして扱います。しかし、Plastic は変更履歴を保存することを優先します。

Plastic SCM は、ユーザーが加える変更の全履歴を考慮します。つまり、Plastic は履歴を書き換えることはしないということです。書き変えることに対して反対しているわけではなく、設計上の判断であり、哲学でした。

変更履歴は、ブランチを操作したりマージしたりしているときに反映されます。Plastic SCM は履歴がどうなっているかを解決して表示できるため、GitSync を使用しているときはそれらの Git コマンドを使用しないことを推奨します。

• リベースは Git にとって微妙な問題です。リベースはプッシュする前にのみ行うことが可能で（実際はほとんどのケースで一切使用しないことが推奨されます）、どれだけマージが行われても混乱を招くことなく、履歴を把握できるように使用されることがほとんどです。
  
  リベースについては Git のようには処理しません。
• Git のファストフォワードマージコマンドは似たようなことを行い、マージを直線的に解決します。
  
  履歴を保存するには、merge --no-ff コマンドを使用します。

Plastic にはブランチエクスプローラーがあり、何が起こっているかをグラフィカルに把握できます。これにより、他のことに惑わされることなく、リベースを見逃すことがありません。

複数のマージがあるブランチの差分を取得すると、実際にそのブランチの何を変えたのか、そのマージによって何が入ってくるのかを見分けるのは困難です。この部分も Plastic では解決済みです。

ここまで見てきたように、Plastic はネイティブな Git プロトコルと HTTPS プロトコルの両方を使用して、GitHub、BitKeeper、CodePlex などのよく知られているサイトを含めたリモートの Git サーバーに対して、直接プッシュ/プル操作を行うことができます。

Plastic SCM との Git 双方向同期の開発を開始した際には、次のようなシナリオを想定していました。

• すでに Plastic SCM を使用しており、GitHub、CodePlex、BitKeeper などのサイトにあるプロジェクトに貢献したいと考えている開発者。
• Plastic SCM を使用することを好んでいるが、貢献して加えた変更をメインのサーバーに戻して反映する必要がある、Git をプライマリサーバーとして使用してチームで作業をしている開発者。
• Plastic SCM を徐々に採用し始めており、Git を使用している他のチームに貢献する必要があるチーム。

解決するのには苦労しました。1 つのシステムからもう一方のシステムに変更を変換したり、高速インポート/エクスポートを行ったりすることを担う何らかの中間スクリプトを思いつかず、大量の制限が課されました。しかし、実際には、Git に対して直接プッシュ/プルできる Git のネットワークプロトコルを Plastic にレイヤーとして実装しました。

Plastic は、Git コマンドで行われるように、Git プロトコルを使用してリモートの Git サーバーとのネゴシエーションフェーズを開始します。これはアドオンのスクリプトではなく、コア機能です。

ここまで述べてきたように、GitSync はスマートプロトコルを実装し、さらに

• リモートの Git の受信パックとネゴシエーションを行ってデータをアップロードできます（どの変更セット/コミットが必要であるかについてネゴシエーションを行い、Plastic のリポジトリデータから Git に送信される正しいパックファイルを生成します）。
• リモートのアップロードパックとネゴシエーションを行って、どのコミットをパッケージ化する必要があるかを判断し、そのパックをダウンロードして Plastic にインポートすることもできます。

それでは GitHub リポジトリに接続していきましょう。

1. GitHub にアクセスしてリポジトリを参照すると、「trendy」リポジトリのリストなどが表示されるでしょう。例の図では、corefx リポジトリが選択されています。
   

   次に、このリポジトリを Plastic へとプルするために、「それをホストする」ためのリポジトリ（これも corefx という名前です）を作成し、初期状態で空のブランチエクスプローラーに移動して、コンテキストメニューオプションから「Git と同期」を起動します。

   

2. その後、同期ダイアログ（Plastic サーバー間で変更をプッシュ/プルするためのレプリケーションダイアログと非常に似ています）を起動し、Git リポジトリの URL を入力します。
   

   ここでは、パブリックリポジトリからプル（クローニング）するだけなので、資格情報は必要ありません。プッシュした後、認証済みユーザーであることをサーバーから要求された場合には、資格情報を指定する必要があります。

3. 「同期」を押すと、次のようにプロセスが起動します。
   
   注：この操作は、次のようにコマンドラインを使用して実行することもできます。 cm sync corefx git https://github.com/corefx/corefx.git

   ローカルの corefx リポジトリが空であれば、リモートの GitHub リポジトリからプルする必要がある変更セットとブランチが計算され、それらがプルされます。

   

   GitHub 側で作業された新しい変更セットをプルするには、同じコマンドを再実行します。

   cm sync corefx git https://github.com/corefx/corefx.git

   そうすると計算が実行され、Git 側で加えられた新しい変更のみがプルされます（もしあれば）。

   この例では、Git の変更セットとブランチをローカルの Plastic SCM リポジトリに直接プルしています。

   
   

4. レプリケーションが完了したら、ワークスペースエクスプローラーに戻り、ワークスペースを更新してソースファイルをダウンロードします。
5. ブランチエクスプローラーも最新情報に更新します。これで、インポートされた Git の変更セットを、Plastic SCM での通常の操作と同様にレンダリングできるようになります。
   

   次に、任意の変更セット（Git 用語ではコミット）を右クリックすると、組み込みの差分システムで差分をチェックできます。

   

これで、Plastic でのさらなる変更作業（ブランチ、マージなど）を行える状態になりました。その後、同じプロセスを繰り返して、それらを Git に同期することができます（それによって変更がプッシュ/プルされ、同じブランチで同時に変更が加えられた場合には、Git にプッシュする前にマージを解決するよう求められます）。

次は、Plastic リポジトリの 1 つを GitHub にプッシュしましょう。このプロセスは前のプロセスと似ています。

それでは始めましょう。

1. 自分の Plastic リポジトリを GitHub にエクスポートするために、新しい GitHub リポジトリを作成しました。
   

2. 選択した Plastic リポジトリは、dokancode です。前の章で行ったように、ブランチエクスプローラービューでブランチの 1 つを右クリックし、メニューから「Git と同期」オプションを選択します。
   

   同期ダイアログが起動します。

3. 次に、GitHub リポジトリの URL と資格情報（必要であれば）を入力します。
   

4. 次に、同期ボタンをクリックして同期を開始します。この場合は、Plastic リポジトリがプッシュ（エクスポート）されます。
   

   この例では、Plastic SCM の変更セットとブランチを GitHub リポジトリに直接プッシュしています。

   注：この操作は、次のようにコマンドラインを使用して実行することもできます。 cm sync dokancode git https://github.com/mbctesting/dokancode.git

   GitHub の dokancode リポジトリが空であれば、Plastic リポジトリからプッシュする必要がある変更セットとブランチが GitSync によって計算され、それらがプッシュされます。

   

   プッシュ操作が完了すると、エクスポートされたオブジェクトのサマリーが表示されます。

   
   

5. GitHub に戻って dokancode リポジトリを最新情報に更新すると、Plastic からエクスポートされたオブジェクトが表示されます。
   

これで、Plastic SCM と GitHub の両方でリポジトリの作業が行える状態になりました。ブランチを作成し、変更を加えた後、プル/プッシュによって再度同期を実行することができます。

この章では、dokancode リポジトリを使った作業方法について説明します。GitHub 側と Plastic 側の両方で、いくつかの基本的な操作を行います。

これから、master ブランチに対していくつかの操作を実行します。

1. license.txt ファイルを削除します。
   

2. dokan-net-0.6.0\readme_dokan.txt ファイルを編集します。
   

3. これを dokan-net-0.6.0\DokanNet フォルダーに移動します。
   

4. 次に、新規ブランチ（scm007）を作成します。
   

5. 2 つのファイルを追加します。
   
   

6. これらのファイルの 1 つを編集します。
   

コミットが完了しました。これで、Plastic 側でこれらを確認できます。

このガイドで学習したように、GitSync は、他の側の新しい部分を計算することができ、リモートサーバーとネゴシエートして変更をプッシュします。

1. では、「Git と同期」アクションを実行して、Plastic リポジトリと GitHub リポジトリの同期を行いましょう。
   
   

2. 「同期」をクリックすると、同期が始まり、それによって GitHub 側で実行された変更が Plastic リポジトリにプルされます。
   

   同期が完了すると、次のように表示されます。

   

3. サマリーおよびインポートされたオブジェクトが表示されます。
   

4. ブランチエクスプローラーに戻って、ビューを最新情報に更新すると、GitHub 側で行われた変更（Plastic にインポートされたもの）を確認できます。
   

5. 変更セットビューを開いて、このような GitHub の変更を確認できます。
   

6. また、さらに深く知りたい場合は、GitHub 側の readme_dokan.txt ファイルを使用して行われた変更を確認できます。このファイルの履歴を見て、それらの変更が同期によって適用されたことをチェックできます。
   

これで、Plastic 側で変更の実行を続けることができます。

scm005 ブランチに対していくつかの変更を実行します。この時点では、Git 側と Plastic 側の両方に同じコンテンツがあります。両方の側でこれをチェックできます。

このブランチでは次の操作を行います。

1. 新規ファイルを追加します。
   

2. DokanOperation.cs ファイルを編集します。
   

   これらが新しい変更です。

   

3. 変更が完了したら、「Git と同期」操作を実行して GitHub リポジトリを同期します。
   

4. 同期が完了したら、サマリーが表示されます。
   

   同期によって 1 つのブランチに関連する 2 つの変更セットが送信されたことがサマリーでわかります。

   

5. GitHub 側に移動すると、Plastic 側で完了された新しい変更を確認できます。
   

お気づきかもしれませんが、Plastic の main ブランチは Git の master ブランチにマップされています。このマッピングは、Plastic の main の子ブランチについても考慮されます。つまり、Plastic のブランチは、階層を削除し、/ を - に置き換えることによって Git ブランチに変換されます。そしてこのルールは、Git ブランチが Plastic ブランチに変換される際にも有効となります。- 文字を使用して、Plastic 内で階層が再作成されます。

前の例では、Plastic ブランチ /main/scm005 が master-scm005 に変換されています。また、master の下の Git ブランチ scm007 は、/main/scm007 に変換されています。

- 文字は、次の例のように、ブランチ名の一部としても使用できます。

Plastic SCM は Git と同じ概念を処理するため（DAG、コミット、マージリンクなど）、思いのほか簡単にマージの追跡を共有することができます。Git でマージを行い、微調整を加え、Plastic に戻すことができます。Plastic でマージを行う場合は、微調整を加えて、マージリンクでさえ Git にプッシュして戻すことができます。

私たちにとって取り扱いが最も難しい機能は、（Git では行われない）「正確な項目の追跡（Precise item tracking）」にまつわる機能です。Plastic には各ファイルとディレクトリに関連付けられた内部 ID が設定されています。つまりこれは Git にとって追跡が困難である大量のマージの競合を簡単に処理できるということです（分岐をしての移動なども、Plastic にとってはあっさりできてしまう処理です）。

次の例では、GitSync を使用しているときにマージの追跡がどのように機能するかをお見せします。

2 つのブランチを作成します。

1. ブランチ scm008 - DokanNet.cs ファイル内の DokanResetTimeout メソッドを編集し、それをファイル内で移動して、新しいフィールドを追加します。
   

2. ブランチ scm009 - DokanNet.cs ファイルを別のフォルダーに移動した後、メソッド DokanResetTimeout を別のクラスに移動し、編集します。
   

3. それぞれのブランチでの変更が完了したら、それらを main ブランチにマージします。結果は次のようになります。
   
   

4. 次に、ご存じのとおり「Git と同期」操作を使用して、両側のリポジトリを同期します。これにより、これらのマージが Git 側にプッシュされます。

新しいブランチがプッシュされ、Git 側ではマージの追跡が次のように表示されます。

では、Git 側でのマージが Plastic 側でどのように追跡されるかを見てみましょう。

1. 新しいブランチを作成し、新しいファイルを作成して、別のファイルを追加します。
   
   

2. コミットが完了したら、scm010 ブランチから master ブランチへのマージを実行します。
   
   「GitSync の制限事項」セクションで説明したように、--no-ff オプションを使用してマージを実行している点に注意してください。
   

   マージが完了したので、これらの変更をリモート Git リポジトリにプルします。

   

3. ローカル Git の変更がリモート Git リポジトリにプルされたら、自分のリポジトリを同期しましょう。これは、最新の変更が Plastic リポジトリにプルされることを意味します。「Git と同期」操作を実行し、
   

4. 同期の完了後にブランチエクスプローラーを最新情報に更新すると、Git 側で行われた変更とマージが Plastic 側にどのようにプルされたかを確認できます。
   

仕組みの章で説明したとおり、Plastic 側と Git 側の両方で同時に変更を行うことができます。つまり、2 つのシステムで同一ブランチの作業を行って、変更を調整することができます（純粋な Plastic 環境または純粋な Git 環境を使用する場合と同様です）。

GitSync および Plastic を使用してこの状況をどのように管理できるかについてこれから説明します。

まず、前の例の 1 つを使用して始めましょう。Git 側での変更の項で、GitHub 側でいくつか変更を行いました。行ったことは次のとおりです。

1. master ブランチで、license.txt ファイルを削除し、dokan-net-0.6.0\readme_dokan.txt ファイルを編集して dokan-net-0.6.0\DokanNet フォルダーに移動しました。
2. 次に、新規ブランチ（scm007）を作成しました。そこで、2 つの新規ファイル（ArrayIndex.cs および ArrayInitialization.cs）を追加し、そのうち 1 つ（ArrayIndex.cs）を編集しました。

ここでは、これから Plastic 側でいくつかの変更を行います。

1. main ブランチでは、DokanNet.cs ファイルを編集します。
   

2. 3 つの新規ファイルを追加します。
   

変更が完了したら、「Git と同期」操作を使用して両方のリポジトリを同期することを決定します。

同期が完了すると、マージが必要であることがメッセージで通知されます。

これは、Git 側と Plastic 側の両方で同じブランチに対して変更を行ったためです。

マージ操作が必要なブランチは main（または master）ブランチであることがサマリーに表示されます。

そのとおりです。Git 側で master ブランチにいくつかの変更を適用し、Plastic 側で main ブランチに別のいくつかの変更を適用しました。main と master は同一ブランチですが、使用している名前が異なることに注意してください（詳細については、Git および Plastic のディクショナリを参照してください）。

仕組みの項で説明したとおり、Plastic 側でマージの競合を解決する必要があります。早速、始めましょう。

1. ブランチエクスプローラーを更新すると、次のことを確認できます。
   • まず、main ブランチに、マージが必要な複数の「ヘッド」があります。このような競合は Plastic SCM ではサブブランチとして処理されるためです。
   • 次に、scm007 ブランチが同期されています（GitHub から Plastic SCM にプルされています）。
   

2. この競合を解決するために、GitHub のヘッド（サブブランチのヘッド）からマージを実行します。
   

   マージ対象の変更が表示されます。

   

3. 「すべてのマージを処理」ボタンをクリックすると、項目が自動的にマージされます。
4. おわかりのように最後のステップは、保留中の変更ビューでの変更のチェックイン（確認）です。
   

5. 「チェックイン」ボタンをクリックすると、2 つの「ヘッド」が 1 つのヘッド（main ブランチのヘッド）にマージされることを確認できます。
   

6. マージ競合が解決されました。ただし、Plastic 側で行われた変更を Git 側にプッシュして、同期を完了する必要があります。また、ご存じのように、これは「Git と同期」アクションを使用して行います。

この操作が完了すると、両方のリポジトリが完全に同期しています。つまり、両方の側で同一の内容を保持しています。

GitSync では、SSH プロトコルを使用した Git リポジトリとの同期がサポートされています。

SSH プロトコルを使用すると、リモートのサーバーやサービスに接続し、認証を行うことができます。

この機能を使用するには：

1. PATH 環境変数には、コマンドライン SSH クライアント ssh を必ず含めるようにしてください。
2. ssh-agent にはプライベート SSH キーを必ず追加するようにしてください。ssh-agent に SSH キーを追加するには、これらの指示に従ってください。

   これにより、SSH キーが SSH エージェントによって管理され、パスフレーズが記憶されます。

これで、Plastic GUI または CLI を使用して、通常の HTTP プロトコルの場合と同様に GitSync を使用できます。

例を見てみましょう。コマンドラインを使用する場合は、SSH プロトコルの URL を適切に指定する必要があります。

HTTPS プロトコルの場合は次のようになります。

2020 年 9 月 24 日

2020 年 5 月 26 日

2017 年 6 月 16 日

2016 年 4 月 12 日