| タスク | ||
|---|---|---|
|
|
|
|
| 概念 | 参照 | |
EGit を使用して Git リポジトリーをセットアップする場合、(「プレイグラウンド」とは対照的な)「実動」リポジトリーの作成に関して次の 2 点の推奨事項があります。
最初の点は、リポジトリーを作成またはクローン作成中にワークスペース・フォルダーを指定する場合に関係します。
どちらの点も、ワークスペースに手動で作成した Eclipse プロジェクトから予防措置を取らずに Git 共有ウィザードを使用するときに関係します (このウィザードは最新バージョンで修正されています)。
これらの推奨事項に関して、以下を参照すると背後にある事柄について理解できます。
Git リポジトリーはいくつかの異なる方法で作成できます。例えば、既存のリポジトリーからクローン作成する方法、一から作成する方法、EGit 共有ウィザードを使用する方法などです。
どの場合であっても (ここでは取り上げませんが、「ベア」リポジトリーを作成するのではない限り)、本質的に新しいリポジトリーは、「作業ディレクトリー」とメタデータ・フォルダーが含まれる、ローカル・ハード・ディスク上のフォルダーです。メタデータ・フォルダーは「.git」という名前の専用の子フォルダーで、しばしば「.git-folder」とも言われます。そこには、実際のリポジトリー (つまり、コミット、参照、ログなど) が入ります。
メタデータ・フォルダーは、Git クライアントに対して完全に透過的ですが、作業ディレクトリーは、現在チェックアウトされているリポジトリー・コンテンツをツールおよびエディターのファイルとして公開するために使用されます。
通常、これらのファイルを Eclipse で使用する場合は、Eclipse ワークスペースに何らかの方法でインポートする必要があります。そのためには、プロジェクトを簡単に作成できる「Import Existing Projects」ウィザードから .project ファイルにチェックインするのが最も簡単です。そのためほとんどの場合には、Eclipse プロジェクトが含まれるリポジトリーの構成は、以下のようになります。
前述の点には、以下の影響があります。
最初にプロジェクトを作成し、その後共有できます。プロジェクト共有ウィザードは、Git リポジトリーの作成をサポートしています (Adding a project to version control を参照してください)。
また、Git リポジトリー・ビューから空の Git リポジトリーを新規作成することもできます ( リポジトリーの作成を参照してください)。
最初に、共通ディレクトリーの下に複数のプロジェクトを作成してから、すべてのプロジェクトの共通リポジトリーを一度に作成することができます。
Eclipse ワークベンチで Git リポジトリーのコンテンツを処理するには、含まれているファイルおよびフォルダーをプロジェクトとしてインポートする必要があります。原則として、このインポートは汎用の「New Project」ウィザードまたは「Import...」ウィザードを使用して実行できます。Git リポジトリーの作業ディレクトリーは、ローカル・ファイル・システムの通常のディレクトリーだからです。ただし、新しく作成するプロジェクトは、Git で手動で共有する必要があります。「Import Projects from Git」ウィザードでは、プロジェクトのインポートと共有をまとめて行えるほか、便利な点がほかにもあります。
ウィザードを開始するには、「Import」>「Git」>「Projects from Git」とクリックします。
クリーン・ワークスペースで開始した場合、最初のページには空のリストが表示されます。
続行するには、その前に 1 つ以上の Git リポジトリーをリストに追加しなければなりません。既にリポジトリーがリストにある場合、このステップはオプションです。
Git リポジトリーをリストに追加するには、次の 2 つの方法があります。
この最初のオプションは、リモート・リポジトリーを使用して開始するときのものです。クローン操作によって、そのリポジトリーがローカル・ファイル・システムにコピーされます。クローン作成ウィザードを開始するには、「Clone...」をクリックします。クローン作成ウィザードの詳細については、 リモート・リポジトリーのクローン作成を参照してください。クローン操作が正常に完了すると、新しくクローン作成されたリポジトリーがリストに自動的に表示されます。
2 番目のオプションは、ローカル・ファイル・システムに既にリポジトリーがある場合 (以前にクローンを作成した場合、最初から作成した場合、別の場所からコピーした場合など) に役立ちます。「Add...」をクリックし、ローカル・ファイル・システムのディレクトリーを選択します。「Search」を押して、このディレクトリーに含まれる Git リポジトリーのスキャンを起動します。Git リポジトリーが見つかった場合、それらがリストされ、追加するリポジトリーを選択できます。
正常に完了すると、リポジトリー・リストには次のようにリポジトリーがいくつか含まれているはずです。
リポジトリーを選択して、「Next」をクリックします。次のウィザード・ページで、プロジェクトのインポート方法を決めます。
このページには、ウィザードを選択できるラジオ・ボタンのあるグループが示されます。また、作業ディレクトリー内のフォルダーをオプションで選択できるディレクトリー・ツリーも示されます。
このラジオ・ボタンを選択すると、ウィザードはローカル・ファイル・システムで .project ファイルをスキャンし、インポート対象として検出されたプロジェクトを表示します。これが最も便利な方法で、.project ファイルをリポジトリーにチェックインする場合は、この方法を使用してください。
この場合、下のディレクトリー・ツリーがアクティブになります。.project ファイルの検索範囲を絞り込むために、このツリー内のフォルダーを選択できます。選択しない場合には、リポジトリーの作業ディレクトリー全体がスキャンされます。次のページに、検出されたプロジェクトが存在する場合には、そのリストが表示されます。これは汎用の「Import Existing Projects」ウィザードとよく似ていますが、フィルター機能がいくつか追加されています。
このオプションを選択すると、汎用の「New Project」ウィザードが開きます。「New Project」ウィザードが完了すると、「Import Projects from Git」ウィザードが再開され、先ほど作成したプロジェクトの共有が支援されます。
この場合、下のディレクトリー・ツリーは非アクティブです。「New Project」ウィザードでは選択する場面がないためです。
このオプションは、使用可能な .project ファイルも、Git リポジトリーのコンテンツに適した「New Project」ウィザードもない場合に役立ちます。選択すると、ウィザードによって .project ファイルが生成され、プロジェクトがリポジトリーの作業ディレクトリーのフォルダーを指すようになります。この結果、「一般プロジェクト」になります。
デフォルトでは、新しく生成されたプロジェクトはリポジトリーの作業ディレクトリーを指します。下のディレクトリー・ツリーからフォルダーを選択すると、そのフォルダー用にプロジェクトを生成できます。
「Next」をクリックすると、新規プロジェクトの名前とディレクトリーを入力するための単純なダイアログが開きます。
デフォルトでは、ディレクトリーの名前と同じプロジェクト名が提案されます。
Git クローン作成ウィザードを使用すると、さまざまなトランスポート・プロトコルでリモート・リポジトリーのクローンを作成できます。
このウィザードは、「Import...」>「Git」>「Projects from Git」>「Next」>「Clone...」
と選択して、「Import Projects from Git」ウィザードから開始するか、
「Clone a Git Repository」ツールバー・ボタンまたはビュー・メニューを使用して、Git リポジトリー・ビュー (リポジトリーの管理で説明されています) から開始できます。
ウィザードの最初のページで、リモート・リポジトリーのロケーションを入力します。
次のプロトコルがサポートされています。
注: ファイアウォールの内側にいる場合、プロキシー設定が必要になることがあります (「Preferences」>「General」>「Network Connections」)。多くの HTTP プロキシーは、http://fred:topsecret@egit.eclipse.org/egit.git などのユーザー名 (またはパスワード、あるいはその両方) を含む URL をブロックするように構成されているため、ウィザード・ページの下部にある「user」、「password」 フィールドを使用することをお勧めします。資格情報は HTTP ヘッダーとして送信されます。
次のページで、リモート・リポジトリーから複製するブランチを選択します。
必要なブランチが不明な場合は、「Select All」を押します。
リストの上にあるテキスト・コントロールを使用して入力することにより、ブランチを名前でフィルタリングできます。ただし、チェックされたブランチは必ずリストに表示され、フィルタリングされません。
次のページで、ローカル・ファイル・システムにリポジトリーを保管する場所と、いくつかの初期設定を定義します。
Git リポジトリーを格納するためのデフォルト・ルート・パスは、設定の
「Team」>「Git」>「Default Repository Folder」で構成できます。
このページで 「Finish」を押すか、Gerrit Code Review を使用して作業していて、それに応じてリポジトリーを構成する場合には「Next」を押します。
EGit のクローン作成ウィザードを他のプラグインで拡張し、Git リポジトリーをホストする特定のバックエンドのリポジトリーを検索できます。現在、このような拡張機能は Github で使用でき、まもなく Gerrit でも使用できるようになります。どちらの場合も、それぞれの Mylyn コネクターをインストールする必要があります。その後 Gerrit Mylyn コネクター拡張では、Gerrit で作業するためのリモート・リポジトリーも構成します。この点は、後ほど Git リポジトリー・ビューから設定または変更できます。Gerrit 構成を参照してください。
そのような拡張をインストールすると、クローン作成ウィザードが開き、クローン作成するリポジトリーのソースを選べる選択ページが表示されます。
いわゆる「アップストリーム構成」を持つローカル・ブランチで作業している場合、プッシュを行うのに最も便利な方法は、そのアップストリーム構成に依存します。
通常、ローカル・ブランチはリモート・トラッキング・ブランチに基づいて作成されます。リモート・トラッキング・ブランチはリモートに関連付けられていて、そのリモートには対応するリモート・リポジトリーにアクセスするために必要な情報が含まれているため、ローカル・ブランチを作成しながら、このアップストリーム構成を自動的に作成することができます (詳しくは、ブランチを参照してください)。
ローカル・ブランチからアップストリームをプッシュする場合、プッシュには追加パラメーターは必要ないため、別のダイアログを表示することなく、保管されているアップストリーム構成に基づいて実行できます。
アップストリームをプッシュするには、プロジェクトを右クリックして「Team」>「Push to upstream」を選択するか、リポジトリー・ビューでリポジトリーを右クリックして「Push to upstream」をクリックします。Git コマンド・グループにも使用できるアクションがあります。
その後、アクションを選択するとすぐにプッシュが実行されます。完了すると、プッシュされたデータまたはエラー・メッセージ (あるいはその両方) に関する情報が確認ダイアログに表示されます。
アップストリーム・プッシュの構成は、前述の確認ダイアログにある「Configure...」ボタンを使用するか、プロジェクトを右クリックして「Team」>「Remote」>「Configure push to upstream...」を選択して行えます。
プッシュ URI と対応するブランチ・マッピング (RefSpecs) を構成するための構成ダイアログが表示されます。
ダイアログは 3 つのメイン・セクションに分割されています。上部には、現在のリポジトリーと現在チェックアウトされているブランチに関する情報が表示されます。その外側のグループには、現在のブランチに関連付けられているリモートのプッシュ構成が示されます (今回の場合、グループ・テキストには「origin」と示されています)。
この具体的な例では、「origin」という名前のリモートを使用するブランチがいくつか存在することを示す警告メッセージが示されています。つまり、プッシュ構成の変更が、「Branch」フィールドに表示されるブランチだけでなく、これらすべてのブランチに影響するということです。
「URI」グループには、「URI」フィールドと「Push URIs」リストの 2 つのコントロールがあります。このリストが空の場合、「URI」フィールドの URI がプッシュに使用され、「Push URIs」リストに 1 つ以上のエントリーがある場合には、リスト内の URI が使用されます。「Push URIs」リストが空で、URI をこのダイアログで変更すると、その新しい URI もプルに使用されるので、変更する場合には注意が必要です。
「Ref Mapping」グループを使用すると、プッシュ用の 1 つ以上の RefSpecs (Refspecs を参照してください) を指定できます。
「Add」をクリックすると、RefSpecs の作成に役立つ小規模のウィザードが表示されます。RefSpec をクリップボードからリストに貼り付けることもできます。
「Advanced」コントロールをクリックすると、後述するプッシュ・ウィザードと同様に、より複雑な RefSpec 編集を行える「Edit (Advanced...)」ボタンの表示/非表示が切り替わります。
下部のボタン・バーにあるボタンを使用すると、変更内容を保存して即時にプッシュを実行したり、取り出すことなく変更を保存したり、ドライラン (構成を保存せずにプッシュ) を行ったり、変更を元に戻したり、キャンセルしたりできます。
リモートのプッシュ仕様に関してダイレクト・プッシュ・サポートを使用することもできます。
最も強力 (ただし、最も複雑) な手段は、プッシュ・ウィザードを使用することです。
そのためには、「Team」>「Remote」>「Push...」と選択します。
詳細については、Refspecs も参照してください。
「Next」をクリックします。
SSH を使用してこのリポジトリーに初めて接続する場合には、リモート・リポジトリーのホスト・キーを受け入れることが必要になります。
SSH 鍵が (推奨どおりに) パスフレーズによって保護されている場合、ここに入力する必要があります。
「Add all branches spec」をクリックします。
これは、ローカル・ブランチ名を、変更をプッシュするアップストリーム・リポジトリー上の同じブランチ名にマップすることを宣言するための便利な方法です。
「Add all tags spec」をクリックして、ローカル・タグを、プッシュ先のリポジトリーのタグと 1:1 でマップします。
ローカル・ブランチをアップストリーム・リポジトリー内のブランチに別の方法でマップする場合は、以下の方法でより詳細なマッピング仕様を定義できます。
これにより、新たに定義したマッピングが「Specifications for push」リストに転送されます。
その他の一般的なプッシュ仕様:
宛先リポジトリー内の参照を削除するには、「Remote ref to delete」ドロップダウン・リストから削除対象の参照を選択し、「Add spec」をクリックします。これにより、「Specifications for push」リストに対応するエントリーが作成されます。あるいは、削除する参照の仕様を入力することもできます。この場合、ワイルドカードも使用できます。削除参照の仕様をプッシュすると、宛先リポジトリーで一致する参照が削除されます。
競合する複数のプッシュ参照仕様を追加すると、それらに赤色のマークが付けられます。競合する仕様を削除または編集して解決してください。また、「Specifications for push」リストで仕様をインプレース編集することもできます。
「Next」をクリックします。
これにより「Push Confirmation」ダイアログが開き、変更が宛先リポジトリーにプッシュされるときのプレビューが示されます。これが予想と一致しない場合は、「Back」をクリックして、プッシュ仕様を適宜修正します。
「Finish」をクリックします。
選択したオプションに応じて、プッシュ結果レポート・ダイアログが表示されます。
下部のボックスに、リモート・サーバーからのプッシュ確認メッセージが表示されます。エラーが発生した場合は、リモート・サーバーからのエラー・メッセージがここに表示されます。指定したリスト項目のメッセージを表示するには、単にリストで選択します。
「OK」をクリックしてダイアログを閉じます。
いわゆる「アップストリーム構成」を持つローカル・ブランチで作業している場合、取り出しを行うのに最も便利な方法は、そのアップストリーム構成に依存します。
通常、ローカル・ブランチはリモート・トラッキング・ブランチに基づいて作成されます。リモート・トラッキング・ブランチはリモートに関連付けられていて、そのリモートにはリモート・リポジトリーにアクセスするために必要な情報が含まれているため、ローカル・ブランチを作成しながら、このアップストリーム構成を自動的に作成することができます (詳しくは、ブランチを参照してください)。
アップストリームから取り出す場合、この保持される構成を使用して、ダイアログにさらにパラメーターを指定せずに自動的に取り出すことができます。
アップストリームから取り出すには、プロジェクトで「Team」>「Fetch from upstream」をクリックするか、リポジトリー・ビューのリポジトリーで「Fetch from upstream」をクリックします。Git コマンド・グループにも使用できるアクションがあります。
アクションを選択するとすぐに取り出しが実行されます。完了すると、取り出されたデータまたはエラー・メッセージ (あるいはその両方) に関する情報が確認ダイアログに表示されます。
アップストリーム取り出しは、前述の確認ダイアログの「Configure...」ボタンを使用するか、プロジェクトで「Team」>「Remote」>「Configure fetch from upstream...」とクリックして構成できます。
取り出し URI とブランチ・マッピング (RefSpecs) を構成するための構成ダイアログが表示されます。
ダイアログは 3 つのメイン・セクションに分割されています。上部には、現在のリポジトリーと現在チェックアウトされているブランチに関する情報が表示されます。その外側のグループには、現在のブランチに関連付けられているリモートの取り出し構成が示されます (今回の場合、グループ・テキストには「origin」と示されています)。
「URI」フィールドは、取り出し URI を追加/変更するときに使用できます。
「Ref Mapping」グループを使用すると、取り出し用の 1 つ以上の RefSpecs (Refspecs を参照してください) を指定できます。
「Add」ボタンをクリックすると、RefSpecs の作成に役立つ小規模のウィザードが表示されます。RefSpec をクリップボードからリストに貼り付けることもできます。
「Advanced」コントロールをクリックすると、後述する取り出しウィザードと同様に、より複雑な RefSpec 編集を行える「Edit (Advanced...)」ボタンの表示/非表示が切り替わります。
下部のボタン・バーにあるボタンを使用すると、変更内容を保存して即時にプッシュを実行したり、取り出すことなく変更を保存したり、ドライラン (構成を保存せずに取り出し) を行ったり、変更を元に戻したり、キャンセルしたりできます。
取り出しを行うもう 1 つの方法は、リモートの取り出し仕様でダイレクト取り出しサポートを使用することです。
最も強力 (ただし、最も複雑) な手段は、取り出しウィザードを使用することです。
その場合、「Team」>「Fetch...」と選択します。
詳細については、Refspecs も参照してください。
「Next」をクリックします。
「Add all branches spec」をクリックします。
これは、変更を取り出すアップストリーム・リポジトリーのブランチ名を、同じローカル・ブランチ名に 1:1 でマップすることを宣言するのに便利な方法です。
アップストリーム・リポジトリーにあるブランチまたはタグを別の方法でローカル・ブランチにマップする場合には、次の方法でより詳細なマッピング仕様を定義できます。
これにより、新たに定義したマッピングが「Specifications for fetch」リストに転送されます。
「Finish」をクリックします。
取り出し結果ダイアログが表示されます。
プル元のアップストリーム・ブランチのアドホック選択は、EGit ではまだサポートされていません。
使用可能な代替方法は以下のとおりです。
Gerrit (http://code.google.com/p/gerrit/) で作業している場合、EGit を使用すると、検査や変更のために変更をローカル・リポジトリーに簡単に取り出すことができます。
プロジェクトを右クリックして「Team」>「Remote」>「Fetch from Gerrit...」と選択するか、リポジトリー・ビューでリポジトリー・ノードを右クリックして「Fetch from Gerrit...」を選択します。
URI および変更を選択または入力したり、他のオプションを設定したりできるダイアログが表示されます。
変更 ID をコピー・アンド・ペーストしたり手動で入力したりする面倒な方法ではなく、ダイアログでは変更のコンテンツ・アシストも利用できます。Ctrl+Space を押すだけでアクティブになります (「Change」フィールドの近くにある小さな電球の上にマウスを合わせると表示されるツールチップを参照してください)。Gerrit サーバーに接続し、使用可能なすべての変更が取り出されて、コンテンツ・アシスト・ダイアログに表示されます。
リストは、「Change」フィールドの入力内容でフィルタリングされます。コンテンツ・アシストで変更を選択すると、「Change」フィールドに正しい情報が入ります。
ラベル装飾には、Git バージョン管理下にあるリソースの Git 固有の情報が示されます。この情報は、パッケージ・エクスプローラー、プロジェクト・エクスプローラー、ナビゲーター、階層ビューなどのモデル・オブジェクトを表示するすべてのビューに表示されます。
Git ラベル装飾は、「Preference」メニュー (「Window」>「Preferences」) の「General」>「Appearance」>「Label Decorations」でグローバルにオンに切り替えることができます。
より詳細な設定は、「Preferences」の「Team」>「Git」>「Label Decorations」で行えます。
ラベル装飾には、テキスト装飾とアイコン装飾の 2 種類があります。
テキスト装飾は、テキスト・ラベルの右側または左側に表示されます。「Preferences」ダイアログの「Team」>「Git」>「Label Decorations」の「Text Decorations」タブで構成できます。例えば、dirty リソースのデフォルトは、名前の左側にある > です。
デフォルト設定を以下に示します。
ファイルとフォルダーの場合、"name"、"dirty"、"staged" という変数があります。"Dirty" と "staged" はフラグで、true の場合にはコロンの後のテキストが表示されます。
プロジェクトの場合、"repository" と "branch" という追加変数があります。"repository" 変数は、リポジトリーの名前を表示します。
"branch" 変数は、現在チェックアウトされているブランチの名前を表示します。チェックアウトされているブランチがない場合、装飾にはコミットの短縮名 (最初の 7 文字の後に省略符号) が表示されます。タグまたはリモート・ブランチ (あるいはその両方) がこのコミットを指している場合、この情報を表示するために「最適推測」のヒューリスティックも適用されます。タグはリモート・ブランチよりも優先され、複数のタグが適用されている場合には、最新のものが示されます。変更日付のない複数のリモート・ブランチまたはタグがある場合、英数文字によるソートが適用されて、最後のものが表示されます。例: チェックアウトされたコミット
e49f576...はリポジトリー
egit のタグ
v.0.7.1 を表しています。
アイコン装飾は、ラベルの前に表示されるアイコンの右下隅に表示されます。「Preferences」ダイアログの「Team」>「Git」>「Label Decorations」の「Icon Decorations」タブで構成できます。
デフォルト装飾を以下に示します。
変更されたすべての追跡対象ファイルの状況の要約が、コミット・ダイアログに表示されます。ファイルをダブルクリックすると、コミットされる変更が比較ダイアログに表示されます。現在 EGit では作業ツリーの内容をコミットするときに (コマンド行の git commit-a に相当)、比較ダイアログで作業ツリーと最終コミットが必ず比較されます。
日常の作業では、最終コミット、索引、および現行作業ツリーの間の変更を確認する必要がよく生じます。そのためには、プロジェクト・エクスプローラーまたはナビゲーターでリソース (プロジェクト、フォルダー、またはファイル) を選択し、「Compare With」の下のアクションを右クリックします。
特定のコミット内容を分析するには、このタスクを実行しやすくするヒストリー・ビューを使用することをお勧めします。コミットの検査を参照してください。
単一ファイルで「Compare With」のサブメニュー・アクションのいずれかを使用すると、比較エディターが表示されます。それ以外の場合は、変更を参照できる Git ツリー比較ビューが開きます。変更されたファイルをこのビューでダブルクリックすると、このファイルの比較エディターが開きます。例外として、ヒストリー・ビューを開くサブメニュー・アクション「History...」があります。
現行作業ディレクトリー内のリソースと現行ブランチ内の最終コミットとの差異は、コンテキスト・メニュー「Compare With」>「HEAD revision」で表示できます。このフィーチャーは、コミット・ダイアログでも使用できます。コミット・ダイアログで項目をダブルクリックすると、比較ダイアログが開きます。
現行作業ツリーと (現在選択されているリソースに基づく) 索引の差異は、コンテキスト・メニューの「Compare With」>「Git Index」で表示できます。
このフィーチャーはまだ実装されていません。
作業ツリー (コミットされていない変更が含まれる) とブランチまたはタグの間の差異は、プロジェクトの動的メニュー「Team」>「Synchronize」をクリックして、作業ツリーに関して同期する参照 を選択すると、表示できます。Git リポジトリーに複数の Eclipse プロジェクトが含まれている場合、1 つのプロジェクトを選択するだけで十分です。同期ビューには、他のすべてのプロジェクトも含まれます。
動的メニューにリストされていない参照と同期する場合には、「Team」>「Synchronize」>「Other...」をクリックします。次に、同期ウィザードで同期するリポジトリーの「Destination」列をクリックし、比較対象の参照を選択します。
「Include local uncommited changes in comparison」をクリックすると、ローカルで、まだステージングされていない変更と既にステージングされた変更も比較対象として表示されます。
また、一度に複数のリポジトリーを比較することもできます。その場合には、同期ウィザードで、各リポジトリーに関して比較する参照を選択します。
比較エディターの代わりに、クイック Diff サポートを有効にして、テキスト・エディター内で変更を確認できます。
このフィーチャーは、「General」>「Editors」>「Text Editors」>「Quick Diff」設定ページで使用可能にできます。
その後、エディターの左側に差異注釈が表示されます。
注釈の上にマウスを移動すると、比較するバージョンの内容が表示されます。
デフォルトの場合、比較は HEAD に対して行われます。ヒストリー・ビュー (「Show in」>「History」) のコミットのコンテキスト・メニューから、比較対象のバージョン (いわゆるクイック Diff ベースライン) を選択できます。3 つのメニュー項目があります。
指定のコミットを検査するには、次のようにします。
ヒストリー・ビューの左下のペインに Diff が表示されます。右下のペインでファイルを選択すると、Diff の対応するファイルのセクションにスクロールします。
右下のペインでファイルをダブルクリックしたときの動作は、比較モードの切り替えボタンの状態によって異なります。オンの場合、現行コミットのファイルの内容と祖先コミットの内容を比較する比較エディターが開きます。オフの場合は、現行コミットのファイルの内容を示すエディターが開きます。
Git バージョン管理されているプロジェクトに加えられた変更は、コミットによって Git ヒストリーで保持されます。最初に Git リポジトリーからチェックアウトされた状態から、満足できる状態になるまでプロジェクトを変更し、その後それらすべての変更を 1 回のコミットとしてリポジトリーにコミットします。各コミットは、リポジトリーに保管されるすべてのファイルの、明確に定義されたスナップショットを表します。
Git で既に共有しているプロジェクトを変更するには、Eclipse 内で、またはファイル・システム内で直接ファイルを変更または削除します。これらの操作について、Git に事前に通知する必要はありません。バージョン管理する必要がある新規ファイルは、明示的に Git バージョン管理に含める必要があります。
または、コミット・ダイアログで追跡対象外のファイルを表示し、「Show untracked Files」チェック・ボックスにチェック・マークを付けて、それらのファイルをコミットに含めるように選択することもできます。
パッケージ・エクスプローラー・ビューなどにラベル装飾機能によって、以下のことが示されます。
詳しくは、ラベル装飾を参照してください。
次のファイルに関する、パッケージ・エクスプローラーにおける例を示します。
変更をコミットするには、プロジェクトのリソースのコンテキスト・メニューで「Team」>「Commit...」をクリックします。
Git は、リポジトリー全体におけるすべての変更を追跡し、それらのファイルが同じ Eclipse プロジェクト内にあるかどうかに関係なく、そのリポジトリー内のすべてのバージョン管理対象ファイルの変更を取り込みます。
コミットをトリガーすると、コミット・ダイアログがポップアップ表示されます。
コミット・ダイアログで、変更について記述したコミット・メッセージを指定します。
変更を要約した短い最初の行でメッセージを開始し、それに続きブランク行、メッセージ本体の順にすることをお勧めします。また Git コマンド行ツールがこれらのメッセージを適切にフォーマット設定できるようにするため、行の幅が広くなりすぎないようにフォーマット設定してください (グレーの垂直線を超えないようにします)。
コミット・メッセージ・テキストは、Eclipse スペル・チェッカーでエラーが検査されます。スペル・チェッカーは、Eclipse の「Preferences」>「General」>「Editors」>「Text Editors」>「Spelling」を使用して構成できます。Ctrl+1 を押すと、スペル・エラーの修正に役立つクイック・フィックスが開きます。
コミット・メッセージ・エディターでは、コミット・ダイアログの「Files」セクションに表示されるファイル名に関してコンテンツ・アシストを使用できます。Ctrl-Space を押すと、アクティブになります。
フッター・タグ
コミット・メッセージの最後の段落では、オプションのフッター・タグが以下のように続く場合があります。
Bug: 3176 Change-Id: I267b97ecccb5251cec54cec90207e075ab50503e Reported-by: Joe Developer <joe@dev.org> Signed-off-by: William Shakespeare <will.from@the.past>
これらのタグのセマンティクスは、プロジェクトまたはツールに固有です。
さらに、このダイアログは、コミットに含める変更を制御します。ファイルの前にあるチェック・ボックスのチェックを外すと、そのファイルへの変更はコミットに含まれません。Eclipse ワークスペース内のローカル・ファイルには、後続のコミットでコミットできる変更がまだ残っています。このフィーチャーは、一連のファイルに加えた変更を異なるコミットに分割するときによく使用されます。
1 つの例: 最終コミット以降、A.java にあるバグを修正し、新しいメソッドを B.java に追加したとします。こうした 2 つの変更は相互に論理的に独立しているため、2 つの独立したコミットでコミットしたい場合があります。この場合、コミットを初期化し、コミット済みファイルのセットから B.java を選択解除し、A.java のバグ修正のみを記述したコミット・メッセージを指定します。最初のコミットが正常に行われた後、コミットを再び呼び出すと、B.java に残っている変更を示すダイアログが表示されます。今度は追加メソッドについて記述したコミット・メッセージを指定し、2 番目のコミットを終了します。
バージョン管理に明示的に追加されていないプロジェクトに追加した新規ファイル (『コンテンツの変更』を参照) は、「Show untracked Files」チェック・ボックスを選択した場合にはコミット・ダイアログにリストされます。リスト内のこれらのファイルの前にあるチェック・ボックスを選択した場合、「Commit」ボタンを押すとリポジトリーに追加されてコミットされます。チームの無視リストまたは .gitignore ファイルで除外したファイルや、(java プロジェクトの bin フォルダーなど) 派生したファイルはここには表示されません。このような追跡対象外ファイルではなく、リポジトリーに他に変更がない場合は、デフォルトで「Show untracked Files」チェック・ボックスが選択されます。
変更のコミット時に何かが間違っていた場合は、これを修正できます。コミット・ダイアログを再度開いて、現在のコミットが現行ブランチにある直前のコミットを「修正」するように指定します。その後、新規コミットが前のコミットと置き換わります。このフィーチャーは、他のリポジトリーに公開される前に誤りのあるコミットを修正するためによく使用されます。
注: 共有リポジトリーに既に公開したコミットは修正しないでください。こうしたコミットを修正すると、公開された変更に基づいて他の変更が加えられている場合には、混乱の原因となる可能性があります。
修正例:
タイプミスを含むファイルに対して変更をコミットしたとします。
変更をコミットした後にタイプミスに気付きます。この入力と対応するコミットを修正するには、ソース・ファイルで入力を修正するだけです。
次にもう一度コミット・ダイアログを開き、「Amend previous commit」オプションを選択します。
前のコミットのコミット・メッセージ (置き換える必要があるメッセージ) が「Commit Message」フィールドに入ります。これにより、バージョン管理されているファイル内容のエラーを修正するだけでなく、変更を説明するコミット・メッセージ内のエラー (タイプミスなど) も訂正できます。
修正する代わりに、修正後のバージョンを後続コミットとしてコミットすることもできます。ただし、タイプミスが含まれる最初のコミットはだれも必要としないため、不必要なコミットでプロジェクトのヒストリーが乱雑になるのを防ぐためにこのコミットを修正することができます。
既に他のリポジトリーに公開されているコミットを修正すると、問題が発生する可能性があることに注意してください。リモート・リポジトリーにコミットをプッシュした場合、またはローカル・リポジトリーを他のユーザーがクローン作成した場合、コミットの修正は慎重に行う必要があります。その場合には、最初のコミットを修正する 2 番目のコミットを公開するのがおそらくより良い解決策となります。そうしない場合は、公開したコミットを修正したことを他のすべてのユーザーに通知し、それに応じて対応できるようにします。
選択した一連のファイルに関して、まだコミットされておらず、ステージングもされていない変更は元に戻すことができます。 パッケージ・エクスプローラーや類似したビューでファイルを選択するか、「Replace With」>「File in Git Index」とクリックします。
このフィーチャーは現在、単一ファイル・レベルでは使用できません。「Reset to」をオプション「hard」と併用して、リポジトリーの作業ツリー全体を HEAD コミットの状態に強制的に戻すことができます (下にある『現行の HEAD のリセット』を参照)。この操作により、作業ツリーと索引のすべての変更が元に戻ります。現時点では、EGit を使用して選択した一連のファイルに対してこの操作を実行することはできません。
クイック Diff フィーチャーを使用すると、ファイルに対する個別の変更を元に戻すことができます。行、ブロック (特定の範囲の変更行)、または選択対象ごとに戻すことができます。すべてのテキストを選択し、「Revert selection」を選んでファイル全体を元に戻します。
特定のコミットによって導入された変更は、現在チェックアウトされているコミット上に自動的に作成された新規コミットによって元に戻すことができます。そのために、元に戻すコミットをチェックアウトする必要はありません。
ヒストリー・ビューでコミットを選択し、コンテキスト・メニューを開いて「Revert Commit」を選択します。これにより、現在チェックアウトされているコミットの上に新規コミットを作成することによって、選択したコミットで導入された変更が元に戻されます。
Git では、現行ブランチの HEAD を他のコミットにリセットできます。オプションで、そのコミットに一致するように索引および作業ツリーをリセットできます。このアクションは、リポジトリー全体のすべてのファイルおよびフォルダーに影響を与えることに注意してください。
ハード・リセット、混合リセット、ソフト・リセットを実行するオプションがあります。
プロジェクトで、「Team」>「Reset...」と選択します。これにより、ブランチまたはタグを選択できるダイアログが開きます。
ヒストリー・ビューでコミットを選択し、コンテキスト・メニューを開きます。「Hard reset」、「Mixed reset」、および「Soft reset」という項目が表示されます。
これは、特殊なケースのリセットとして行うことができます。オプション「hard」を指定して現行 HEAD (通常はブランチの最終コミット) にリセットすると、作業ツリーと索引が HEAD のコンテンツで上書きされます。これは、次の 3 つの方法で行うことができます。
ブランチの数が多すぎると、リストにすべてが表示されません。この場合には、次のようにします。
または
この操作は、必ずブランチ作成ダイアログを使用して行います。新しく作成したブランチは、ダイアログのチェック・ボックスを選択することでチェックアウトすることもできます。
ローカル・ブランチを作成するためにいくつかのアクションを使用できます。これらすべてのアクションでは、ブランチ作成ダイアログを使用します。
上部のコンボでは、新しいブランチのベースにするブランチまたはコミットを選択できます。通常、これはリモート・トラッキング・ブランチですが、リポジトリーの任意のブランチまたはコミットにすることができます。
「Pull Strategy」グループを使用すると、「アップストリーム構成」のデフォルト・セットアップをオーバーライドできます。これは、取り出しとプッシュ時に、さらには特にプルのときに役立ちます。選択したオプションによっては、以下の構成を選択できます。
リポジトリー構成でアップストリーム構成を表示および編集できます。
また EGit では Git 構成パラメーター branch.autosetuprebase がサポートされるので、デフォルトでリベース・プル戦略を使用する場合、always に設定します。リポジトリー構成でこれを設定すると、このリポジトリー内のリモート・トラッキング・ブランチに基づいて作成されたすべてのローカル・ブランチで使用されます。ユーザー構成でこれを設定すると、すべてのリポジトリーで使用されます。
下部では、新しいブランチをすぐにチェックアウトするかどうかを決定できます。
マージは、(ヒストリーが現行ブランチから分岐して以降の) 名前付きコミットの変更を現行ブランチに取り込みます。
マージは、以下の 2 つの場所からトリガーできます。
パッケージ・エクスプローラーまたはナビゲーターで、プロジェクト・ノードのコンテキスト・メニューを開きます。 「Team」>「Merge...」と選択します。
マージ・ダイアログが開きます。
ダイアログで、現行ブランチとマージするブランチまたはタグを選択します。
マージは、任意のブランチおよびタグのノード、およびローカル・ブランチをチェックアウトした場合にはリポジトリー・ノードからトリガーできます。詳しくは、ブランチまたはタグのマージを参照してください。
「Merge」ボタンを押すと、以下のシナリオが考えられます。
マージの結果は次のダイアログに要約されます。
最初の行には、マージの結果が示されます。「Already-up-to-date」、「Fast-forward」、「Merged」、「Conflicting」、「Failed」のいずれかの結果になります。「Failed」の理由としては、作業ディレクトリー内の変更が競合している可能性があります。
2 行目には、マージが成功した場合 (Already-up-to-date、Fast-forward、または Merged) には新しい HEAD コミットが表示されます。
表には、マージされたコミットが表示されます。
マージを行うと、ユーザー処置が必要な競合が発生する可能性があります。ファイル内容を自動的にマージできない場合です。これらの競合には、ナビゲーション・ツリー内でラベル装飾によりマークが付けられます。ファイル内容におけるマージ競合には、テキスト競合マーカーが表示されます (詳しくは、http://www.kernel.org/pub/software/scm/git/docs/git-merge.html#_how_conflicts_are_presented を参照してください)。
競合を解決するには、以下の手順を実行する必要があります。
競合ファイルを含むリポジトリーには、リポジトリー名にテキスト・ラベル装飾機能の「|Conflicts」が付加されます。競合リソースと、そうした競合リソースを含むフォルダーには、競合ラベル装飾が付加されます。
ファイル内容で、変更の競合が生じているペア部分が、<<<<<<<、=======、および >>>>>>> というマーカーでマークされます。通常、======= の前の部分は自分のもので、その後の部分は通常、他のユーザーのものです (詳細は、http://www.kernel.org/pub/software/scm/git/docs/git-merge.html#_how_conflicts_are_presented を参照してください)。
エディターでファイルを開き、内容を編集してエディターを保存します。
この手順は必須ではありません。EGit は、競合が解決されたかどうかを判断するために内容のチェックは行いません。次も関連する手順です。
ファイルの編集が終わったら、「Team」>「Add」と選択して競合解決を Git 索引に追加します。1 つのフォルダーで実行することも、またはプロジェクト全体で実行して、一度にすべての競合を解決することもできます。
すべての競合を解決すると、テキスト・リポジトリー・ラベル装飾が「Merged」に変わります。これで、競合マーカーはすべて消えました。
リポジトリーの状態が「Merged」(リポジトリー名にテキスト・ラベル装飾子「|Conflicts」が付加されて示されます) になると、最終的にマージをコミットできます。
ナビゲーション・ツリーの任意の場所で「Team」>「Commit...」と選択します。通常のコミットと比べて外観がやや異なるコミット・ダイアログが開きます。
「Commit」ボタンを押すと、マージか完了します。
マージによって競合が生じる場合、現行ブランチに対するハード・リセットを使用してマージを中止できます。これは、状態が「Conflicts」および「Merged」のときに、つまり、競合を解決する前と後に行えます。
ハード・リセットは、「Team」メニュー、Git リポジトリー・ビュー、またはヒストリー・ビューから行えます。詳細については、すべてのローカルおよびステージング済みの変更を戻すを参照してください。
リベースでは、特定のコミットにコミットのチェーンを適用します。ある時点で「マスター」ブランチから作成された「トピック」ブランチでいくつかのフィーチャーを開発するというのが一般的なシナリオです。例えば、「トピック」がまだ開発中である間に他の開発者の変更によって「マスター」が更新される場合、こうした変更を「トピック」に取り込むことが必要になることがあります。
それでは、マスターから「トピック」ブランチを作成して「トピック」上で開発を始めることにしましょう。この時点では、「マスター」と「トピック」の両方がコミット「E」を指しています。最初のコミット (「A」) が「トピック」に追加されると、リポジトリーのコミット・ヒストリーは次のようになります。
A topic
/
D---E master
ここで、「トピック」と「マスター」にそれぞれいくつかの追加コミットがあるとします (例えば、「マスター」はリモート・リポジトリーをいくつか追跡し、「マスター」にプルされたそのリモート・リポジトリーに変更がいくつか含まれている場合などがあります)。
A---B---C topic
/
D---E---F---G master
次に、「マスター」にある変更を「トピック」に取り込むため、「マスター」に関する「トピック」のリベースを行います。
A'--B'--C' topic
/
D---E---F---G master
技術的には、「マスター」にではなく「トピック」に含まれるコミットの順序が 1 つずつ「マスター」の上に適用されます (つまり、チェリーピックされます)。
コミット A、B、C は失われることも変更されることもありません。代わりに、元のコミットと同じ変更とコミット・メッセージが含まれる新しいコミット・チェーン A'、B'、C' が作成されます (ただし、コミット ID は異なります)。古いコミット A、B、C はオブジェクト・データベースに存在しますが、どのブランチからもアクセスできないので表示されません。A'、B'、C' には、変更 F と G も含まれるようになったので古いものとは異なります。
簡単な例について考えてみましょう。次のような内容が最初に含まれている「FamousWords.txt」というテキスト・ファイルがあります。
Chapter 1 Once upon a time... Chapter 2 To be or not to be
ここで「トピック」で 2 つのコミットが作成されます。最初のコミットでは Chapter 2 にフランス語の翻訳が追加され、2 番目のコミットではドイツ語の翻訳が追加されます。
「トピック」の最初の変更後は次のようになります。
Chapter 1 Once upon a time... Chapter 2 To be or not to be Être ou ne pas être
「トピック」の 2 番目の変更後は次のようになります。
Chapter 1 Once upon a time... Chapter 2 To be or not to be Être ou ne pas être Sein oder nicht sein
同時に、「マスター」では Chapter 1 にフランス語とドイツ語の翻訳が加わった 2 つのコミットが追加されてファイルが変更されました。
Chapter 1 Once upon a time... Il était une fois Es war einmal Chapter 2 To be or not to be
コミット・ヒストリーは以下のようになります。
この段階で「トピック」を「マスター」にリベースすると、トピック内の 2 つの変更が、「トピック」の進展時に適用されたのと同じ順序で適用されます。
マージされたバージョンの「FamousWords.txt」の結果は次のようになります。
Chapter 1 Once upon a time... Il était une fois Es war einmal Chapter 2 To be or not to be Être ou ne pas être Sein oder nicht sein
また、現行の「マスター」における「トピック」のコミット・ヒストリーを含むコミット・ヒストリーは次のようになります。
この時点まででは、「トピック」内の変更は「マスター」に自動的にマージされると想定しました。ただし現実には、リベース時に競合が生じることがあります。そこで、チェリーピックするコミットに「マスター」内の変更と競合する変更が含まれていると、リベース操作は、競合する変更を適用すると中断されます。競合は通常の手段 (競合マーカー) で視覚化され、ユーザーは次のいずれかを行うように選択できます。
「Resolve Conflicts」を選択し、競合を手動で解決した場合、変更を「追加」しなければなりません。その後、リベースを再開できます。つまり、チェーン内の次のコミットが適用されます。
「Skip」を選択すると、競合する変更は元に戻されて、チェーン内の次のコミットが適用されます。
「Abort」を選択すると、リベース操作は完全にロールバックされます。リベースが開始される前の元の状態にリポジトリーが戻ります。 このプロセスは、最後のコミットが正常に適用されるかスキップされるまで繰り返されます。最終的に「トピック」ブランチは、最後のコミットを指すように変更されます。
「Skip」についてより深く理解するため、前述の概要部分に戻りましょう。コミット「B」によって現行「マスター」と競合がいくつか生じる場合、ユーザーは「B」を単にスキップすることにする場合があります。その場合、リベース後の新しいコミット・ヒストリーは次のようになります。
A'--C' topic
/
D---E---F---G master
リベースは、Git リポジトリー・ビューで利用できます。リポジトリー・ノードで、「Rebase...」を選択すると、チェックアウトしていないブランチを選択するようにユーザーに求めるダイアログが開きます。現在チェックアウトされているブランチが、選択済みブランチにリベースされます。ブランチ・ノード (ローカル・トラッキング・ブランチおよびリモート・トラッキング・ブランチの両方。ただし、現在チェックアウトされていないブランチ) で、「Rebase」を選択すると、現在チェックアウトされているブランチが、選択済みブランチにすぐにリベースされます。
リベースが成功した場合は、確認ダイアログが表示されます。このダイアログはチェック・ボックスにチェック・マークを付けると表示されないようにできます。Git 設定ページを使用すると、このダイアログを再度表示できます。このダイアログが表示されない場合、代わりに「情報」メッセージが Eclipse ログに書き込まれます。
リベース中に競合が発生すると、競合の原因となったコミットに関する情報がダイアログに表示されます。ラジオ・ボタンを選択すると、次のどの操作を実行するかを選択できます。
ダイアログで「スキップ」または「中止」を選択したのではない場合には、競合しているファイルを手動で編集して競合を解決する必要があります。編集完了時には、ファイルを索引に「追加」することによって、それらを解決済みとして宣言する必要があります。
すべての競合が解決したら、Git リポジトリー・ビューでリポジトリー・ノードを右クリックし、「Rebase」>「Continue」と選択してリベースを再開できます。
「スキップ」と「中止」のオプションも Git リポジトリー・ビューから使用できます。その場合には、リポジトリー・ノードを右クリックして、「Rebase」>「Skip」または「Rebase」>「Abort」とそれぞれ選択できます。
またマージ・ツールは、「Team」メニューで対応する項目を使用して開始することもできます。
リポジトリーが「Rebasing」状態にある限り、ユーザーは Git リポジトリー・ビューのリポジトリー・ノードで「Rebase」>「Abort」メニュー・アクションを使用してリベースをいつでも中止できます。
現在 EGit で実装されているリベースでは、利用可能なすべてのバージョンのグラフを処理することはできません。グラフが複雑すぎる場合、リベースは中止され、エラー・メッセージが表示されます。こうしたより複雑なグラフが EGit のリベースでサポートされるまでの回避策として、代わりにコマンド・ラインからネイティブ Git を使用できます。
stable-1.0 ブランチのコミット C に、master ブランチ上の現在の開発に取り込みたい一連の変更が含まれているとします。
A--B--C--D stable-1.0
/
D---E---F---G master HEAD
コミット C をチェリーピックして、現在チェックアウトされている「master」ブランチの HEAD コミットの上に新しいコミット C' を作成します。 すると、C' には、C で実行された変更が含まれるようになり、現在チェックアウトされている master ブランチの HEAD 上に適用されます。
A--B--C--D stable-1.0
/
D---E---F---G--C' master HEAD
現在、「feature2" (HEAD)」ブランチで作業しているとします。別のブランチにコミット「feature 1」があります。
コミット「feature 1」で実行した変更を、「feature 2」ブランチの現行開発に取り込みたいとします。
タグは、ヒストリー・ビューでも作成できます。コミットを選択して、コンテキスト・メニューで「Create Tag...」を実行します。選択したコミット上にタグが作成されます。
間違ったコミットにタグを作成したり、何らかのタイプミスがあったりした場合にはどうしたらいいでしょうか?
古いタグをまだプッシュしていない場合、以下の方法で修正できます。
タグを削除するには、削除するタグを選択して「Delete Tag」をクリックします。
注: パブリック・サーバーで既に公開されているタグを削除することは望ましくありません。一部の Git サーバーでは、通常はタグ付けされているリリースのトレーサビリティーを確保するためにタグの削除が禁止されています。タグ・コマンドの Git リファレンス資料の『On re-tagging』セクションも参照してください。
軽量タグは、リポジトリー・ビューとタグ作成ダイアログに表示されますが、編集はできません。 タグは、リポジトリー・ビューでは青色のアイコンで、注釈付きタグは黄色の人物がついています。
ヒストリー・ビューでは、タグは黄色のラベルで表示されます。
署名付きタグは EGit ではまだサポートされていないので、代わりにコマンド行の git tag または git tag -s を使用してください。
パッチとは、問題を修正したり、コンピューター・プログラムやそのサポート・データを更新したりするためのソフトウェア断片のことです (wikipedia)。パッチ・ファイルには、別の Eclipse ワークスペースまたは Git リポジトリーに自動的に適用できる一連のリソース変更の説明が含まれています。
Eclipse で使用されるパッチ・フォーマット (「Team」>「Apply Patch」) と Git で使用されるフォーマット (コマンド行の git apply または git am) は異なります。EGit では両方のタイプのパッチを作成できます。
これは、分散バージョン管理システムで最も一般的なユース・ケースです。開発者がローカル・フィーチャーまたはバグ修正ブランチで変更をコミットし、この変更をパッチ・ファイルにエクスポートする必要があるとします。
ヒストリー・ビューから次のように行えます。
パッチ・ファイルには、ヒストリー・ビューのコミットとその親の間の差異が含まれています。ヒストリー・ビューのフィルターがパッチ作成にも適用されることに注意してください。
このウィザードは 2 ページで構成されています。1 ページ目では、パッチの場所を選択します。
パッチ・ファイルの名前は、コミット・メッセージの最初の行に基づいて作成されます。
2 ページ目では、パッチ・フォーマットを変更できます。
現時点では、「Export in git patch format」という 1 つのチェック・ボックスが表示されます。
現時点では、バイナリーの差分は生成されません。
現在、EGit では Git フォーマットのパッチを適用できません。「Team」>「Apply Patch...」を使用して、標準の Eclipse (Unified 差分) フォーマットでパッチを適用できます。Git パッチには、名前変更およびバイナリーの差分に関する非標準の拡張が含まれている場合があります。現行バージョンの EGit ではこうした拡張を生成できません。
「Git リポジトリー・ビュー」は複数のリポジトリーを同時に簡単に扱えるようにするための 1 次 UI エレメントです (つまり、1 つの Eclipse ワークスペース内で作業できます)。
このビューは、次のメニュー・パスを使用して開くことができます。
「Windows」>「Show View」>「Other...」>「Git」>「Git Repositories」
また、次のメニュー・パスで使用できる「Git Repository Exploring」パースペクティブの一部でもあります。
「Window」>「Open Perspective」>「Other...」>「Git Repository Exploring」
Git リポジトリーと共有しているプロジェクトがワークスペース内に既にある場合、任意のリソースで
「Team」>「Show in Repositories View」
と選択してビューを開くこともできます。
Git リポジトリー・ビューは最初は空です。リポジトリーをこのビューに追加するには、いくつかのオプションがあります。
ローカル・ファイル・システムのリポジトリーを、クローン作成しないで Git リポジトリー・ビューに追加できます。これは、新規 Eclipse ワークスペースをセットアップしていて、Git リポジトリーを再利用する場合に役立ちます。ビューのツールバーにある 「Add an existing Git Repository」ボタンを使用します。
ローカル・ファイル・システムのディレクトリーを確認するプロンプトのダイアログが表示されます。正しいディレクトリーを選択した後、「Search」ボタンを押すと、このディレクトリー内の Git リポジトリーのリストを表示できます。その後、検出されたリポジトリーの一部またはすべてを選択し、「OK」を使用してそれらをビューに追加できます。
リポジトリーをクローン作成するには、リモート・リポジトリーのクローン作成を参照してください。クローンが正常に作成されると、新しくクローン作成されたリポジトリーが Git リポジトリー・ビューに自動的に表示されます。
また、ビューのツールバーにある「Clone a Git Repository」ボタンを使用して、クローン作成ウィザードを開始することもできます。
このウィザードの使用方法については、リモート・リポジトリーのクローン作成を参照してください。
ローカル・ファイル・システム上に空の新規リポジトリーを作成できます。これは、後でこのリポジトリーの下に 1 つ以上の新しいプロジェクトを作成する場合に便利です。もう 1 つのユース・ケースは、プッシュ先の新しいベア・リポジトリーを作成する場合です。ビューのツールバーにある「Create a new Git Repository」ボタンを使用します。
ディレクトリーを選択するためのダイアログが表示されます。
「Create as Bare Repository」チェック・ボックスを選択すると、新しいリポジトリーは作業ディレクトリーを持ちません。そのため、別のリポジトリーからの変更をプッシュすることによってのみコンテンツを追加できます。
ショートカットとして、クリップボードにある Git リポジトリーのローカル・ファイル・システム・パスをこのビューに貼り付けることもできます。そのためには、Git リポジトリーのパス (.git フォルダーの絶対パス) をクリップボードにコピーしてから、ビュー・パネルのコンテキスト・メニューを開きます。
またはメインメニューの「Edit」>「Paste」をクリックします (または対応するキーボード・ショートカットを使用します)。クリップボードの内容が適切でない場合、エラー・ポップアップが表示されます。それ以外の場合は、追加されたリポジトリーが自動的に表示されます。
ビューにいくつかのリポジトリーが取り込まれると、次のようになります。
リポジトリー・ビューからリポジトリーを除去するには、リポジトリーを選択して「Remove Repository」をクリックします。
リポジトリーを削除するには、リポジトリー・ビューでリポジトリーを選択し、「Delete Repository」をクリックします。
次に、リポジトリーを削除することを確認します。
さらに、Eclipse ワークスペースからそのリポジトリーに含まれるプロジェクトを削除するかどうかを決定します。
以下のスクリーン・ショットは、Git リポジトリー・ビューの最上位の 2 つのレベルを示しています。
ルート・ノードはそのリポジトリー自体を表します。ノード・テキストは、リポジトリーの名前と、ローカル・ファイル・システムにおけるその場所を示します。「Branches」ノードと「Tags」ノードでは、タグとブランチの参照および操作を行えます。「References」ノードはブランチでもタグでもない他の参照をリストします。その中で特に注目できるのは「HEAD」と「FETCH_HEAD」のシンボリック参照です (Git 参照をご覧ください)。
「Working Directory」ノードには、ローカル・ファイル・システム上の作業ディレクトリーの場所と構造が示されます (開発、または非ベア・リポジトリーの場合にのみ当てはまります。ベア・リポジトリーの場合、このノードは必ずリーフです)。
最後に、「Remotes」ノードは、取り出しとプッシュに使用されるリモート構成の参照および操作を行えます。
Git リポジトリーのコンテンツを扱うには、そのファイルとフォルダーをプロジェクトの形式で Eclipse ワークスペースにインポートする必要があります。Git クローン作成ウィザードを使用するとクローン作成後にそのようなインポートを直接行うことができ、Git リポジトリー・ビューではクローン作成操作とは別個にプロジェクトのインポートをトリガーできます。
「Import Projects...」コンテキスト・メニューは、リポジトリー・ノード、作業ディレクトリー・ノードのフォルダー・ノード、作業ディレクトリー・ノード自体で使用できます。
いくつかのノードで「Import Projects...」アクションが提供されるのは、「Import Existing Projects」ウィザードなど一部のプロジェクトをインポートするためのウィザードでは、ファイル・システム・ディレクトリーが考慮されることがあるためです。インポートがリポジトリー・ノードまたは作業ディレクトリー・ノードから開始される場合、そのリポジトリーの作業ディレクトリーがコンテキストとして設定され、その他の場合には、現在選択されているフォルダー・ノードに対応するディレクトリーが設定されます。
プロジェクトのインポートについて詳しくは、Use the New Projects Wizard で取り上げられています。
「Branches」ノードを使用すると、ローカル・ブランチとリモート・ブランチの作成、参照、チェックアウト、削除を行えます。「Tags」ノードを使用すると、タグの参照とチェックアウトを行えます。「Branches」ノードと「Tags」ノードの両方で、現在チェックアウトされているブランチへのブランチまたはタグのマージ、および現在チェックアウトされているブランチとの同期を行えます。
見やすくするために「branches」はローカル・ブランチとリモート・ブランチの 2 つのサブノードに編成され、それぞれ短縮名のみが表示されています。例えば、「Local Branches」ノードの下には "refs/heads/master" ではなく "master" という項目が、また「Remote Branches」ノードの下には "refs/remotes/origin/master" ではなく短縮名 "origin/master" がそれぞれ表示されています。同様に、タグ名に関しても "refs/tags/" 接頭部が省略されて短縮されています。
ブランチとタグをチェックアウトする場合、それぞれのノードをダブルクリックするか、対応するコンテキスト・メニュー項目を選択します。
ローカル・ブランチは、ブランチ作成ダイアログを使用して作成できます。このウィザードを開くには、「Branches」、「Local Branches」(任意のブランチ・ノードおよびタグ・ノード上) を右クリックします。
ブランチの削除は、対応するコンテキスト・メニュー項目を使用して行います。
現在チェックアウトされているブランチを別のブランチにリベースするには、任意の (ローカル・トラッキングまたはリモート・トラッキング) ブランチ・ノード上で右クリックして「Rebase」を選択します。
マージは、任意のブランチおよびタグのノード、およびローカル・ブランチをチェックアウトした場合にはリポジトリー・ノードからトリガーできます。マージ・フィーチャーの詳細については、 マージを参照してください。
HEAD 内の変更を他の任意のブランチまたはタグで行われた変更と比較できます。任意のブランチまたはタグを右クリックして、「Synchronize...」を選択します。その後、Eclipse 同期ビューが表示され、HEAD に含まれるものの、他のブランチまたはタグに含まれない変更 (発信変更) またはその逆 (着信変更) が示されます。詳しくは、同期フィーチャーに関する資料を参照してください。
現在チェックアウトされているブランチまたはタグを判別するには、次の 2 つの方法があります。チェックアウトされているブランチ/タグ・ノードは小さなチェック・マークがついています。また、「Symbolic References」ノードの下にある「HEAD」項目にはチェックアウトされているブランチの完全な名前が表示されます。
任意のブランチまたはタグを右クリックして「Reset...」を選択します。これにより、リセットのタイプを決定するダイアログが開きます。詳しくは、現行 HEAD のリセットを参照してください。
HEAD が「デタッチされる (detached)」場合、つまり、ローカル・ブランチの先端を指しておらず、コミットまたはタグを指している場合、ツリーに表示される「チェックアウト済み」マーカーがまったくないか、少ないことがあります。任意の数のリモートのブランチまたはタグが現在チェックアウトされているコミットを指している可能性があるためです。HEAD がデタッチされているときにこの状態になる場合、どのブランチでも記録されません (どのブランチ上にもいないため、これは当然です)。
「References」ノードには、ブランチやタグ以外の他の参照が表示されます (リストは動的で、リポジトリーの現在の状態によって異なります)。
参照がシンボリックである場合、つまり、別の参照を指している場合、ターゲット参照の名前、それに続いて参照のターゲットのオブジェクト ID が示されます。参照がシンボリックではない場合には、オブジェクト ID のみが表示されます。
上の例では、HEAD はブランチ「refs/heads/master」を指しているシンボリック参照です (「master」ブランチはチェックアウトされていて、FETCH_HEAD は次のコミットを直接指しています: 226a7f...)。
参照を右クリックすると、以下のアクションを使用できます: 「Checkout」(参照がチェックアウトされていない場合)、および「Create Branch...」。
「Working Directory」ノードは、Git リポジトリーのローカル・ファイル・システム構造を視覚化します。また、ファイルをテキスト・エディターで開くこともできます。
あるいは、作業ディレクトリーのファイルをエディター領域にドラッグしてもファイルを開くことできます。
または、すべてのファイル、フォルダー、リポジトリーのノードで、クリップボードに (ファイル・システム固有の) パスをコピーするオプションも提供されます。これは、ファイル・ブラウザーを使用してディレクトリーを開いたり、ビュー・インスタンス間でリポジトリーをコピー・アンド・ペーストしたりする (前述のビューへのリポジトリーの追加方法を参照) など、パスが必要になるときに役立つことがあります。「Copy to Clipboard」アクションは、「Edit」>「Copy」(または対応するキーボード・ショートカット) によっても使用できます。
Eclipse の汎用の「Properties」ビューとの統合により、Git 構成を表示および編集できます (グローバルとリポジトリー固有の構成)。「Properties」ビューが開いている場合には、リポジトリー・ノードが選択されるときに自動的に更新されます。ドロップダウン・ボックス (スクリーン・ショットの左側にある赤いボックス) を使用すると、リポジトリー構成、グローバル構成、および両方をまとめたビューの表示を切り替えることできます。ビューにリポジトリー構成またはグローバル構成が表示されている場合、「Edit」ボタン (スクリーン・ショットの右側にある赤いボックス) があるエディター・ダイアログを開くことができます。エディター・ダイアログには、「Preference」ページの「Team」>「Git」>「Configuration」と同じ機能があります。
Git リポジトリー・ビューのコンテキスト・メニューには「Properties」アクションがあります。これにより、リポジトリー構成を編集できる構成ダイアログが開きます。このダイアログでは、キーと値のペアの追加、変更、または削除を行えます。「Open」ボタンを使用すると、テキスト・エディターでリポジトリー構成ファイルを開くことができます。
「Remotes」ノードを使用すると、リモート構成の参照および編集を行えます。各リモート構成には、名前と、プッシュ仕様または取り出し仕様 (あるいはその両方) があります。リモート構成ノードまたはその子を選択すると、「Properties」ビューにリモート構成の要約が表示されます。この例では、「origin」という名前のリモート構成があり、プッシュ仕様はなく、取り出し仕様のみが含まれています。
リモート構成、取り出しとプッシュの仕様を追加、構成、除去するためのメニュー・アクションが提供されます。
取り出しノードおよびプッシュ・ノードではそれぞれ、取り出しまたはプッシュを直接 (つまりウィザードを使用することなく) 行うことができます。
非同期ジョブでは取り出しまたはプッシュの操作はすぐに実行されます。完了すると、取り出し結果を示す確認のポップアップが表示されます。
取り出しノードにはいわゆる取り出し仕様が含まれ、プッシュ・ノードにはプッシュ仕様が含まれます。
リポジトリーをクローン作成すると、デフォルトの取り出し仕様が作成されます。「Configure Fetch...」メニュー項目を使用すると、取り出し仕様を編集できます。これでウィザードが開きます。最初のページでは、取り出し URI を編集できます。2 番目のページでは、取り出し参照仕様を決定できます。取り出し参照仕様を参照してください。
「Configure Push...」メニュー項目を使用して、プッシュ仕様を作成または編集できます。これでウィザードが開きます。最初のページで、プッシュ URI を編集できます。取り出しが指定されると、取り出し URI がプッシュ仕様に自動的に組み込まれるので、プッシュ URI を追加する必要はありません。2 番目のページで、プッシュ参照仕様を決定できます。プッシュ参照仕様を参照してください。
これは、「Remotes」ノードのコンテキスト・メニュー・アクションを使用して実行できます。ウィザードが開始され、新しい構成の名前、および取り出し、プッシュ、またはその両方を構成するかどうかが尋ねられます。
「Configure Fetch」チェック・ボックスを選択した場合、ウィザードの次のページで、取り出し元のリポジトリーの URI が尋ねられます。
「Change...」をクリックすると、URI を選択できるダイアログが表示されます。次の手順では、取り出し URI のリモート仕様を定義します。詳しくは、取り出し参照仕様を参照してください。
「Configure Push」チェック・ボックスを選択すると、ウィザードの次のページでは、プッシュ先のリポジトリーの URI が尋ねられます。これは実際にはリストで、複数のリポジトリーを一度にプッシュできます。「Add....」をクリックして、上と同じダイアログを使用して URI をリストに追加します。リストで URI にマークを付けて、「Remove」を押すと、URI を除去できます。既に取り出し URI が定義されている場合、この手順は完全にオプションです。その場合には、取り出し URI がプッシュにも使用されます。この手順では少なくとも 1 つのプッシュ URI が定義されていると、取り出し URI がそれによりオーバーライドされます。この例では、取り出し URI が既にあるので、リストにプッシュ URI がない場合であっても、「Next」ボタンが有効です。
次の手順では、プッシュ URI のリモート仕様を定義します。詳しくは、プッシュ参照仕様を参照してください。
完了すると、新しいリモート構成が表示されます。
コンテキスト・メニューを使用すると、既存のリモート構成の取り出し/プッシュの仕様を追加、削除、または変更することもできます。
Gerrit Code Review をリモート・リポジトリー・サーバーとして使用して作業している場合、以下を行うことができます。
リモートのコンテキスト・メニューで「Gerrit Configuration...」を選択します。これにより、1 ページで構成されるウィザードが開きます。
ビューは定期的に自動更新されます。ツールバーの「Refresh」ボタンを使用すると、すぐに更新できます。
「Link with selection」トグルが有効になっている場合、現在のワークベンチ選択に対応するファイルまたはフォルダーが自動的に表示されます。
「Link with editor」トグルが有効な場合、現在アクティブなエディターに対応するファイルまたはフォルダーが自動的に表示されます。
「Hierarchical Branch Layout」トグルが有効な場合、ブランチは、階層分離文字としてスラッシュ (/) を使用して階層型レイアウトで表示されます。
これは、多数のブランチを編成するときに役立ちます。
「ベア」Git リポジトリー (開発リポジトリーや標準リポジトリーと対称的) には定義上、作業ディレクトリーはありません。そのため、作業ディレクトリーに関連するすべてのアクション (チェックアウト、プロジェクトのインポート、作業ディレクトリーの参照) はこの種のリポジトリーでは使用できません。リポジトリーの「ベア (むき出し)」具合は作業ディレクトリー・ノードで表れ、常にリーフです。
ベア・リポジトリーを変更する唯一の方法は、変更をプッシュすることです。
リポジトリー・ノードのアクション・メニューとしてこの操作を行えます。これより、リポジトリーは削除されるわけではなく、ビューからこのノードが除去されるに過ぎません。リポジトリーの作業ディレクトリーにあるワークスペースにプロジェクトが含まれる場合、これらのプロジェクトを Eclipse ワークスペースから削除するかどうかを確認するプロンプトがユーザーに出されます。
「Show in」>「History」コマンドを使用すると、選択したリポジトリーにある変更すべてが示されているヒストリー・ビューが開きます。
「Show in」>「Reflog」コマンドを使用すると、選択したリポジトリーの Git Reflog が示されている Git Reflog ビューが開きます。
「Show in」>「Properties」コマンドを使用すると、選択したリポジトリーのプロパティーが示されているプロパティー・ビューが開きます。
EGit 0.11 以降、タスク・リポジトリーの処理をサポートするために Mylyn との最初の統合を利用できるようになりました。
EGit Mylyn 統合を使用するには、「EGit Mylyn」フィーチャーをインストールする必要があります。Mylyn をインストールすることも必要です。
タスクの処理方法について詳しくは、Mylyn User Guide を参照してください。
Egit コミット・ビューアーを使用すると、Eclipse エディター領域でコミットを開くことができます。
EGit コミット・ビューアーには、次のコミット情報が表示されます。
コミット・ビューアーに表示されているコミットがチェックアウトされます。コミットはチェックアウトされ、HEAD がデタッチ状態になります。
現在チェックアウトされているコミットまたはブランチの上に、コミット・ビューアーで表示されているコミットによって導入された変更が適用されます。
コミット・ビューアーは以下の場所から開くことができます。
EGit は、コミットの検索をサポートしています。
コミットは、標準の Eclipse 検索ダイアログの「Git Search」タブから検索できます。
このダイアログでは、Git コミットの別のフィールド (例えば、コミットのメッセージ、作成者行、コミッター行、SHA-1 ID、その親、および関連付けられているツリーなど) にあるテキストまたはパターンの検索をサポートしています。
コミット検索の結果は、標準の Eclipse 「Search」ビューに表示されます。結果は、ツリー・モードの場合にはリポジトリーごとにグループ化されます。「Search」ビューでコミットをダブルクリックすると、 コミット・ビューアーで開かれます。
「Git Search」ページは、Eclipse ツールバーにある「Search」ドロップダウンから「Git Search」オプションを選択すると開くことができます。
EGit 1.0 には「Open Git Commit」というダイアログがあり、これは Mylyn の「Open Task」や主要な「Open Resource」ダイアログに似ています。このダイアログは、フィルター・ボックスに入力されたブランチ、タグ、またはコミットの SHA-1 をすべての構成済み Git リポジトリーで検索し、一致するコミットを表示します。
このダイアログを開くには、Eclipse ナビゲーション・ツールバーにある「Open Git Commit」ボタンを選択します。
EGit 1.0 では、エディター・ルーラー内で git blame 情報を表示できます。
ファイル選択で「Team」>「Show Annotations」アクションを選択するとエディターが開き、ファイルの各行に関するコミットと作成者情報が含まれる注釈ルーラーが表示されます。ルーラーにマウスを合わせると、コミット ID、作成者、コミッター、コミット・メッセージが記されたポップアップが表示されます。
blame 注釈エディター・ルーラーの外観は、ルーラーのコンテキスト・メニューで使用できる「Revisions」サブメニューから構成できます。
ポップアップで SHA-1 ハイパーリンクを選択すると、コミット・ビューアーでコミットが開きます。
EGit/JGit におけるサブモジュールのサポートは、2011 年 2 月に Indigo SR2 の一部であるリリース 1.3 で追加されました。
Git サブモジュールと、その仕組みについて詳しくは、こちらの Git Community Book の章を参照してください。
サブモジュールは、親リポジトリー内にネストされているリポジトリーです。そのため、親リポジトリーのクローンを作成する場合は、サブモジュール・リポジトリーを複製して、親リポジトリーの作業ディレクトリーでファイル/フォルダーを使用できるようにする必要があります。
Git クローン作成ウィザードの「Clone Submodules」ボックスにチェック・マークを付けると、親リポジトリーのクローン作成が終了後、すべてのサブモジュール・リポジトリーがクローン作成されます。
サブモジュールが含まれるリポジトリーの「Git Repositories」ビューには「Submodules」 ノードが 1 つ表示されます。
このノードの下には、指定された親リポジトリーのサブモジュールすべてと、現在チェックアウトされているコミットに関する情報が表示されます。
新規サブモジュールをリポジトリーに追加するには、「Git Repositories」ビューでリポジトリーを選択し、「Add Submodule」 コンテキスト・メニュー・オプションを選択します。
ウィザードにより、追加するサブモジュールのパスと URL の入力を求めるプロンプトが表示されます。入力するパスは親リポジトリーの作業ディレクトリーと URL に相対的で、リポジトリーをローカルで複製するときに使用されます。
ウィザードが完了すると、サブモジュールが複製され、索引に追加されます。またサブモジュールが、.gitmodules ファイルおよび親リポジトリーの .git/config ファイルに登録されます。
サブモジュールの更新に使用できるアクションは、「Update Submodule」 と「Sync Submodule」 の 2 つです。
サブモジュールで「Update Submodule」 アクションを選択すると、そのサブモジュールの親リポジトリーの索引で参照されるコミットがチェックアウトされます。このコマンドは、親リポジトリーの .git/config ファイルで選択されているサブモジュールの構成セクションの「update」 フィールドで構成されている場合には、マージまたはリベースも実行します。
サブモジュールで「Sync Submodule」 アクションを選択すると、親リポジトリーの作業ディレクトリーのルートにある .gitmodules ファイルの現在値に基づいて、サブモジュールで使用されるリモート URL が更新されます。
|
|
|
|
| 概念 | 参照 |