EGit/User ガイド

開始

概要

Gitあるいは一般的な分散バージョンコントロールシステムが初めてであれば、まずGit for Eclipse Users を読んだほうが良いかも知れません。もっと詳しい背景および詳細はオンラインの Pro Gitで見つけることができます。

CSVから来た場合は、Git Platform-releng/Git Workflowsのための一般的なCSVワークフローを見つけることができます。

基本チュートリアル: バージョンコントロールにプロジェクトを追加

設定

自己証明

リポジトリの履歴が変わる時はいつでも(技術的にはコミットが作成される時はいつでも)、Gitはコミットを作成したユーザを追跡します。 識別は名前(主に人の名前)およびメールアドレスから成ります。情報は専用のキーの下のファイル ~/.gitconfig に格納されます。

EGit はあなたが始めてコミットを作成した時にこの情報をたずねるでしょう。 デフォルトでは、このダイアログは新しいワークスペース、あるいはGitプリファレンスページの"Show initial configuration dialog"チェックボックスにチェックマークを付けるまで、一度しか表示されません。

後でまた見たい場合には、"Don't show this dialog again" のチェックマークを外すこともできます。

このダイアログを使う代わりに、いつでもGit設定を使ってこの情報を変更することができます。

• Preferences > Team > Git > Configuration をクリック
• New Entry をクリックし、user.email およびuser.name のキーの値のペアを入力します
  

Windows上にホームディレクトリをセットアップ

環境変数にHOME環境変数を追加します。

1. Windows 7では、スタートメニューで"environment" をタイプします。
2. "Edit environment variables for your account" を選択します。
3. "New" ボタンをクリックします。
4. 名前欄に "HOME" を入力します。
5. 値欄に、"%USERPROFILE%" あるいはその他のパスを入力します。
6. OKをクリックし、さらにOKします。これでWindowsにホームディレクトリが追加されました。
   

Cygwinを使う場合は、既にHOMEが設定されている筈です。例えば、Cygwin を C:\cygwin にインストールし、あなたの名前が Fred の場合は、Cygwinは既に HOME を C:\cygwin\home\Fred (あるいはそのようなもの)に設定しているはずです。Windowsコマンドプロンプトでecho %HOME%あるいは、Cygwinシェルでecho $HOMEを入力することで、これを確認することができます。

EGit はユーザ設定(.gitconfig)を探すためにこのパスを必要とします。HOME はホームディレクトリを指していなければなりません。例えば C:\Users\Tom。大文字小文字を正しくしてください！ 例えば C:\Users の代わりにC:\users とすると問題が起きるでしょう！

HOME 変数が定義されていない場合は、ホームディレクトリはHOMEDRIVE と HOMEPATH を連結して算出されるでしょう。

HOMEとHOMEDRIVEの両方が定義されていない亜倍は、HOMESHARE が使われるでしょう。

もしHOME が明示的に定義されていない場合は、EGitは警告を出すでしょう。Eclipseが動作している間にHOME環境変数を設定した場合は以下の警告がまだ表示されるだろうということに注意してください。EGitがHOME変数を理解するためにEclipseを再起動する必要があるでしょう。

システム全域設定の指定

WindowsでEgitの相手としてGitを使う場合、EgitがどこにGitがインストールされていて"system wide settings"を見つけられるようにする必要があります。例えば、core.autocrlfがどうやって設定されるか。設定に行き、Tamm>Git>Configuration の下を探し、システム設定のタブを探します。

GitをWindowsにインストールするときにコマンドラインプロンプトからGitを使うようにオプションを設定した場合は、system wide settingの場所にはパスが入力されていて、すべてがうまくいくでしょう。そうでなければ、どこにGitがインストールされているかを見つけるためにBrowseボタンを使います。例えば 、C:\Program Files(x86)\Git。

この助言は他のGitパッケージのユーザにも適用されます。例えば CygwinあるいはTortoiseGitの下のGit。

Windowsではないユーザは原理的にはこの設定を調べるべきですが、system wide settnig は通常Windowsでは無いプラットフォームでは使われません。

リポジトリの作成

• 新しいJavaプロジェクト HelloWorld を作成する。(この場合、プロジェクトはEclipse ワークスペースの外に作成されました。)

• プロジェクトを選択し、File > Team > Share Projectをクリックします。
• リポジトリタイプGit を選択し、Nextをクリックします。

• Gitリポジトリを設定するには、新しいプロジェクト HelloWorld を選択します。

• HelloWorldプロジェクトの新しいGitリポジトリを初期化するには、 Create Repository をクリックします。プロジェクトが既に既存のGitリポジトリの作業ツリーの中にある場合は、そのリポジトリは自動的に選択されるでしょう。

• ウィザードを閉じるためにFinish をクリックします。
• プロジェクトの後ろの"[master]"装飾文字はこのぷrジェクトが master ブランチのリポジトリで追跡されていることを示し、疑問符の記号は.classpathと .project と .settings ファイルはまだバージョン管理されていないことを意味します。

変更の追跡

• プロジェクトノードのTeam > Add to Index をクリックします。(このメニュー項目はEgitの古いバージョンでは Add という名前です。)
• + 装飾はこれでプロジェクトのファイルがバージョン管理に追加されたことを意味します。
• "bin"フォルダの上で右クリックしTeam > Ignore を選択するか、プロジェクトフォルダに以下の内容の.gitignoreファイルを作成することで、"bin"フォルダを”Gitから無視される"ように印を付けることができます。

/bin

• Gitの追跡ファイルからbin フォルダを除外します。
• バージョンコントロールに.gitignoreを追加します(Team > Add):

• Package Explorer で.gitignore を表示するためには、Package Explorer filterを設定する必要があるかもしれません。filterにアクセスするには、ビューメニューを表示するために Package Explorer タブの右端の矢印を選択します。

• ビューメニューから Filters... を選択すると、Java Element Filter ダイアログが表示されるでしょう。 . で始まるファイルを表示するには一番上のエントリを非選択にします。(period) such as .gitignore.

• プロジェクトのコンテキストメニューで Team > Commit をクリックします。
• 変更を説明するコミットメッセージを入力し、(空行が続く)最初の行がこのコミットの短い記録になるでしょう。デフォルトではホームディレクトリの.gitconfig ファイルから作者とコミッターが取り出されます。
• Signed-off-by: タグを追加するに、Add Signed-off-by をクリックするかもしれません。
• 他の作者の変更をコミットする場合は、作者の名前とメールアドレスを渡すために作者欄を変更するかも知れません。
• 最初の変更をコミットするにはCommit をクリックします。

• コミットされたファイルの装飾があなたのコミットの結果として変更されたことに注意してください。

履歴の調査

• リソースの履歴を調査するには、コンテキストメニューから Team > Show in Historyをクリックしてください。

• 新しいJavaクラスHello.javaを作成し、実装します。
• バージョン管理に追加し、変更をコミットします。
• 実装を改善し、改善したクラスをコミットします。
• リソース履歴はこれでこのクラスに対して2つのコミットを表示します。

• 履歴ビューの Compare Mode トグルボタンをクリックします。
• 比較ビューで最後にコミットした変更を開くために、履歴ビューのリソースリストの中で src/Hello.javaをダブルクリックします。

おめでとう。Gitを使って初めてのプロジェクトをこれでマスターしました！

GitHub チュートリアル

ローカルリポジトリの作成

• 新しいローカルリポジトリを(デモプロジェクトの代わりにあなたの内容で)作成するために、EGit/User Guide/Getting Started に従ってください。

GitHubでリポジトリを作成

• GitHubで新しいリポジトリを作成します:

次の画面で、新しいリポジトリにアクセスするために使うだろうURLを見ることができます:

• SSH protocolを選択するために SSH をクリックします。読み書きアクセスのために使われます。
• HTTP protocolを選択するために HTTPをクリックします。読み書きアクセスのためにも使われます。
• クローンのために匿名のgit protocolを選択するために Git Read-Onlyをクリックします。それはgitがサポートするもっとも効果的なプロトコルです。git protocol は認証をサポートしないため、公開されたリポジトリへの効果的な読み込み専用アクセスを提供するためによく使われます。

Eclipse SSH 設定

• Eclipse のPreferencesを開き、SSH2ホームが正しく設定され(通常は ~/.sshです)、SSH2キーを含むことを確認します:

• SSHキーをまだ持っていない場合は、このダイアログの2つ目のタブでそれらを作成します(Key Management)。秘密鍵を守るために良いパスフレーズを使用してください。詳しくは "working with key passphrases" を見てください。
• 公開SSHキーを GitHub account settings にアップロードします。

(Puttyの使用あるいはEgitを使うほかのSSHエージェントのような)進化したSSH設定のさらに詳しい情報は、EGit FAQ (section SSH)で利用可能です。

UpstreamのPush

• Team > Remote > Push... をクリックし、新しいGitHubリポジトリのSSH URL をペーストします。
• SSH通信を許可しないファイアウォールの後ろにいる場合は、代わりにGitHup HTTPS URLを使用し、アップロードした公開SSHキーの代わりにGitHubのユーザとパスワードを提供します。証明書をEclipseのsecure store に格納するには、Store in Secure Storeをクリックします。
• 注意:HTTP URLの中にユーザ名が露出することはセキュリティリスクだと考えられるため、 多くのHTTPプロキシはユーザ名を含むHTTP URLをブロックするように設定されています。 そのような場合にはHTTP URLからユーザ名を削除し、ユーザ欄でそれを提供するだけにします。それはHTTPヘッダとして送信されるでしょう。

• Nextをクリックし、最初の接続でGitHubのホストキーを受け入れます。

• SSH keyの passphrase を入力し、OKをクリックします。

• ローカルブランチ名を目的のリポジトリの中のブラン地名と同じ名前に割り当てるために、次のウィザードページで Add all branches specをクリックします(一対一対応)。

• Nextをクリックします。push確認ダイアログは目的のリポジトリにpushされた時に起こる変更のプレビューを表示するでしょう。

• これらの変更をpushしたいかを確認するためにFinishをクリックします。

• 次のダイアログはpush操作の結果を報告します。

• 新しいリポジトリの内容が到達したことを見るために、GitHubのリポジトリに向かいます。

EclipseCon 2012 Git チュートリアル

ここで全ての課題とスライドを見ます。

Gitチュートリアルの準備のために exercise #1 に従います。

概念

Gitは2、3の単純かつとても強力な考えからできています。それらを知ることはgitがどう動くかをもっと理解するのに役立ちます。

リポジトリ

リポジトリあるいはオブジェクトデータベースはプロジェクトの履歴を作る全てのオブジェクトを保持します。 このデータベースの全てのオブジェクトはオブジェクトの安全な20バイトのSHA-1 hashを使って識別されます。これには幾つかの利点があります:

• 二つのオブジェクトの比較は二つのSHA-1ハッシュの比較に要約されます。
• オブジェクトの名前は各gitリポジトリの中で同じ方法でオブジェクトの内容を使って計算されるため、同じオブジェクトはこのオブジェクトを含むことになった全てのリポジトリの中で同じ名前で保持されるでしょう。
• オブジェクトは一度作成されると決して変わりません(内容の変更は新しいハッシュが計算される必要があることを意味し、新しい名前が割り当てられることから明らかです)。
• SHA-1オブジェクト名がオブジェクトの内容の安全なハッシュのままかどうかを調べることで、リポジトリの腐敗を簡単に検知することができます。

Git には4つのオブジェクトの種類があります:

• Blob object はファイルの内容を格納します。
• Tree object はディレクトリの構造を保持し、ファイルシステム名とモードと一緒に Blob objects と他の Tree objects を含みます。
• Commit object はコミットの時点のディレクトリ構造のスナップショットを表し、リポジトリ履歴を形成するリポジトリリビジョンの非循環のグラフを形成する Commit object の子孫へのリンクを持ちます。
• Tag objectはオブジェクトの名前と種類を含む他のリポジトリオブジェクトへのシンボリック名のリンクです。任意で、タグの作成者と他の署名情報についての情報も含みます。

オブジェクトデータベースは .git/objectsディレクトリの中に格納されます。Objects are either stored as loose objects or in a single-file packed format for efficient storage and transport.

Trust

Gitは(信頼できないかもしれない)ソースから取得されたオブジェクトが正しくそれらが生成されてから修正されていないかを検証することができる安全なSHA-1ハッシュを使って組み込みの信頼チェーンを提供します。

If you get the signed tag for e.g. a project release which you can verify with e.g. the tagger's (the project lead's) public signing key, git ensures that the chain of trust covers the following:

• 署名されたタグはコミットオブジェクトを識別します。
• コミットオブジェクトは内容と履歴を含む厳密に一つのプロジェクトリビジョンを表します。
• コミットオブジェクトは、ブロブオブジェクトとプロジェクトリビジョンのディレクトリ構造を表す他のツールオブジェクトを含んでいます。
• ブロブオブジェクトはこのプロジェクトリビジョンのファイルの内容を含んでいます。

全ての関連するオブジェクト名は、プロジェクトのバージョンの正確さと履歴全部が信頼できることを確認するためにSHA-1アルゴリズムを使って、一貫性を調べることができます。

インデックス

Git Index は.git/index ディレクトリの中にある、ファイルの修正を効果的に検知するために使われるファイル名、ファイルモードおよびファイルのメタデータをのソートされたリストを含むバイナリのファイルです。ブロブオブジェクトのSHA-1オブジェクト名も含んでいます。

以下の重要なプロパティを持っています:

• インデックスは一つのユニークに定義されたツリーオブジェクトを生成するために必要な全ての情報を含んでいます。例えば、コミット操作はこのツリーを生成し、それをオブジェクトデータベースに格納し、それをコミットと関連付けます。
• The index enables fast comparison of the tree it defines with the current working directory. これはインデックスデータに必要とされるファイルに関する追加のメタデータを格納することで達成されます。T
• The index can efficiently store information about merge conflicts between the trees involved in the merge so that for each pathname there is enough information about the involved trees to enable a three-way merge.

ブランチ

Gitでのブランチはコミットへの名前付きの参照です。ブランチには二つの種類があります。すなわち"Local"および"Remote Tracking"ブランチは異なる目的に役立ちます。

ローカルブランチ

(ローカル)ブランチへの変更がコミットされる時はいつも新しいコミットオブジェクトが作成されます。Without any other means, it would be very difficult to keep track of the changes in the Repository, in particular when other commits are added to the Repository, for example due to an update from the remote Repository or when checking out another commit.

ローカルブランチは"現在の"コミットを見つけることができる(ローカルの)名前を提供することでこれを助けます。変更がローカルリポジトリにコミットされた場合、ブランチは自動的に新しく作成された場所に更新されます。

さらに、リモートリポジトリに同期する時に便利なupstream設定と呼ばれるものをローカルブランチに追加することができます。

リモート トラッキング ブランチ

リモート トラッキング ブランチはリモートリポジトリからクローンおよびフェッチする時に自動的に作成されます。ローカルリポジトリ内のリモート トラッキング ブランチはリモートリポジトリ内の(ローカル)ブランチに常に対応します。そのようなブランチの名前はある慣習に従います。

リモートトラッキングブランチは(clone/fetch時に)リモートリポジトリ内の対応するブランチとして同じコミットを指します。

リモートトラッキングブランチはローカルブランチのためのupstream設定の自動生成に使うことができます。

作業ディレクトリ

作業ディレクトリは次のコミットのためにファイルの修正に使われるディレクトリです。デフォルトでは.gitディレクトリの一つ上に位置します。新しいコミットの作成は一般的に以下のステップを伴います:

• 新しいコミットがベースとするブランチをチェックアウトします。これはブランチの HEAD リビジョンを反映するように作業ディレクトリを変更します。
• ワーキングディレクトリ内で修正を行います。
• gitにこれらの変更を伝えます(修正したファイルを追加します)。これは修正されたファイルの内容をオブジェクトデータベースに転送し、ツリーがインデックスにコミットされるように準備します。
• インデックス内で準備されたツリーをオブジェクトデータベースにコミットします。
• 結果は新しいコミットオブジェクトで、現在のブランチのHEADは新しいコミットに移動します。

リポジトリ内の変更の記録

ローカルリポジトリのブランチの新しいチェックアウトから始まります。何か変更をし、記録したい状態になった時にいつでもリポジトリ内の変更のスナップショットを記録したいとします。

作業ディレクトリ内の各ファイルは 追跡あるいは 非追跡することができます:

• 追跡 ファイルは新しく indexに上げられた最近のスナップショットあるいはファイルです。それらは unmodified, modified あるいは staged になりえます。
• Untracked ファイルはその他全てのファイルです(それらは最後のスナップショットの中に無く、indexにまだ追加されていません)。

最初にリポジトリをクローンした時には、作業ディレクトリ内の全てのファイルは 新しくチェックアウトされまだ編集が開始されていないため、tracked および unmodified でしょう。

ファイルの編集に従い、gitはそれらが最後のコミットに関して modifiedと認識するでしょう。修正されたファイルをインデックスに stage し、その後stagedされた変更を commit します。園サイクルは繰り返されます。

このライフサイクルは以下のように表されます:

タスク

リポジトリの作成

GitリポジトリがEclipseで使われるための考慮

概要

Egitを使ってGitリポジトリをセットアップする場合は、"productive"("playground"の逆)リポジトリの作成には二つのお勧めがあります。

• Eclipse workspace内にリポジトリを作成しない。
  • リポジトリをクローンあるいは作成する場合には注意してください。
  • Git Sharing ウィザードを正しく使うようにしてください。
• Eclipseプロジェクトを使ってルートとしてリポジトリを作成しないでください。
  • Git Sharing ウィザードを正しく使うようにしてください。

リポジトリのクローンあるいは作成の時にワークスペースフォルダを指定する場合に最初の失敗が起こります。

Both mistakes will happen when you use the Git Sharing Wizard from an Eclipse project that you have created manually in your workspace without taking precautions (the wizard has been fixed in the latest version).

以下でこれらのお勧めの動機づけを見つけるかも知れません。

詳細

Eclipse ワークスペースとリポジトリの作業ディレクトリ

Git リポジトリは異なる方法で作成することができます。例えば既存のリポジトリからクローン、スクラッチから作成、あるいはEgit Sharing ウィザードから作成することができます。

どの場合でも("bare"リポジトリを作成しない限りは、しかしそれはここでは話題にはしません)、新しいリポジトリは本質的に"作業ディレクトリ"とメタデータフォルダを含むローカルハードディスク上のフォルダです。メタデータフォルダは".git"という名前の専用の子フォルダで、しばしば".git-folder"として参照されます。それは実際のリポジトリを含みます。(別の言い方をすると、コミット、リファレンス、ログなどです)。

The metadata folder is totally transparent to the Git client, while the working directory is used to expose the currently checked out Repository content as files for tools and editors.

一般的に、もしこれらのファイルがEclipseになければ、それらはなんらかの形でEclipseのworkspaceにインポートされなければなりません。In order to do so, the easiest way would be to check in .project files from which the "Import Existing Projects" wizard can create the projects easily. 従ってほとんどの場合Eclipseプロジェクトを含んでいるリポジトリの構造は以下のように見えるでしょう:

示唆

上のことは以下の意味合いを持ちます:

• プロジェクトをリポジトリのルートフォルダにすることはおそらく良くない考えでしょう。

他のプロジェクトをこのプロジェクトに追加できない理由は.projectファイルがルートフォルダにあるからです; プロジェクトをサブフォルダとして追加することもできますが、このようなプロジェクトの入れ子はいたるところで多くの問題を起こすと知られています。他のプロジェクトを追加するには、プロジェクトをリポジトリのサブフォルダに移動し、この変更をコミットする前に二つ目のプロジェクトをもう一つのサブフォルダに追加しなければならないでしょう。

• リポジトリをEclipseワークスペースの外にすることは良い考えです。

これには幾つかの理由があります:

新しいリポジトリは(潜在的な)内容としてEclipseのワークスペースの完全なフォルダ構造を持つでしょう。This can result in performance issues, for example when calculating the changes before committing (which will scan the complete .metadata folder, for example); more often than not, the workspace will contain dead folders (e.g. deleted projects) which semantically are not relevant for EGit but cannot be excluded easily.

メタデータ(.git-)フォルダはEclipseワークスペースの子になるでしょう。これがEclipseによって意図せぬフォルダトラバーサルを引き起こすかどうかも分かりません。

Eclipseワークスペースを破棄することでリポジトリを容易に破壊することができます。

新しい空のGitリポジトリの作成

まずプロジェクトを作成しそれを址で共有することができます。共有プロジェクトウィザードはGitリポジトリの作成をサポートします(バージョンコントロールにプロジェクトを追加を見てください)。

新しい空のGitリポジトリをGitリポジトリビューから作成することもできます(リポジトリを作成を見てください)。

複数のプロジェクトのためのGitリポジトリを作成

共通のディレクトリの下に複数のプロジェクトを作成し、それから全てのプロジェクトのための共通リポジトリを一箇所に作成したいかも知れません。

• Eclipseプロジェクト(例えば、a, b, c)を共通ディレクトリ(例えば、/repos/examples/) の下に作成します。
• 全てのプロジェクト (a, b, c) を選択し、コンテキストメニュークリックの中で Team > Share Project > Git をクリックします。
• Nextを押します
• 全てのプロジェクト (a, b, c) を選択します。
• ウィザードは複数のプロジェクトが選択されたので、自動的にデフォルトのリポジトリの場所を親ディレクトリ /repos/examples/ に繰り上げます。
• Create Repository およびFinishをクリックします。

既存のGitリポジトリからの開始

EclipseのworkbenchでGitリポジトリの内容と連携するには、含まれているファイルとフォルダはプロジェクトとしてインポートされていなければなりません。Git リポジトリの作業ディレクトリはローカルファイルシステムの中の単なる通常のディレクトリのため、原則的にインポートは一般的な"New Project"あるいは"Import..."を使って行われなければなりません。しかしながら、新しく作成されたプロジェクトはまだ手動でGitと共有されなければならないでしょう。"Import Projects from Git" ウィザードはプロジェクトのインポートと共有を統合し、幾つかの特別な利便性も提供します。

インポートウィザードの開始

ウィザードを開始するにはImport > Git > Projects from Gitをクリックします。

何も無いワークスペースで開始した場合、最初のページは空のリストを表示するでしょう:

続ける前に、リストに一つ以上のGitリポジトリを追加する必要があります。リストに既にリポジトリがある場合は、このステップは任意です。

リポジトリのクローンあるいは追加

リストにGitリポジトリを追加するには二つの方法があります:

1. リモートリポジトリのクローン
2. ローカルファイルシステムから既存のリポジトリを追加

リポジトリのクローン

リモートリポジトリから開始する場合は最初の選択肢が使われます。クローン操作がリポジトリをローカルファイルシステムにコピーします。クローンウィザードを開始するには、 Clone...をクリックします。クローンウィザードは Cloning Remote Repositoriesで詳しく説明されます。クローン操作の終了が成功すると、新しくクローンされたリポジトリが自動的にリストに現れます。

リポジトリの追加

The second option is useful if you already have a repository in your local file system, for example because you have cloned it earlier, you created it from scratch or you copied it from somewhere else. Add...をクリック; ローカルファイルシステムの中のディレクトリを選択します。このディレクトリ内に含まれるGITリポジトリのスキャンを起動するために Search を押します。Gitリポジトリが見つかった場合は、リスト表示され、追加するためのリポジトリを選択することができます:

処理が終わった後で、リポジトリリストは幾つかのリポジトリを含んでいる必要があります:

リストからリポジトリを選択します。

これでリポジトリを選択し Nextをクリックすることができます。ウィザードの次のページでどのようにプロジェクトをインポートするかを決めるでしょう。

プロジェクトのインポート

This page offers a group with radio buttons that allows you to select a wizard and a directory tree that optionally allows you to select a folder in the working directory.

プロジェクトのインポートのためのウィザード

既存のプロジェクトのインポート

ラジオボタンが選択されると、ウィザードは.project のためにローカルファイルシステムをスキャンし、発見したプロジェクトを表示するでしょう。これがもっとも快適な解決法であり、.project ファイルをリポジトリにチェックして入れる場合に使われるべきです。

プロジェクトのインポートのためのスコープの制限

この場合、最下のディレクトリがアクティブになります。このツリーの中のフォルダを選択することで .project ファイルの剣s買うを制限することができます。そうでなければリポジトリの作業ディレクトリ全体がスキャンされるでしょう。 次のページでは、発見されたプロジェクトがあれば表示されるでしょう。これは一般的なImport Existing Projects ウィザードにとても似ていますが、幾つか追加のフィルタリングの方法があります。

新しいプロジェクトのウィザードの使用

このオプションが選択された場合は、一般的な"New Project" ウィザードが開かれるでしょう。"New Project"ウィザードが完了した後で、"Import Projects from Git" ウィザードが再開され、作成したばかりのプロジェクトの共有をする手助けをするでしょう。

この場合、選択は"New Project"ウィザードと無関係のため、最下のディレクトリツリーは非アクティブになります。

一般的なプロジェクトのインポート

このオプションは、利用可能な.projectファイルまたは適切な"New Project"ウィザードが無い場合に有用でしょう。選択された場合は、ウィザードは .project ファイルを生成し、プロジェクトがリポジトリの作業ディレクトリのフォルダを示すようにするでしょう。その結果が"General Project"です。

デフォルトでは、新しく生成されたプロジェクトはリポジトリの作業ディレクトリを示すでしょう。 最下のディレクトリツリーから幾つかのフォルダを選択することで、そのフォルダのために生成されたプロジェクトを得ることができます。

新しいプロジェクトの名前とディレクトリを入力するための単純なダイアログを開くために Next をクリックします。

デフォルトでは、ディレクトリの名前に一致するプロジェクトが示唆されます。

リモートリポジトリとの作業

リモートリポジトリのクローン

Git クローン ウィザードを使って、異なる転送プロトコルを使うリモートのレポジトリをクローンすることができます。

ウィザードは以下を使って "Import Projects from Git" から始めることができます
File > Import... > Git > Projects from Git > Next > Clone URI > Next

あるいはClone a Git Repositoryツールバーのボタンあるいはビュー メニューを使って "Git Repositories View" (リポジトリの管理で説明されます)から。

リポジトリの選択

ウィザードの最初のページで、リモートリポジトリの場所を入力します:

• URI - リモートのリポジトリの完全URL、あるいはファイルシステムのパス。このフィールドは自動的に他のフィールドと同期されます。
  ローカルディレクトリをブラウズするために Local file... ボタンを使うことができ、URIフィールドは以前に使用された値を提供することでコンテントのアシストを提供することに注意してください。
• Host - リモートホストの名前、あるいはファイルシステムからクローンした場合は空。
• Repository Path - リモートリポジトリあるいはファイルシステムのパス。
• Protocol - 以下で説明されるプロトコルのうちの1つ。
• Port - ポート番号。
• User - 認証のために使われるユーザ名。
• Password 認証のために使われるパスワード。
• Store in Secure Store パスワードがEclipseセキュア ストアに保存されるかどうか。

以下のプロトコルがサポートされます:

• file - リポジトリへのファイルシステム アクセス。
• ftp - ファイル転送プロトコル
• git - 最も効率的な組み込みのgitプロトコル (デフォルトのポート 9418). このプロトコルは認証を提供しません。一般的にリポジトリへの匿名読み込みアクセスに使われます。
• http - ハイパーテキスト転送プロトコル はファイアウォールを超えてトンネルすることができます。
• https - ハイパーテキスト転送プロトコル セキュア はファイアウォールを超えてトンネルすることができます。
• sftp - SSH ファイル転送プロトコル
• ssh - secure shell (SSH) プロトコル上のGit。一般的にリポジトリへの認証書き込みアクセスに使われます。

注意: もしファイアウォールの後ろにいる場合は、プロキシ設定 (Preferences > General > Network Connections) を構成しなければならないかもしれません。多くのHTTPプロキシは、例えば http://fred:topsecret@egit.eclipse.org/egit.gitのようなユーザ名 (および/あるいはパスワード)を含むURLをブロックするように設定されています。ウィザードページの下にあるuser, password フィールドを使うことがお勧めなため、証明書はHTTP ヘッダとして送信されるでしょう。

ブランチの選択

次のページで、どのブランチがリモートレポジトリからクローンされるべきかを選択します:

どのブランチが必要かに自信が無い場合は、単純に "Select All" を押してください。

You can filter the branches by their name by typing using the text control above the list. しかし、チェックされたブランチはリスト内で常に表示されるだろうことに注意してください。つまりそれらはフィルターされないでしょう。

ローカルの宛先

次のページで、リポジトリのローカルファイルシステムのどこに保存したいかを定義し、いくつかの初期設定を定義します。

• Directory - Gitレポジトリを含むだろうディレクトリ。まだ存在しない場合は、ウィザードによって作成されるでしょう。
• Initial branch - どのローカルブランチが作成され、始めにチェックアウトされるかを選択します。
• Remote name - リモートリポジトリのための名前を定義します。デフォルトは "origin" です。

Gitリポジトリを格納するためのデフォルトのルートパスは Team > Git > Default Repository Folder 設定の中で構成することができます

Gerrit Code Reviewを使って作業していてそれに応じてリポジトリを設定したい場合は、このページ上のFinishまたはNextを押すことができます。

特定の場所からのクローン

Egitのクローン ウィザードはgitレポジトリをホストする特定のバックエンド上でレポジトリを検索するために他のプラグインによって拡張することができます。現在のところそのような拡張はGithubについて利用可能で、すぐにGerritについて利用可能になるでしょう。両方について、それぞれのMylynコネクタをインストールする必要があります。Gerrit Mylyn コネクタ拡張はGerritと連携するためのリモートリポジトリの設定も必要でしょう。これは後でGitレポジトリビューから行うかあるいは変更することも可能です。Gerrit 構成を見てください。

そのような拡張をインストールした場合、クローン ウィザードはクローンするレポジトリの異なるソースの間で選択することができる選択ページで始まります。

他のレポジトリへのpush

upstreamへのpush

"Upstream 構成"と呼ばれるローカルブランチと連携している場合、pushするための最も便利な方法はこのupstream構成を頼みとします。

一般的にローカルブランチはリモートの追跡しているブランチに基づいて作成されます。リモート追跡ブランチはリモートと関連し、リモートは対応するリモートリポジトリにアクセスする必要があるため、ローカルブランチを作成する間にこのupstream構成を自動的に作成するかもしれません (詳しい情報は ブランチ を見てください)。

upstreamをローカルブランチからpushする時に、pushはそれ以上のパラメータを必要としません。従ってpushは格納されたupstream構成に基づいた他のダイアログを表示することなく行うことができます。

upstreamをpushするために、プロジェクト上で右クリックし、Team > Push to upstream を選択するか、レポジトリビュー内のレポジトリ上で右クリックし、Push to upstreamをクリックします。Git Command Group内にも利用可能なアクションがあります。

pushはアクションを選択した後ですぐに実行されるでしょう。いったん完了すると、pushされたデータおよび/あるいはエラーメッセージについての情報を表示する確認ダイアログが表示されるでしょう:

upstreamのpushの構成

upstreamのpushは確認ダイアログ(上を見てください)上の "Configure..." ボタン、あるいはプロジェクトを右クリックし Team > Remote > Configure push to upstream...を選択することで、構成することができます。

pushのURIと対応するブランチのマッピング (RefSpecs)の設定のために、構成構成ダイアログが表示されるでしょう:

ダイアログは3つの主なセクションに分割されます:上の部分で、現在チェックアウトされたブランチと追従しているリモートについての情報が表示されます。通常はローカルブランチがこのリモート追跡ブランチを追跡するように自動構成するリモート追跡ブランチに基づいて作成されます。

この具体的な例では、"origin"という名前のリモートを使う幾つかのブランチがあるという警告メッセージがあります。このことはpush構成の中での変更はブランチ フィールド内に表示されるブランチだけでなく全てのブランチに影響するだろうことを意味します。ツールチップ内にこれらのブランチを表示するには警告にマウスオーバーしてください。

URIグループは2つのコントロール、URIフィールドとPush URIリスト、を含みます。もしリストが空の場合、URIフィールド内のURIはPushのために使われ、Push URIリスト内に少なくとも1つのエントリがある場合は、リスト内のURIが代わりに使われるでしょう。もしPush URIリストが空でURIがこのダイアログ内で変更された場合、新しいURIもPullのために使われるだろうことに注意しなければなりません。そうする場合には注意が必要です。

RefMapping グループはPushのための1つ以上のRefSpecs( Refspecsを見てください)を許容します。

"Add" はRefSpecsの生成内で役に立つ小さなウィザードを開くでしょう。クリップボードからリストの中にRefSpecを貼り付けることもできます。

"Advanced"コントロールをクリックすると、上述のPush Wizardに似たより複雑なRefSpec編集が行える "Edit (Advanced...)" ボタンを表示/非表示するでしょう。

下のボタンバー内のボタンにより、変更を保存し、即座にpush、フェッチ無しに変更を保存、dry-run (構成を保存無しにpush)、変更の戻し、およびキャンセルを行うことができます。

直接のパス

別のやり方として、リモートのPush仕様上のDirect Push Supportを使うことができます。

Pushウィザード

最も強力(だが、最も複雑)な方法はPushウィザードを使うことです
Team > Remote > Push...

Push URI

• リポジトリビュー内でPush仕様を既に構成している場合、構成されたリモートリポジトリの下のドロップダウンリストを使って、ここで選択することもできます。もしこのリモートのためのPush構成が適切に構成されている(つまり少なくとも1つのURIとref specを持つ)場合、Finish ボタンが有効にされるでしょう。
• そうでなければ、Custom URIをクリックし、pushしたいupstreamリポジトリのURIを入力します。

Push Ref仕様

更に詳しい説明は Refspecs を見てください。

Next
をクリックしますもしこのレポジトリにsshを使って接続するのが初めてなら、リモートリポジトリのホストキーを受け付ける必要があるでしょう。

もしsshキーがパスフレーズ(これがお勧めです)で保護されている場合、ここでそれを入力する必要があります

Add all branches specをクリックします

ローカルブランチの名前を、変更をpushしたいupstreamレポジトリ上で同じブランチ名にマップしたいと宣言するのに便利な方法です。

ローカルタグをpushしたいレポジトリ内のタグに1:1にマップするには、Add all tags spec をクリックします。

もし異なるやり方でローカルブランチをupstreamレポジトリ内のそれらにマップしたい場合は、以下の方法でより詳細なマッピングの仕様を定義することができます。

• refの始点および終点を入力、あるいはドロップダウンリストから既存のブランチを選択します
• Add Specをクリックします

これは新しく定義されたマッピングをリスト Specifications for pushに転送するでしょう

他の一般的なpush仕様:

• ニックネームjoeに対応してpushするブランチに名前を付けたい場合、例えばrefs/heads/* を refs/heads/joe/* にマップするかもしれません。もし複数のユーザが連携して使われるパブリックなレポジトリ内の個人のブランチ上にローカルブランチを発行したい場合は有用です。
• もう一つのよくあるマッピングは起点 ref HEAD を終点 refs/heads/master にマップすることです。このことは現在の HEAD (例えば現在なんらかのトピックブランチを指し示しているかもしれません)をupstreamのマスターブランチにマップしたいことを意味します。

Ref 仕様の削除

目的のレポジトリ内のrefを削除するには、ドロップダウンリスト Remote ref to delete からそのrefを選択し、Add Specをクリックします。これはSpecifications for push リスト内の対応するエントリを作成するでしょう。別のやり方としてrefが削除されるようにspecification内に文字を打つことができます。これはワイルドカードを使うこともできます。Delete Ref Specifications のpushは目的のレポジトリ内の合致するRefsを削除するでしょう。

衝突しているPush Ref Specifications

複数の衝突している Push Ref Specifications を追加すると、それらは赤く印を付けられ、衝突しているspecsを削除あるいは編集することでこれを解決するでしょう。リストSpecifications for push内の適切な位置にspecを編集することもできます。

Pushの確認

Nextをクリックします

これはどの変更が目的のレポジトリにpushされるかのプレビューを表すPush確認ダイアログを開くでしょう。これが期待と異なり場合は、Backをクリックし、push specsをそれに応じて修正してください。

• refの更新については、pushされるコミットの範囲は <SHA1-from>..<SHA1-to> の形式で表されます。例えば d97f5a2e..adfdbfd2 は d97f5a2e と adfdbfd2 の間の全てのコミットがpushされるでしょう。
• 宛先のレポジトリ内にまだ存在しないrefについては、[new branch] または [new tag] が表示されます。
• 削除されるだろうrefについては[deleted]が表示されます。

• Select the Push only if remote refs don't change in the mean time check box if you want to be sure that what you see in this preview is also what you get when pushing these changes out.
• Select the Show final report dialog only when it differs from this confirmation report check box if you only want to get a report after executing the push if the result differs from this preview.

push結果のレポート

Finishをクリックします

選択したオプションに応じてpush結果レポートのダイアログが表示されます。リモートにpushされたコミットのリストを表示します。

下のボックス内でリモートサーバからのpush確認メッセージが表示されます。何かエラーがある場合、リモートサーバからのエラーメッセージをここに見つけるでしょう。与えられたリストのエントリのメッセージを見るには、単にリスト内でそれを選択します。

ダイアログを閉じるにはOkをクリックします。

他のレポジトリからのフェッチ

upstreamからのフェッチ

"Upstream 構成"と呼ばれるローカルブランチと連携している場合、フェッチするための最も便利な方法はこのupstream構成を頼みとします。

ローカルのブランチは一般的にリモート追跡ブランチに基づいて作成されます。リモート追跡ブランチはリモートと関連し、このリモートはリモートリポジトリにアクセスする必要があるため、ローカルブランチを作成する間にこのupstream構成を自動的に作成するかもしれません (詳しい情報は ブランチ を見てください)。

upstreamからフェッチする時、この持続された構成はダイアログ内にそれ以上のパラメータを提供する必要無しに自動的にフェッチするために使うことができます。

upstreamからフェッチするためには、プロジェクト上でTeam > Fetch from upstreamをクリックするか、レポジトリビュー内のリポジトリ上でFetch from upstreamをクリックします。Git Command Group内にも利用可能なアクションがあります。

アクションを選択した後で直ちにフェッチが実行されるでしょう。一旦完了すると、フェッチされたデータおよび/あるいはエラーメッセージについての情報を表示する確認ダイアログが表示されるでしょう:

upstreamからのフェッチの構成

upstreamのフェッチは確認ダイアログ(上述)上の "Configure..." ボタンを使うか、あるいはプロジェクト上の Team > Remote > Configure fetch from upstream... をクリックすることで設定することができます。

フェッチURIとブランチのマッピング (RefSpecs)を設定するための設定ダイアログが現れるでしょう:

ダイアログは3つの主なセクションに分割されます:上の部分で、現在チェックアウトされたブランチと追従しているリモートについての情報が表示されます。

フェッチURIを追加/変更するためにURIフィールドを使うことができます。

RefMapping グループはフェッチのための1つ以上のRefSpecs( Refspecsを見てください)を許容します。

"Add"ボタンがRefSpecsの生成内で役に立つ小さなウィザードを開くでしょう。クリップボードからリストの中にRefSpecを貼り付けることもできます。

"Advanced"コントロールをクリックすると、上述のFetch Wizardに似たより複雑なRefSpec編集が行える "Edit (Advanced...)" ボタンを表示/非表示するでしょう。

下のボタンバー内のボタンにより、変更を保存し、即座にフェッチ、フェッチ無しに変更を保存、dry-run (構成を保存無しにフェッチ)、変更の戻し、およびキャンセルを行うことができます。

直接のフェッチ

フェッチのためのもう一つの方法はリモートのフェッチ仕様上でDirect Fetch Supportを使うことです。

フェッチ ウィザード

最も強力(だが最も複雑)な方法はフェッチ ウィザードを使うことです
Team > Fetch...

• リポジトリビュー内でフェッチ仕様を既に構成している場合、構成されたリモートリポジトリの下のドロップダウンリストを使って、ここで選択することもできます。もしこのリモートのためのフェッチ構成が適切に構成されている(つまり少なくとも1つのURIとref specを持つ)場合、Finish ボタンが有効にされるでしょう。

• そうでなければ、Custom URIをクリックし、変更をフェッチしたいupstreamリポジトリのURIを入力します。

Ref仕様のフェッチ

更に詳しい説明は Refspecs を見てください。

Next
をクリックしますAdd all branches specをクリックします

これは変更を1:1から同じローカルブランチ名にフェッチしたいupstreamレポジトリ内のブランチ名をマップしたい事を宣言するのに便利な方法です。

• 編集フィールド Destination Ref 内でクリックし、パス部分 choose_remote_name をフェッチしようとしているupstreamレポジトリのためのシンボリック名と置き換えます。
• リポジトリがクローンされるレポジトリのためのデフォルトのリモート名は origin です。このリモートのマスターはデフォルトで refs/heads/master から refs/remotes/origin/masterにマップします。
• 例えば、ローカルレポジトリ内にJoeのレポジトリからのブランチを更に追跡したい場合は、彼のレポジトリ内のブランチ refs/heads/* を以下のような追跡ブランチrefs/remotes/joe/*にマップするでしょう。
• fast-forward 更新のみを許可したい場合はForce Updateを非選択にし、non-fast-forwardの変更も許可したい場合はこのオプションを選択します。
• 全てのspec上で強制更新オプションを設定するには Force Update all Refsをクリックします
• リストSpecifications for fetchからの全てのspecを削除するにはRemove all specs をクリックします

• Click Add all tags spec to map tags tags in the repository you want to fetch from 1:1 to local tags.

upstreamレポジトリ内のブランチあるいはタグを異なる方法でローカルブランチにマップしたい場合は、以下の方法でより詳細なマッピング仕様を定義することができます。

• 始点(ソース レポジトリ内のref)と終点ref (ローカルレポジトリ内の追跡ブランチあるいはタグ)を入力するか、ドロップダウンリストから既に存在するブランチを選択します
• Add Specをクリックします

これは新しく定義されたマッピングをリストSpecifications for fetchに移動するでしょう

フェッチ結果レポート

Finishをクリックします

フェッチ結果ダイアログが表示されます。

• For ref updates the list commits which have been fetched will be shown.
• ローカル レポジトリに前まで無かったrefについては、[new branch] あるいは [new tag] が表示されます。
• 削除されたrefについては、[deleted]が表示されます。

新しい変更をupstreamブランチから取り出す

• パッケージ エクスプローラ内のプロジェクト上で右クリックし、Team > Pull を選択するかGitレポジトリビュー内のレポジトリ上で右クリックし、ローカルブランチが追跡しているupstreamブランチから新しい変更をプルするために Pull を選択します。リソースが1つ以上のレポジトリから選択された場合も、これは動作します。
• Whenever you create a local branch based on a remote tracking branch EGit can configure a tracking relationship so that subsequent pulls will fetch and then merge or rebase (depending on the configuration of this tracking relationship) the changes from the tracked upstream branch; see Branching for details.

Ad-hoc selection of the upstream branch to pull from is not yet supported by EGit.

Available alternatives include:

• eclipse外から git pull を実行します (でもWindows上では注意してください)
• ローカルの変更をしないか、ローカルの変更を破棄したい場合は、Team > Reset...を使います

Gerritとの連携

Gerrit (http://code.google.com/p/gerrit/) と一緒に使う場合は、Egitを使ってGerritサーバから、そしてGerritサーバへ便利にプッシュおよびフェッチすることができます。

レポジトリのためにGerritを有効にする

まずレポジトリを構成しない場合は、どのメニューにもGerritの操作が現れないでしょう。そうするには、Gitレポジトリビューを開き、使用したいGitレポジトリサーバを表すRemoteへブラウズし、Gerrit Configuration...を選択します。

変更をGerritコードレビューサーバへプッシュする

プロジェクト上で右クリックしTeam > Remote > Push to Gerrit...を選択するか、レポジトリビュー内のレポジトリ上で右クリックしてPush to Gerrit...を選択します。

URIとブランチ名を選択あるいは入力するダイアログが現れるでしょう:

• URIコンボの中で、Gerritインスタンスを示すURIを選択あるいは入力します; コンボは現在のレポジトリのリモート内で定義されている全てのURIであらかじめ埋められているでしょう; 更に、このフィールドの中にどのようなURIでも入力することができます
• Gerritブランチフィールドの中で、変更がプッシュされるだろうレビューキューを選択するためにブランチ名を入力します

ダイアログはGerritブランチについてのコンテント アシストも提供します。これを活性化するには単純に "Ctrl+Space" を押します (Gerritブランチフィールドの近くの小さな球の装飾の上でホバーする時に現れるツールチップを参考にしてください)。現在のレポジトリのためのリモート追跡ブランチが現れるでしょう。このコンテント アシストはフィルターされているため、全ての提案を見るにはコンテント アシストを要求する前にGerritブランチフィールドを確実に空にする必要があることに注意してください。

Finishをクリックすると、現在チェックアウトされているコミットが特定のGerritブランチにプッシュされるでしょう。また、URIとGerritブランチの値は記憶され、ダイアログが後で再び開かれる時に再び提案されるでしょう。

並行して異なるGerritブランチと作業する場合、これはもっと柔軟性を考慮します (例えば、開発とホットフィックスの間で頻繁に切り替え)。

変更の編集

変更がGerritにプッシュされレビュワーが何らかの改善を示唆する場合、この変更に対する新しいパッチセットがアップロードされなければなりません。まず、コミット(s)を編集します:

• 1つの変更に対し1つのコミットの場合、コミットを修正することができます ( コミットの修正を見てください)。
• 複数の依存コミットがあり、最後の1つ以外にコミットを編集する必要がある場合、対話的なrebaseを行うことができます ( 対話的なRebaseを見てください)。別のやり方として、編集したいコミットをチェックアウトしてそれを修正し、一番上の最近のコミットを拾い上げます (これは対話的なrebaseが行うことです)。

そして同じブランチに再びプッシュします。Gerritは既存の変更を更新していることを検知し、新しいパッチセットを追加するでしょう。

Gerritコードレビューサーバから変更をフェッチします。

プロジェクト上で右クリックしTeam > Remote > Fetch from Gerrit...を選択するか、レポジトリビュー内のレポジトリ上で右クリックしてFetch from Gerrit...を選択します。

URLと変更、そして幾つかの追加のオプションを選択あるいは入力させるダイアログが現れるでしょう:

• URIコンボの中で、Gerritインスタンスを示すURIを選択あるいは入力します; コンボは現在のレポジトリのリモート内で定義されている全てのURIであらかじめ埋められているでしょう; 更に、このフィールドの中にどのようなURIでも入力することができます
• 変更フィールドの中で変更の完全な名前を入力しなければなりません; この値を以下で説明されるコンテントアシストを使ってGerrit Web UIから取るか、以下のパターンを使って名前を構築することができます:
  "refs/changes/" + (last two digits from change number) + / + (change number) + / + (revision number)
• In the "Actions to perform after fetch" you can decide what to do after the change has been fetched; you can either create and checkout a branch pointing to the change, create and checkout a tag pointing to the change, or simply checkout the change (thus making HEAD detached); the last option does nothing after fetch, but you will be able to find the commit pertaining to the change at FETCH_HEAD (go to the Repositories View and find FETCH_HEAD under the References node of your Repository, see Inspecting References ).
  ブランチあるいはタグの名前はダイアログによって提案されますが、必要に応じて上書きされるかもしれません。
  タグの削除は現在のところEGitでサポートされないため、しばらくの間はタグよりローカルブランチを使うことをお勧めします。レポジトリビューにｙろい"/" を階層分離符号として使ってブランチの階層構造をグループ化することができるため、多数の変更を取り扱う時に提案された名前扱いやすく役に立ちます。

退屈なコピー-ペーストあるいは変更IDの手動入力の代わりに、ダイアログは変更のためのコンテントアシストも提供します。これを活性化するには単純に "Ctrl+Space" を押します (変更フィールドの近くの小さな球の装飾の上でホバーする時に現れるツールチップを参考にしてください)。Gerritサーバは接続され、全ての利用可能な変更がフェッチされ、コンテントアシスト ダイアログ内に表示されるでしょう:

リストは変更フィールドの中で入力を使ってフィルターされます。コンテントアシストの中で変更を選択した後で、変更フィールドは正しい情報で満たされます。

Fetch from Gerrit... ウィザードを開く前にGerrit WebUIからクリップボードにダウンロードコマンドをコピーすることもできます。This will automatically populate the dialog with the values needed to fetch this change.

レポジトリの状態の検査

ラベルの装飾

ラベルの装飾はGitバージョンの管理下にあるリソースについてのGit固有の情報を示します。それらはパッケージエクスプローラ、プロジェクトエクスプローラ、ナビゲータ、階層ビューのようなモデルオブジェクトを示す全てのビューの中で現れます。

The Git label decorations can be switched on globally in the Preference Menu (Window > Preferences) under General > Appearance > Label Decorations, and more detailed settings can be modified in Preferences under Team > Git > Label Decorations.

2つの異なる種類のラベル装飾があります: テキスト装飾とアイコン装飾。

テキスト装飾

テキスト装飾はテキストラベルの左あるいは右側に現れます。それらはText Decorationsタブ上のTeam > Git > Label Decorationsの下のPreferenceダイアログ上で設定することができます。例えば、ダーティなリソースのデフォルトはその名前の左側の> です。

これらはデフォルトの設定です:

ファイルとフォルダについては、様々な"name", "dirty" と "staged"があります。"Dirty" と "staged" はフラグです; もしtrueの場合、コロンの後のテキストが表示されます。

プロジェクトについては、追加の変数"repository", "branch" と "branch_status" があります。"repository" 変数はレポジトリの名前を表示します。

"branch" 変数は現在チェックアウトされたブランチの名前を表示します。もしブランチがチェックアウトされない場合は、装飾はコミットの短縮名(省略記号が続く最初の7文字)を示します。If tags and/or remote branches are pointing to this commit, a "best guess" heuristic is applied to also show this information: tags take precedence over remote branches, and if several tags apply, the newest one is displayed. 修正日付が無い幾つかのリモートブラントあるいはタグがある場合は、アルファベット順のソートが適用され、最後の1つが表示されます。例: チェックアウトされたコミットe49f576... はリポジトリegitのタグv.0.7.1を参照します:

"branch_status" 変数は、upstreamとして設定されたリモート追跡ブランチに匹敵するローカルブランチの状態を示します:

• ↑N – ローカルブランチはまだリモート追跡ブランチに無いN個のコミットを持ちます。これは "N commits to push" として読み込まれることができます。
• ↓M – リモート追跡ブランチはローカルブランチに無い M個のコミットを持ちます。これは "M commits to merge/rebase" として読み込まれることができます。
• ↑N↓M – ローカルブランチとリモート追跡ブランチは分岐しました (上の二つが両方を適用します)。
• – ローカルブランチとリモート追跡ブランチが同じ状態を持つ場合は空です。

状態変数はこのように前の空白を使って使うことができます: { branch_status}. これは状態が空でない場合のみ追加される空白となります。

アイコンの装飾

アイコンの装飾はラベルの前に表示されるアイコンの右下の隅に現れます。それらはタブ Icon Decorationsの上のTeam > Git > Label Decorationsの下のPreferenceダイアログ上で設定することができます。

これらはデフォルトの装飾です:

• dirty (folder) - フォルダの下の少なくとも1つのファイルがダーティ; インデックス内あるいはレポジトリ内のどちらでもない作業ツリー内で変更があることを意味します。
• tracked - リソースはGitリポジトリに知られていて、従ってバージョン制御下にあります。
• untracked - リソースはGitリポジトリに知られておらず、明示的に追加されるまでバージョン制御されないでしょう。
• ignored - リソースはGitチーム プロバイダによって無視されます。Team > Ignored Resourcesのプリファレンス設定, "derived" フラグ と.gitignore ファイルからの設定が考慮されます。
• dirty - リソースがインデックスあるいはレポジトリ内のどちらでも無い作業ツリー内で変更されました。
• staged - リソースにはインデックスに追加された変更があります。インデックスへの変更の追加は現在のところリソースのコンテキストメニューを使ってコミットダイアログ内でのみ可能であることに注意してください。
• partially-staged - The resource has changes which are added to the index and additional changes in the working tree that neither reached the index nor have been committed to the repository. See partial staging from the Git Staging view for how to do that.
• added - リソースがまだレポジトリ内にコミットされていないが、将来追跡するためにGitレポジトリに新しく追加されました。
• removed - リソースがGitリポジトリから削除するためにステージに上げられました。
• conflict - そのファイルについてマージの衝突があります。
• assume-valid - リソースは"assume unchanged" フラグを持ちます。This means that Git stops checking the working tree files for possible modifications, so you need to manually unset the bit to tell Git when you change the working tree file. Assume unchanged actionも見てください。

コミット ダイアログ

全ての修正された追跡されているファイルの状態の要約がコミットダイアログ上に表示されます。ファイルをダブルクリックすることでコミットされる変更が比較ダイアログの中に表示されるでしょう。EGitは現在のところ作業ツリーの内容を常にコミットするため(コマンドライン上での git commit -a に対応します)、比較ダイアログは作業ツリーと最後のコミットを比較するでしょう。

内容の比較

日常の作業の中で、最後のコミット、インデックス、そして現在の作業ツリーの間の変更をしばしば見たいでしょう。そうするには、プロジェクトエクスプローラあるいはナビゲータ内でリソース (プロジェクト、フォルダあるいはファイル)を選択し、Compare Withの下のアクションを右クリックします。

特定のコミットの内容を解析するにはこのタスクをもっと手助けするHistory Viewを使うべきです。タスク Inspecting Commitsを見てください。

比較エディタと同期ビュー

1つのファイル上でCompare Withのサブメニュー アクションのいずれかを使う場合、比較エディタが表示されるでしょう。そうでなければ (Egit 3.1から)変更をブラウズさせるSynchronize View が開かれるでしょう; このビューの中の変更されたファイル上でダブルクリックすることで、このファイルについての比較エディタが開かれるでしょう。同期ビューのツールバーの中で、調査している変更を表すために使いたい同期モデルを選択することができます。

最後のコミットと連携する比較作業ツリー

現在の作業ディレクトリと現在のブランチの中の最後のコミットのリソース間の違いはコンテキストメニューのCompare With > HEAD revisionから見ることができます。この機能はコミットダイアログからも利用可能です。コミット ダイアログ内のエントリ上でダブルクリックすると比較ダイアログが開きます。

インデックスを使った作業ツリーの比較

現在の作業ツリーとインデックス(現在選択されたリソースに基づく)との間の違いはコンテキストメニュー Compare With > Git Indexから見ることができます。

ブランチ、タグあるいはリファレンスと作業ツリーの比較

• リソースを選択します
• Compare With > Branch, Tag, or Reference...を右クリックします
• ブランチ、タグあるいはリファレンスを選択します

任意のコミットと作業ツリーの比較

プロジェクトエクスプローラから:

• リソースを選択します
• Compare With > Commit...を右クリックします
• コミットグラフからコミットを選択します

履歴ビューから(ファイルのみ):

• パッケージエクスプローラ内のファイルを選択します
• Team > Show in Historyあるいは Compare With > History...を右クリックします
• コミットグラフの中でコミットを選択します
• コンテキストメニューからCompare with working treeを選択します
• これは選択されたコミットと現在の作業ツリーの間の変更を表す比較ダイアログを開くでしょう

2つのコミットの比較

• パッケージエクスプローラ内のリソースを選択します
• Team > Show in History あるいはCompare With > History...をクリックします (後者はファイルのためのみです)
• コミットグラフ内で2つのコミットを選択します
• Compare with each otherを右クリックします
• これは2つの選択されたコミットの間の変更を表す比較ダイアログを開くでしょう
• Compare with each other in Treeを右クリックすることでGitツリー比較ビューを開くこともできます

HEADあるいは任意の他のコミットとインデックスを比較

ステージングビューを使ってインデックスとHEADを比較することができます。インデックスのバージョンとHEADバージョンを比較するために、"Staged Changes" ペインの中で表示されるファイルをダブルクリックします。インデックスと他のコミットの間の比較はまだ実装されていません。

ブランチとの比較(同期)

作業ツリー(コミットされていない変更を含む)とブランチまたはタグとの間の違いは、比較したいプロジェクト(s)を選択し、Compare With > Branch, Tag or Referenceをクリックすることで見ることができます(Egit 3.1から)。結果は比較が始まる前に選択されたリソースについてフィルタされます。

プロジェクト上の動的メニューTeam > Synchronize をクリックし、作業ツリーに対して同期したいRefを選択することで、ブランチと比較することもできます。Git リポジトリが複数のEclipseプロジェクトを含む場合、1つのプロジェクトを選択するだけで十分です。Synchronization Viewは全ての他のプロジェクトも含むでしょう。

動的メニューにリスト化されていないRefと同期したい場合は、Team > Synchronize > Other...をクリックします。そして同期Wizard内で同期したいレポジトリの目的のカラムをクリックし、比較したいRefを選択します。

When clicking "Include local uncommitted changes in comparison" also local, not yet staged changes and the already staged changes will be shown in comparison.

複数のレポジトリを同時に比較することも可能です。この場合同期ウィザード内で比較したいRefの各レポジトリを選択します。

Quickdiff

比較エディタを使う代わりに、quick diffサポートを有効にし、テキストエディタ内で変更を見ることができます。
この機能はGeneral > Editors > Text Editors > Quick Diff プリファレンスページを使って有効にすることができます:

そして異なる注釈がエディタの左側に表示されるでしょう:

注釈をマウスオーバーすると、比較しようとしているバージョンの内容が見えます:

デフォルトでは、比較はHEADに対して行われます:You can determine the version you are comparing to, the so-called quickdiff baseline, from the context menu of a commit in the history view (Show in > History). 3つのメニューのエントリがあります:

• Quick Diff -> Reset baseline to first parent of HEAD - HEADの前の最初のコミットに対する比較。
• Quick Diff -> Reset baseline to HEAD - HEADに対する比較。
• Quick Diff -> Set as baseline - 選択されたコミットに対する比較。

コミットの検査

指定されたコミットの検査をするには

• パッケージエクスプローラ内のコンテキストメニューからTeam > Show in Historyを選択します
• 検査をしたいコミットを選択します

コミットについてのDiffを見る

履歴ビューは左下のペインにdiffを表示します。右下のペイン内のファイルを選択すると、そのファイルについてのdiffを表示します。

コミットの内容を表示

右下のペイン内のファイル上でのダブルクリックの挙動は比較モードのトグルボタンの状態に依存します。onの場合、現在のコミット内のファイルの内容と前のコミットの内容を比較する比較エディタが開かれるでしょう; offの場合、現在のコミットのファイルの内容を表示するエディタが開かれるでしょう。

変更のコミット

gitバージョン管理下のプロジェクトへの変更はコミットを通じてgit履歴に残ります。Starting from the state checked out from the git repository modify your project until you have reached a state you are satisfied with and then commit all these changes into the repository as one single commit. 各コミットはレポジトリ内に格納されている全てのファイルの良く定義されたスナップショットを表します。

内容の修正

既にGitと共有されているプロジェクトを修正するには、Elicpse内あるいはファイルシステム内のファイルを修正または削除します。これr尚操作についてあらかじめGitに知らせておく必要はありません。バージョン制御されなければならない新しいファイルはGitバージョン制御の下に明示的にputされなければなりません:

• ファイルのコンテキストメニュー内でTeam > Add をクリックします

別のやり方として、コミットダイアログ内の追跡されていないファイルを表示し、コミットに含めるためにそれらを選択するためにShow untracked Filesをチェックします。

例えばパッケージエクスプローラ内では、ラベル修飾子は以下のように見えます:

• まだgitバージョン制御に無い、追跡されていないファイル ("?"で印を付けられます)
• 追加されたファイル ("+"で印を付けられます)
• 修正されたフィル (ファイル名の前に">" で印を付けられます)

詳細はラベル修飾を見てください。

これはパッケージエクスプローラ内での例です:

• コミットされたファイル
• 作業ディレクトリ内で修正されたが、次のコミットのためにまだステージされていないファイル
• 修正が次のコミットのためにステージされている修正されたファイル
• 次のコミットで初めて含まれるために新しくステージされたファイル
• gitバージョン制御下に無いファイル

コミット

ステージング ビューを使ったコミット

選択されたレポジトリについて常に現在の状態を表し、ステージ(gitインデックスに追加する)し、修正されたファイルをアンステージ(gitインデックスから削除する)ことができるため、EGitを使ったコミットを作成するために好まれる方法は Staging View です。gitインデックスと比較するにはUnstaged Changes ペイン内のファイルをダブルクリックし、HEADに対してインデックスバージョンを比較するにはStaged Changesペイン内のファイルをダブルクリックします。ステージングビューはモーダル エディタではなくビューなので、ステージングビュー内でコミットメッセージを逐次的に編集することができます。

コミットダイアログを使ってコミット

変更をコミットするには、プロジェクト内のリソースのコンテキストメニュー内のTeam > Commit... をクリックします。

Git tracks all changes made to the entire repository capturing the modifications of all version-controlled files in that repository not regarding if these files reside in the same Eclipse project or not.

一旦コミットを起動すると、Commit Dialog がポップアップするでしょう

コミットしたい変更を選択し、コミットをメッセージを入力します。コミットを作成するにはコミットメッセージのテキストフィールド内でCtrl+Enter (Mac OS XではCommand+Enter)を押すか、Commitをクリックします。

コミットメッセージ

ステージング ビューあるいはコミットダイアログ内で変更を説明するコミットメッセージを指定します。

変更を要約した最初の短い行の後に空行が続き、それからメッセージの本文を持つメッセージを始めることは、良い練習です。In order to ensure that also git command line tools can format these messages nicely the lines shouldn't be formatted too wide (this is indicated by a grey vertical line).

コミットメッセージのテキストはEclipseスペルチェッカーによってエラーをチェックされます。スペルチェッカーはEclipseの Preferences > General > Editors > Text Editors > Spellingによって設定することができます。綴りのエラーを修正するのに役立つかもしれないクイック フィックスを開くには Ctrl+1 を押します。

コミットメッセージ エディタはコミットダイアログのファイルの部分で示されるファイル名についてコンテントアシストをサポートします。これは Ctrl+Space を押すことで有効化することができます。

フッター タグ
コミットメッセージの最後の段落(つまり、最後の改行の後)に、任意のフッタータグが続くかもしれません:

Bug: 3176
Change-Id: I267b97ecccb5251cec54cec90207e075ab50503e
Reported-by: Joe Developer <joe@dev.org>
Signed-off-by: William Shakespeare <will.from@the.past>

これらのタグの意味は、プロジェクトあるいはツールに固有です

• もしコミットされた変更についてバグ追跡システム内のエントリがある場合は、それをバグのタグとしてここに追加することは良い考えです
• Gerrit Code Review uses the Change-Id: footer to correlate different patchsets of a change evolving during the review process towards the finally accepted patch. To generate a Gerrit Change-Id click Compute Change-Id for Gerrit Code Review; the ID will be generated on commit, until then a null Change-Id is shown as a placeholder. With the EGit configuration parameter gerrit.createchangeid set to true the corresponding checkbox in the Commit Dialog is always preselected. このパラメータはレポジトリレベル、システムレベル、あるいはユーザレベルで設定することができます。詳細は レポジトリの設定 を見てください。
• The Signed-off-by: footer is used by many projects to create a formal track record of declarations that the signing author contributed the changes under the project's license and IP rules. This way the IP provenance of a project's evolving code base can be captured on a technical level. 例えば、Linux Kernelプロジェクトで使われるDeveloper Certificate Of Origin を見てください。If the EGit preference Insert Signed-off-by in Team > Git > Commit Dialog is set the corresponding checkbox in the Commit Dialog is always preselected.

コミットする変更を選択

• Staging View内でCommitをクリックすると、ステージされた変更だけがコミットされるでしょうnativeのgitコマンドラインも同じように動作します。全てのステージされていない変更は触れられないままにされ、作業ディレクトリ内に残るでしょう。この機能はファイルのセットに行われた変更を異なるコミットに切り離すためにしばしば使われます。
• Commit Dialog内でCommitをクリックする時に、変更を新しいコミットに含めたいかどうかを決定するために各ファイルの前のチェックボックスを使うことができます。ファイルの前のチェックボックスをクリアすると、このファイルへの変更はコミット内に含まれないでしょう。eclipseのワークスペース内のローカルファイルはその後のコミットでこれらの変更をコミットする機会がある修正をまだ含みます。

1つの例: 最後のコミットでA.java内のバグを修正し、新しいメソッドをB.javaに追加したとします。これらの2つの修正は論理的にお互いに依存しません。従ってそれらを2つの独立したコミット内でコミットしたいかもしれません。この場合、コミットを起動し、コミットされたファイルのセットからB.javaの選択を外し、A.java内のバグ修正のみを説明するコミットメッセージを指定します。最初のコミットが成功した後で、単にコミットを再び呼び出し、現れるダイアログはB.java内の残りの変更を表すでしょう。今度はメソッドの追加を説明するコミットメッセージを指定し、2つ目のコミットを完了します。

コミットダイアログの中で、明示的にバージョン制御に追加されていなかったプロジェクトへ追加されたファイル("Modifying the content" を見てください) は、"Show untracked Files" チェックボックスを選択した場合、コミットダイアログの中にリスト化されるでしょう。リスト内のこれらのファイルの前のチェックボックスを選択すると、コミットボタンを押すとそれらはレポジトリに追加され、コミットされるでしょう。.gitignore ファイルによって除外されているファイルはここには現れないでしょう。そのような追跡されていないファイル以外にレポジトリ内に他に変更がない場合は、デフォルトでチェックボックスShow untracked Filesが選択されます。

コミットの修正

変更をコミットする時に何か失敗したと分かった場合はこれを修正することができます: ステージングビューあるいはコミットダイアログを再び開き、現在のブランチの中で現在のコミットが以前のコミットを "修正" しなければならないことを指定します。新しいコミットは以前のものを置き換えるでしょう。この機能は現在の正しくないコミットが他のレポジトリに公開される前に、現在の正しくないコミットを修正するためにしばしば使われます。

Note: do not amend commits if they have already been published to a shared repository since this may disturb others if they already based their changes on the published change.

修正の例:
タイポを含んでいるファイルに変更をコミットしたとします

変更をコミットした後で、タイポを発見します。このタイポと対応するコミットを訂正するために、ソースファイル内のタイポを単に修正します

そして、ステージングビューあるいはコミットダイアログを再び開き、ツールバー内のAmend Previous Commitアイコンを選択します。

以前のコミット(置き換えたいもの)のメッセージは "Commit Message" フィールドに記入されます。これによりバージョン制御されたファイルの内容内のエラーを訂正するだけでなく、変更を説明するコミットメッセージ内のエラー(例えばタイポ)も訂正することができます。

訂正の別のやり方として、後のコミットとして訂正されたバージョンを単にコミットすることができます。しかし、タイポを含む最初のコミットは誰の役にも立たず、プロジェクトの履歴を不必要なコミットで乱雑にしないために、コミットを修正するべきです。

既に他のレポジトリに公開されたコミットの修正は問題を起こすかもしれないことに注意してください。コミットをリモートのリポジトリにコミットするか、あるいはローカルのレポジトリが誰か他の人にクローンされた場合、コミットの修正にはとても注意する必要があります。この場合、最初のコミットを訂正する2つ目のコミットを公開Iすることが恐らくより良い解決策です。そうでなければ、他の全ての人が相応に反応できるように、公開されたコミットが修正されたことを彼らに知らせます。

変更の戻し

作業ツリー内の変更の戻し

Gitインデックス内のファイルの置き換え

まだコミットされておらず、まだステージされていない変更は、選択されたファイルのセットについて戻すことができます。パッケージエクスプローラあるいは類似しているビュー内のファイル(s)を選択し、Replace With > File in Git Indexをクリックします。

HEADとの置き換え

選択されたファイルをそれらのHEADバージョンと置き換えるには、Replace With > HEAD をクリックします。レオジトリの作業ツリー全体をHEADコミットの状態に強制的に戻すには、オプションhard付きでReset toを使うこともできます (以下の "Resetting your current HEAD" を見てください)。このオプションは作業ツリーとインデックス内の全ての変更を戻すでしょう。

ブランチ、タグあるいはリファレンスとの置き換え

選択されたファイルを対応するブランチ、タグあるいはリファレンスのバージョンと置き換えるには、Replace With > Branch, Tag or Reference をクリックします。

コミットとの置き換え

選択されたファイルを選択されたコミットに対応するバージョンと置き換えるには、Replace With > Commit をクリックします。

以前のリビジョンとの置き換え

Changes that are already staged or even committed can be "reverted" by replacing them with a version from the previous commit. Select a single resource in the Package Explorer or an analogous view and click Replace With > Previous Revision. The repository will determine the last commit that modified the selected resource and offer to replace the workspace resource with the contents of this commit.

This is mainly intended for "removing" single files from a commit (when committing the reverted workspace resources, they are effectively removed from the current commit). Even though this also works on folders and projects, the results of replacing a folder or project with a "previous revision" may be unexpected.

Revert using quickdiff

The quickdiff feature can be used to revert individual changes to a file. You can revert by line, block (se range of changes lines) or selection. Select all text and then Revert selection to revert a whole file.

Reverting changes introduced by a specific commit

Changes which are introduced by a given commit can be reverted by an automatically created new commit on top of the currently checked out commit. The commit which is to be reverted does not have to be checked out for that.

Select the commit in the History View, open the context menu and select Revert Commit. This reverts the changes that the selected commit introduces by creating a new commit on top of the currently checked out commit.

Resetting your current HEAD

Git offers the possibility to reset the HEAD of the current branch to any other commit. It optionally resets the index and the working tree to match that commit. Note that this action affects all files and folders in the entire repository.

You have the option to do a hard reset, a mixed reset and a soft reset.

• soft - the HEAD points now to the new commit, the index and the working tree are unchanged
• mixed - the HEAD points now to the new commit, the index is updated, the working tree is unchanged
• hard - the HEAD points now to the new commit, the index and the working tree are updated

Reset to specific branch or tag

Select Team -> Reset... on a project. This opens a dialog where you can select a branch or a tag.

Reset to a specific commit

Select a commit in the History view and open the context menu. Here you find the entries Hard reset, Mixed reset and Soft reset.

Revert all local and staged changes

This can be done using a hard reset. If you reset to the current HEAD (normally the last commit on your branch) with the option hard you reset the currently checked out branch to this commit and overwrite the working tree and the index with the content of HEAD. You can do this in three ways:

• Select Team > Reset... on a project. In the dialog select HEAD or your current branch and switch the radio button to hard.
• Right click and select Reset... on any branch or tag in the Repositories view. This opens a dialog which lets you decide on the reset type. Choose hard here.
• Open the context menu on the HEAD commit in the history view and select Hard Reset.

Branching

General remarks about branches

Committing changes to a local repository is impractical without using a local branch (see concepts section above). Furthermore, by using several different branches, it is possible to work on different changes in parallel by switching among these branches.

Thus, before starting to change the local repository, the first step is typically to create a local branch. Local branches are "based upon" either a commit or a remote tracking branch.

The second option is recommended when working with remote repositories, as it simplifies the task of synchronizing the local changes with the remote ones by adding so-called "upstream configuration" to the new local branch.

See Branch Creation dialog for more details.

Upstream configuration

Each local branch which is based on a local tracking branch can have some additional configuration indicating the remote repository, the remote branch, and the so-called pull strategy. See Branch Creation dialog for more details.

Typically, this configuration is created automatically when creating the local branch based on a remote tracking branch. However, it can be displayed and edited in the repository configuration or by clicking Show In > Properties on a branch in the Repositories View.

Checking out an existing Branch

From the team menu on a project node:

• Select Team > Switch To... and select a branch name from the list

If there are too many branches the list does not show all of them. In this case

• Select Team > Switch To... > Other...
• On the dialog, select a branch, a tag or a Reference
• Click Ok

From the Git Repositories View

• click Checkout on a branch node
• or double click a branch node

From the History View

• Click Checkout on a commit which has a branch label
• If more than one branch point to the commit a dialog will let you decide which branch to check out.

Creating a New Local Branch

This is always done with the Branch Creation dialog. The newly created branch can optionally be checked out by selecting a check box on the dialog.

From the team menu

• Select Team > Switch To... > New Branch....
• On the dialog, select a branch, a tag or a Reference.
• Click Create Branch....
• The Branch Creation dialog will be opened.

From the Repositories View

• Select Create Branch... on the "Branches" node or on any "Branch", "Tag" or "References" node.
• The Branch Creation dialog will be opened.

From the History View

• Select Create Branch...
• The Branch Creation dialog will be opened

Renaming an Existing Branch

From the Team menu on a Project node

• Select Team > Advanced > Rename Branch...
• On the branch selection dialog, select the branch to rename
• Enter the new branch name and click OK

From the Repositories View

• Open the Git Repositories View
• Select Rename Branch... or press F2 on the branch you want to rename
• Enter the new branch name and click OK

From the History View

• Select Rename Branch... on a commit with a branch label
• Enter the new branch name and click Ok

Deleting a Branch

All the actions below show the same behavior with respect to the following:

• The currently checked out branch can not be deleted
• If deletion of the branch may result in data loss, a warning is displayed that must be confirmed
  • EGit assumes a potential data loss if the branch points to a commit that is not reachable from the currently checked out commit

From the Team Menu on a Project node

• Select Team > Advanced > Delete Branch...
• Select the branch to delete from the dialog being displayed and press Ok

From the Repositories View

• Open the Git Repositories View
• Select Delete Branch on the branch you want to delete

From the History View

• Select Delete Branch on a commit with a branch label
• If multiple branches point to the commit, a selection dialog will be shown on which you can select the branches to delete

Branch Creation Dialog

There are several actions available to create a local branch. All these actions use the Branch Creation dialog:

Enter the name of the local branch you want to create. If a source branch is selected which is a remote tracking branch EGit will suggest to create the new local branch with the same name.

Click Select... to select the source branch the new branch shall be based on. Typically, this is a remote tracking branch, but it could be any branch or commit in the repository (selecting a local branch is not recommended if you are working with a remote repository). If you want to base the new branch on a commit no branch is referring to then click Create Branch... from the commit shown in the History View.

When a source branch is selected you can configure the "upstream configuration" of the new branch which is helpful when fetching and pushing, but particularly when pulling. Depending on the selected option the following configuration can be chosen:

• "Merge upstream commits into local branch": When pulling, the changes will be fetched from upstream and the remote tracking branch will be updated. Then the current local branch will be merged with the new changes. This is the default if the new branch is based on a remote tracking branch (but this default may be overridden by specific repository configuration)
• "Rebase commits of local branch onto upstream": When pulling, new changes will be fetched from upstream and the remote tracking branch will be updated. Then the current local branch will be rebased onto the updated remote tracking branch
• if you uncheck the option "Configure upstream for push and pull"): When pulling, no specific upstream configuration will be done for the new branch; however, if a default remote exists (a remote with name "origin", pull will try to use the configuration of this remote; this is the default if the new branch is not based on a remote tracking branch

You may view and edit the upstream configuration in the repository configuration or by selecting Show In > Properties on a branch in the Repositories View.

EGit also supports the git configuration parameter branch.autosetuprebase, set it to always if you want to use the rebase pull strategy by default. If you set this in the repository configuration this is used for all local branches created based on a remote tracking branch in this repository, if you set it in your user configuration it will be used for all your repositories.

In the lower part, you can decide whether the new branch shall be checked out immediately.

Configure Branch Dialog

Click Configure Branch... on a branch in the Repositories View in order to change the upstream configuration of a local branch. Select which remote ("." means the local repository) and branch the selected local branch should track. Check "Rebase" if you want pull to rebase the local branch onto new changes arriving for the tracked branch, otherwise pull will merge new changes arriving for the tracked branch.

Merging

A merge incorporates changes from another branch or tag, since the time their histories diverged from the current branch, into the currently checked out branch.

Merging a branch or a tag into the current branch

You can trigger merge from:

• the History View
• the Team menu
• the Git Repositories View

Starting merge from the History View

This is the recommended view to start a merge since it shows you the history of your repository. Ensure that the toggle buttons Show all changes in repository and Show all Branches and Tags are selected in the History View's toolbar. This ensures that you see the complete history of your repository in order to decide which branch you want to merge. Select the commit with the branch or tag label you want to merge and click Merge.

Starting merge from the Team menu

In the Package Explorer or Navigator, open the context menu on a project node. Select Team > Merge...

Now the merge dialog opens:

On the dialog, select a branch or a tag you want to merge with your current branch. This dialog also allows you to select merge squash and fast-forward options.

Starting merge from the Git Repositories View

You can trigger a merge from any branch and tag node and from the repository node if you have checked out a local branch. See Merging a Branch or a Tag for further details.

Merge options

The following fast-forward configuration options for merge are recognized by EGit, which are used for all branches:

[merge]
    ff = true|false|only

When you only want to configure it for a certain branch, use the following:

[branch "name"]
    mergeoptions = --ff|--no-ff|--ff-only

fast-forward options

ff = true or mergeoptions = --ff 

When the merge resolves as a fast-forward, only update the branch pointer, without creating a merge commit. これはデフォルトの挙動です。

ff = false or mergeoptions = --no-ff 

Create a merge commit even when the merge resolves as a fast-forward.

ff = only or mergeoptions = --ff-only 

Refuse to merge and abort the merge operation unless the current HEAD is already up-to-date or the merge can be resolved as a fast-forward.

When you start merge from the Team menu "Team > Merge..." you can set the fast-forward, squash or no-commit merge options in the merge dialog:

Possible merge results

After pressing the Merge button, the following scenarios can occur:

• Already up to date: Your current branch points to a commit that has the selected branch or tag as predecessor. In this case nothing is changed.
• Fast-forward: Your current branch points to a commit that is a predecessor of the selected branch or tag. In this case your branch is moved and points to the selected branch or tag; this new HEAD is checked out to the working tree. Fast-forward is very common when working with remote repositories: When a remote tracking branch is updated, the merge with the corresponding branch generally is a fast-forward. You can perform a pull by fetching the remote branch (e.g. origin/master) and merging it into the corresponding local branch (e.g. master).
• Real merge: When neither of the conditions above apply egit triggers a merge of the commits. There are two possible outcomes: If no conflicts occur the current branch will point to a newly created merge commit; if conflicts occur the conflicting files will be marked with label decorators (see Resolving a merge conflict for further actions in case of merge conflicts).

Merge Result dialog

The result of a merge is summarized in a dialog:

On the first line you see the result of the merge. The possible results are "Already-up-to-date", "Fast-forward", "Merged", "Conflicting" or "Failed". A possible reason for "Failed" may be that there are conflicting changes in the working directory.

On the second line you see the new HEAD commit in case of a successful merge (Already-up-to-date, Fast-forward or Merged).

In the table you see the commits which were merged.

Resolving a merge conflict

A merge can result in conflicts which require user action. This is the case when the content of files cannot be merged automatically. These conflicts are marked with a label decoration in the Staging View. Using the Staging View to find the files with conflicts in order to resolve them is handy since the Staging View shows only modified files so that you don't have to wade through all of your resources but only those which might need your attention for resolving the conflicts.

Also the conflicting resources are decorated in the navigation trees like Project Explorer or Package Explorer views

The merge conflicts in the content of files are presented with textual conflict markers (see http://www.kernel.org/pub/software/scm/git/docs/git-merge.html#_how_conflicts_are_presented for more details).

Using Merge Tool

• select the top level resource showing the red conflict label decorator
• click Team > Merge Tool
• select the merge mode Use HEAD (the last local version) of conflicting files and click OK

• the merge editor opens showing the working tree version in the left pane and the version to be merged in the right pane

• edit the working tree version until you are happy with it
• Team > Add the merged resource to mark the conflict as resolved
• commit the merge commit via Team > Commit

Manual conflict resolution

To resolve a conflict you have to do the following steps:

• Navigate to the conflicting resource
• Edit the content of the conflicting resource
• Tell EGit that the conflict is resolved with Team > Add
• Commit the conflict resolution with Team > Commit

Finding conflicting files

A repository which contains conflicting files has the textual label decorator "|Conflicts" attached to the repository name. Conflicting resources and folders containing such conflicting resources get a conflict label decoration.

Alternativley, it's easy to find a list of all conflicting files in the staging area. Open the Git Staging view. The conflicting files with decorators will be seen on the left.

Editing conflicting files

In the file content, the area where a pair of conflicting changes happened is marked with markers <<<<<<<, =======, and >>>>>>>. The part before the ======= is typically your side, and the part afterwards is typically their side (see http://www.kernel.org/pub/software/scm/git/docs/git-merge.html#_how_conflicts_are_presented for more details).

Open the file in an editor, edit the content and save the editor.

Note that this step is not mandatory. EGit does not check the content to decide if a conflict is resolved. The next step is the relevant one.

Adding conflict resolution to the git index

Once you are finished with editing a file either click Add to Index in the Staging View or click Team > Add to add the conflict resolution to the git index. This will also mark the corresponding conflict as resolved.

When you have resolved all conflicts the textual repository label decoration changes to "Merged". There are no conflict markers anymore.

Committing a merge

When the repository is in state "Merged" (as is indicated with the textual label decorator "|Conflicts" attached to the repository name) the merge can finally be committed.

In the Staging View you may want to remove the conflict remarks from the standard merge commit message which is generated by the merge operation and update the commit message if necessary. Then click Commit in order to commit the conflict resolution.

If you want to use the Commit Dialog to commit the conflict resolution click Team > Commit... anywhere in the navigation tree. The commit dialog opens with a slightly different look compared to a normal commit:

• The Commit message area is prefilled with a standard merge commit message.
• It is not possible to amend a previous commit.
• It is not possible to add untracked files.
• it is not possible to uncheck the checkboxes. This guarantees that all resolved conflicts are committed.

After pressing the "Commit" Button the merge is completed.

Aborting Merge

If a merge resulted in conflicts you can abort the merge with a hard reset to the current branch. This can be done in state "Conflicts" and in state "Merged", i.e. before and after you have resolved the conflicts.

The hard reset can be done from the team menu, the Git Repositories View or the History View. See Revert all local and staged changes for more details.

Rebasing

Rebase Introduction

Rebase applies a chain of commits onto a given commit. A typical scenario is the development of some feature on a "topic" branch which was created from a "master" branch at some point in time. When "master" is updated with changes e.g. from other developers while "topic" is still under development, it may become necessary to incorporate these changes into "topic".

Let's assume we start development on "topic" by creating the "topic" branch from master. At this point, both "master" and "topic" point to commit "E". When the first commit ("A") is added to "topic", the commit history of the repository looks like this:

 A topic
 /
 D---E master

Now, let's assume that there were some more commits on "topic" and as well some more commits on "master" (for example, "master" may track some remote repository and there were some changes in that remote repository that have been pulled into "master"):

 A---B---C topic
 /
 D---E---F---G master

Now, in order to incorporate the changes in "master" into "topic", a Rebase of "topic" onto "master" would produce

 A'--B'--C' topic
 /
 D---E---F---G master

Technically, the sequence of commits that are contained in "topic" but not in "master" are applied (that is, cherry-picked) on top of "master" one by one.

Note that the commits A, B, C are neither lost nor changed, instead a new chain of commits A', B', C' with the same changes and commit messages as the original commits (but different commit IDs) will be created. The old commits A, B, C are still around in the object database but not visible anymore as they are no longer reachable from any branch. A', B', C' are different from the old ones as they now also contain changes F and G.

Rebase, A Simple Example

Let's have a look at some simple example: we have a text file "FamousWords.txt" which initially might have some content like

Chapter 1
Once upon a time...

Chapter 2
To be or not to be

Now, in "topic", two commits are created, the first one adding a French translation to Chapter 2, and another one adding a German translation:

After first change in "topic":

Chapter 1
Once upon a time...

Chapter 2
To be or not to be
Être ou ne pas être

After second change in "topic":

Chapter 1
Once upon a time...

Chapter 2
To be or not to be
Être ou ne pas être
Sein oder nicht sein

At the same time, the file was changed in "master" by adding two commits adding French and German translations to Chapter 1:

Chapter 1
Once upon a time...
Il était une fois
Es war einmal

Chapter 2
To be or not to be

The commit history looks like this:

Now, if "topic" is rebased onto "master", the two changes in topic are applied in the same sequence as they were applied during the evolution of "topic".

The result is a merged version of "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

and a commit history with the commit history of "topic" on top of the current "master":

The Real World: Rebase Conflicts

Up to now, we have assumed that the changes in "topic" can be auto-merged into "master". In the real world, however, it may happen that you encounter conflicts during rebase. Now, if a commit that is to be cherry-picked contains changes that conflict with changes in "master", the rebase operation is interrupted after applying the conflicting change; the conflicts are visualized in the usual way (with conflict markers) and the user gets a chance to decide whether to

• resolve these conflicts manually,
• skip the current commit, or
• abort the rebase completely

If Resolve Conflicts is chosen, and the conflicts have been resolved manually, the changes must be "Added", and then rebase can be resumed, i.e. the next commit in the chain will be applied.

If Skip was chosen, the conflicting changes will be reverted and the next commit in the chain will be applied.

If Abort was chosen, the rebase operation will be completely rolled back, returning the Repository into its original state before the rebase was started. This process is repeated until the last commit was applied successfully or skipped. Finally, the "topic" branch will be changed to point to the last commit.

To understand "Skip" better, let's look back to the introduction above. If we assume that commit "B" causes some conflicts with the current "master", the user might decide to simply skip "B"; the new commit history after the rebase would then look like this:

 A'--C' topic
 /
 D---E---F---G master

Starting Rebase

In the History View:

• Checkout the branch you want to rebase
• Select the commit onto which you want to rebase the checked out branch. This commit will become the new base for all commits being rebased
• Click Rebase

In the Git Repositories View: On Repository nodes, Rebase... opens a dialog asking the user to select a branch that is not checked out; the currently checked out branch will then be rebased onto the selected branch. On "Branch" nodes (both Local and Remote Tracking branches, but not on the currently checked out branch), Rebase immediately rebases the currently checked out branch onto the selected branch:

Rebase Confirmation Dialog

If Rebase was successful, a confirmation dialog will be displayed; this dialog can be suppressed by ticking a checkbox; a preference on the Git preference page allows to make the dialogs appear again. If the dialog is suppressed, an "Information" message is written to the Eclipse log instead.

Rebase Conflicts

If a conflict occurs during rebase, a dialog is shown giving some information about the commit that caused the conflict. By selecting a radio button, you can decide whether to

• Start the Merge Tool to resolve the conflicts manually
• Skip the current commit
• Abort the rebase altogether
• Do nothing (return to the workbench), this is equivalent to hitting "Escape":

Unless Skip or Abort was chosen in the dialog, the conflicts must be resolved manually by editing the conflicting files. When done with editing, the files must be declared as being resolved by adding them to the git index.

If you canceled the rebase wizard the easiest way to find the files with conflicts is using the Staging View. Click Merge Tool on the file with conflicts to open the merge tool for this file. The Merge Tool can also be started from the corresponding entry in the Team menu.

Edit the file until you are happy with the conflict resolution and click Add to Index on the corresponding entry in the Staging View. This stages the conflict resolution and marks the conflict resolved.

After all conflicts have been resolved, the Continue operation gets enabled. In order to continue the rebase operation which was stopped due to conflicts click the Continue button in the Staging View or click Rebase > Continue on the repository node in the Repositories View.

If instead of resolving conflicts you want to skip the commit which caused the conflicts click Skip instead.

If you want to abort the ongoing rebase operation click Abort. This reverts everything to the state before you started rebase.

Aborting Rebase

As long as the Repository is in "Rebasing" state, the user can always abort the rebase in the Git Repositories View using the menu action "Rebase > Abort" which is available on the Repository node.

Interactive Rebase

概要

Interactive rebase allows to quickly edit a series of commits using the following actions defined in a rebase plan:

• pick to define the order of commits, moving pick entries enables reordering
• skip to remove a commit
• edit to amend a commit
• reword to edit a commit's message
• squash to squash a commit with its predecessor commit and including their commit messages
• fixup to squash a commit's diff into its predecessor discarding the squashed commit's message

Warning: don't rewrite commits you have already published on a remote repository, it's considered a bad practice for all but experimental or review branches since your colleagues may have already based their work on these published commits and you would force them to also rewrite their changes. Though it's a tool frequently used on review branches e.g. when using Gerrit to rework changes which have to be improved based on review feedback.

Starting interactive rebase

First checkout the local branch (here branch toRebase) containing the commit series you want to edit. Then open the History View for this repository and click Interactive Rebase on the commit preceding the oldest commit you want to rewrite. Often this is the one origin/master points at.

This opens the new view Git Interactive Rebase showing the rebase plan populated with the commits to be modified in topological order in the sequence they will be processed during the rebase operation. The initial action for all commits is Pick which would cherry-pick the corresponding commit. Note that EGit also rewinds HEAD to the commit preceding the first one in the edit list in order to prepare the repository for rebasing.

Planning rebase

Here the initial rebase plan, the first commit to be applied on the rewound HEAD comes first and then all the other commits to be rebased in the order they will be applied when clicking "Start".

Next we prepare the rebase plan, moving commits up and down using the arrow buttons to reorder commits and choosing the rebase action we want to apply on the commits we want to tweak.

In this example I first reordered the commits so that the implementation of new calculator operations immediately precedes the commit implementing tests for the respective operation.

Here what I want to modify in this series of commits:

I want to skip commit "TODO list" since it contains a private todo list I used while implementing the operations and I don't need this anymore. I need to amend commit "Add divide operation" since it's buggy, this was revealed by the corresponding test which was implemented in a later change, hence I select action Edit here the commit "Add multiply opration" obviously has a typo in the commit message header so I choose Reword. I want to squash commit de7647b into its predecessor since it doesn't make sense to have the JavaDoc fix separate from the implementation of what it describes, hence I choose Squash to squash it with its predecessor.

Executing interactive rebase

When you're done planning the rebase click Start to start execution of the rebase command. EGit will process the plan and stop at the commits where you have selected actions which need your intervention to interactively edit the corresponding commit.

In our little example rebase stops the first time on commit "Add divide operation" since we signaled that we want to edit it. The last picked commit is highlighted in bold. At this time the first step skipping the commit "TODO list" was already processed and this commit is no longer in our commit series we are rewriting while executing rebase. Also the commit "Add divide operation" was already cherry-picked since we want to amend it. Note that EGit has already selected the "Amend" option in the Staging View in order to prepare amending this commit.

Now we fix the bug in this commit, stage the changes needed to fix the bug, adjust the commit message if necessary and click Commit in order to amend the buggy commit.

Let's have a look at the History View to see the resulting commit graph. HEAD now points at the rewritten fixed commit "Add divide operation", note that its SHA1 is different from its original version since we rewrote the commit to fix the bug.

Next we click Continue in order to resume processing the rebase plan. Rebase picks the commits "Divide test" and "Add multiply opration" and stops again raising a commit message editor so that we can fix the typo in the commit message of the latter commit.

Edit the commit message to fix the typo and click OK in order to amend the commit message and resume processing.

Rebase picks the next 3 commits, squashes the commits "add power" and "Fix javadoc for power operation" into one new commit and stops again so that we can prepare the commit message of the new commit. Its initialized with the concatenation of the messages of the commits being squashed.

Edit the squashed commit's message and click OK to resume processing.

Rebase picks the final commit "Power test" and completes successfully.

Finally lets have another look in the History View to examine the result of the interactive rebase command. Compare the rewritten series of commits now contained in branch "toRebase" with the old commit series still visible since I have placed another local branch "start" there in order to keep the old series visible.

Safety Instructions

If you happen to go wrong during this multi-step process you can always hit Abort in order to stop the rebase operation in progress and roll back to the starting point.

When you are starting to use this feature it's maybe a good idea to place a second local branch on the starting point (as I showed in this example) to make it more obvious what's going on until you are familiar with this powerful git command.

Rebase with auto-stashing

EGit also supports the Git configuration option rebase.autostash. Set this option rebase.autostash = true to automatically create a temporary stash before a rebase operation begins, and apply it after the operation ends. This means that you can run rebase and also interactive rebase on a dirty worktree. However, use with care: the final stash application after a successful rebase might result in non-trivial conflicts.

Cherry Picking

Cherry-pick Introduction

A given commit C on branch stable-1.0 contains a set of changes you would like to integrate in your current development on branch master.

 A--B--C--D stable-1.0
 /
 D---E---F---G master HEAD

Cherry-pick the commit C to create a new commit C' on top of the head commit of the currently checked out branch master. C' will then contain the changes performed in C applied onto the HEAD of the currently checked out branch master.

 A--B--C--D stable-1.0
 /
 D---E---F---G--C' master HEAD

Cherry-pick Example

You are currently working on branch "feature2" (HEAD). There is a commit "feature 1" in another branch.
You want to integrate the changes performed by commit "feature 1" into your current development on branch "feature 2".

• In the History View select commit "feature 1" and click Cherry-pick:

• As result you get a new commit "feature 1" at the tip of your current branch "feature" containing the changes of "feature 1":

• Cherry-picking can encounter conflicts. In this case conflict markers are rendered into the affected sources:

• Open the Staging View to quickly find the conflicting files.
• Click Merge Tool on a file with conflicts to open the merge tool for this file
• Resolve the conflicts by editing the corresponding sources in the same way as described in Resolving a merge conflict
• Add the files you edited to mark the conflicts resolved
• Commit the conflict resolution

Tagging

Creating a Tag

• Open the History View and click Create Tag... on the commit you want to tag

• Enter the tag name
• Enter the tag message
• Click OK to create the annotated tag

Tags can also be created from the team menu, click Team > Advanced > Tag..., enter the tag name and message, select the commit you want to tag (default is HEAD) and click OK.

Replacing an Existing Tag

What to do if you tagged the wrong commit or ended up with some sort of typo ?

• If you didn't yet push this out just replace the tag and you are done.
• If it's already published you shouldn't replace the tag but use a new name since otherwise you have to tell everybody who got the old tag to replace it manually with your updated one. This is because, Git does not (and it should not) change tags behind users back. So if somebody already got the old tag, doing a git pull on your tree shouldn't just make them overwrite the old one.

So if your old tag wasn't yet pushed you may correct it in the following way :

• In the History View click Tag... on the commit you want to place the tag on

• Select the tag you want to replace from the list of existing tags
• or start typing any part of the tag you look for into the Tag Name field, this will filter the list of existing tags to those tags which contain the string you are typing, then select the tag you want to replace
• Mark the checkbox Force replace existing tag
• Change the tag and press OK

Deletion of tags

In order to delete a tag, select the tag to be deleted and click Delete Tag.

Note: it's a bad practice to delete tags which have already been published on a public server, some Git servers even disallow tag deletion to ensure traceability for releases which are usually tagged. Also see the section "On re-tagging" in the Git reference documentation of the tag command.

Light-weight and Signed Tags

Light-weight tags are shown in the Repositories View as well as in the Create Tag dialog, but can not be edited. Tags are shown with a blue icon in the Repositories View, annotated tags are decorated with a yellow person.

In the History View, tags are shown as yellow labels.

Signed tags are not yet supported by EGit, use command line git tag -s instead.

Patches

Creating Patches

"A patch is a piece of software designed to fix problems with, or update a computer program or its supporting data" (wikipedia). A patch file contains a description of changes of a set of resources which can be automatically applied to another eclipse workspace or git repository.

The patch formats used by eclipse (Team > Apply Patch) and by git (git apply or git am on the command line) are different. It is possible to create both types of a patch in EGit.

Create a Patch from a Commit

This is the most common use case for a distributed versioning system. A developer commits a change on a local feature or bugfix branch and wants to export this change into a patch file.

It can be done from the history view:

The patch file will contain the difference between the commit and its parent in the history view. Note that the filter of the history view applies also for patch creation.

Patch Wizard

The Wizard consists of two pages. Page one lets you select the location of the patch:

The name of the patch file is created from the first line of the commit message.

On the second page you can change the patch format.

Currently there is one check box: Export in git patch format.

• If you do not check it (this is the default) the patch can be applied with the eclipse Apply Patch... wizard. The paths are relative to the eclipse projects and do not contain prefixes (like git format-patch --no-prefix on the git command line).
• If you check it the patch will look like the result of git format-patch --no-stat on the git command line.

Binary diffs are currently not produced.

Applying Patches

Currently EGit isn't able to apply patches in git format. It is possible to apply patches using the standard Eclipse (unified diff) format using Team > Apply Patch.... Git patches may contain non-standard extensions for rename and binary diffs. The current version of EGit does not generate these extensions.

Managing Repositories

The "Git Repositories View" is the primary UI element to facilitate working with multiple Repositories simultaneously (i.e. within one Eclipse Workspace).

This view can be opened using the menu path
Windows > Show View > Other... > Git > Git Repositories

It is also part of the "Git Repository Exploring" perspective available using menu path
Window > Open Perspective > Other... > Git Repository Exploring

If you already have projects in your workspace which are shared with a Git Repository, you can use
Team > Show in Repositories View

on any resource to open the view.

Adding Repositories to the Git Repositories View

Initially, the Git Repositories View is empty. In order to add Repositories to it, there are several options:

1. Adding a Repository from the Local File System manually
2. Cloning a Repository and having the cloned Repository added to the view automatically
3. Creating a Repository on the Local File System
4. Adding a Repository by pasting a Git Repository path to the view

Adding a Repository manually

You can add a Repository from your local file system to the Git Repositories View without cloning it. This can be helpful if you are setting up a new Eclipse workspace and want to re-use your Git Repositories. Use the Add an existing Git Repository button from the view's toolbar:

A dialog will appear prompting you for a directory of your local file system. After selecting the correct directory, you can hit the Search button to see a list of Git Repositories in this directory. You can then select some or all found Repositories and add them to the view using OK:

リポジトリのクローン

In order to clone a Repository, refer to Cloning remote Repositories. After a successful clone operation, the newly cloned Repository should appear in the Git Repositories View automatically.

You can also use the Clone a Git Repository button from the view's toolbar to start the Clone wizard:

Please refer to Cloning remote Repositories about how to use the wizard.

Creating a Repository

You can create a new, empty repository on the local file system. This is useful if you later on want to create one or more new projects below this repository. Another usecase is to create a new bare repository where you can push to. Use the Create a new Git Repository button from the view's toolbar:

A dialog will appear which lets you choose a directory:

If you select the checkbox Create as Bare Repository the new repository will not have a working directory. You then can only add content by pushing changes from another repository.

Adding a Repository using Copy and Paste

As a shortcut, it is also possible to paste the local file system path of a Git repository from the clipboard into this view. In order to do so, copy the path of a Git repository (the full path of its .git folder) to the clipboard, then open the context menu on the view panel:

or click Edit > Paste from the main menu (or the corresponding keyboard shortcut). If the clipboard content is not suitable, an error popup will be displayed, otherwise the added Repository should appear automatically.

After the view has been populated with some repositories, it should look like this:

Removing Repositories

Removing a Repository from the Repositories View

In order to remove a repository from the Repositories View select a repository and click "Remove Repository"

Deleting a Repository

In order to delete a repository, select it in the Repositories View and click "Delete Repository".

Then confirm that you want to delete the repository and decide if you want to delete the repository's working directory with the projects contained in the repository from the Eclipse workspace.

Structure of the Git Repositories View

The following screenshot shows the topmost two levels of the Git Repositories View:

The root node represents the Repository itself. The node text indicates the name of the Repository and its location in the local file system. The "Branches" and "Tags" nodes allow browsing and manipulation of tags and branches. The "References" node lists other references which are not branches or tags, most notably the "HEAD" and "FETCH_HEAD" symbolic references (see Git References).

The "Working Directory" node displays the location and structure of the working directory on the local file system (only in case of a development, or non-bare Repository, for bare Repositories, this node is always a leaf).

Finally, the "Remotes" node allows browsing and manipulating the remote configurations used for Fetch and Push.

Functions of the Git Repositories View

Project Import

In order to work with the contents of a Git Repository, its files and folders must be imported into the Eclipse workspace in the form of projects. While the Git Clone wizard allows to do such imports directly after cloning, the Git Repositories View allows to trigger project imports independently of the clone operation.

The "Import Projects..." context menu is available on the "Repository" node as well as on any "Folder" node within the "Working Directory" node and the "Working Directory" node itself:

The rationale for offering the Import Projects... action on several nodes is that some of the wizards used for importing projects can take the file system directory into account, for example the Import Existing Projects wizard. If the import is started from the "Repository" or the "Working Directory" node, the working directory of the repository is set as context, otherwise the directory corresponding to the currently selected "Folder" node.

The details of project import are discussed in Use the New Projects Wizard.

Branch and Tag Support

The "Branches" node allows to create, browse, checkout and delete local and remote branches. The "Tags" node allows to browse and check out tags. Both the "Branches" node and the "Tags" node allow to merge the branch or tag into the currently checked out branch and also to synchronize with the currently checked out branch.

For better readability, branches are organized in two sub-nodes for local and remote branches, respectively, and only the shortened names are displayed, e.g. instead of "refs/heads/master" you would find an entry "master" under the "Local Branches" node, instead of "refs/remotes/origin/master" the shortened name "origin/master" is displayed under the "Remote Branches" node. Similarly, tag names are shortened by omitting the "refs/tags/" prefix:

Check-out of Branches and Tags

Branches and tags can be checked out by either double-clicking on the respective node or by selecting the corresponding context menu entry.

Creation and Deletion of Branches

Local branches can be created using the Branch Creation Dialog. The wizard is opened by right-clicking on the "Branches", the "Local Branches" on any "Branch" and "Tag" node).

Branch deletion is done using the corresponding context menu entry.

Rebasing

You can trigger rebasing of the currently checked-out branch onto another branch by right-clicking Rebase on any (local or remote tracking) branch node.

Merging a Branch or a Tag

You can trigger a merge from any branch and tag node and from the repository node if you have checked out a local branch. See Merging for further details of the merging features.

• When you select any branch node other than the currently checked out branch or any tag node, use Merge to directly trigger a merge into the currently checked out branch.

• When you select the repository node or the currently checked out branch, use Merge... to open the merge dialog. The merge dialog is described at Merging a branch or a tag into the current branch.

Synchronizing with a Branch or a Tag

You can perform a comparison of the changes in your HEAD with the changes done in any other branch or tag. Right click and select Synchronize... on any branch or tag. Then the eclipse synchronize view opens which contains a representation of the changes that are contained in your HEAD but not on the other branch or tag (outgoing change) or vice versa (incoming change). Please refer to the documentation of the synchronize feature for further details.

Determining the Checked-out Branch

There are two ways to determine which branch or tag is currently checked out: the checked out branch/tag node is decorated with a little check mark and the "HEAD" entry under the "Symbolic References" node shows the (full) name of the checked out branch:

Resetting to a Branch or a Tag

Right click and select Reset... on any branch or tag. This opens a dialog which lets you decide on the reset type. See Resetting you current HEAD for further details.

"Detached" HEAD

If HEAD is "detached", i.e. is not pointing to the tip of a local branch but to a commit or tag, then none or several "checked-out" markers may appear in the tree, since any number of remote branch or tags may point to the currently checked out commit. The state you are in while your HEAD is detached is not recorded by any branch (which is natural --- you are not on any branch).

Inspecting References

The References node displays some References other than branches and tags (the list is dynamic and depends on the current state of the Repository):

If the Reference is symbolic, i.e. points to another Reference, the name of the target reference is shown, followed by the object ID of the reference's target. If the Reference is not symbolic, only the object ID is shown.

In the example above, HEAD is a symbolic Reference pointing to branch "refs/heads/master" (i.e. branch "master" is checked out", while FETCH_HEAD points directly to commit 226a7f... .

The following actions are available on right-clicking on a Reference: Checkout (unless the Reference is already checked out) and Create Branch'...' .

Browsing the Working Directory

The "Working Directory" node visualizes the local file system structure of the Git Repository. It is also possible to open a text editor on the files:

Alternatively, files can be opened by dragging them from the Working Directory to the Editor Area.

Also, on all file and folder nodes as well as on the "Repository" node, an option is offered to copy the (file-system specific) path to the clipboard. This is sometimes useful when the path is needed, for example to open a directory using a file browser or to copy and paste Repositories between view instances (see above about how to add Repositories to the view). The Copy to Clipboard action is also available using Edit > Copy (or the corresponding keyboard shortcut).

Repository Configuration

Integration with the generic "Properties" view in Eclipse allows to view and edit the Git Configuration (global and repository-specific configuration). If the "Properties" view is open, it is updated automatically when a "Repository" node is selected. With a drop down box (left red box in the screen shot) you can switch between the display of the Repository Configuration, the Global Configuration and a view which aggregates both. If the view displays the Repository Configuration or the Global Configuration you can open an editor dialog with the Edit button (right red box in the screen shot). The editor dialog has the same functionality as the preference page Team > Git > Configuration.

In the Git Repositories view, there is a Properties action in the context menu, which will open a configuration dialog allowing to edit the Repository Configuration. Here, key value pairs can be added, changed or deleted. The Open button allows to open the Repository Configuration file in a text editor.

Remote Repositories

The "Remotes" node allows for browsing and editing Remote configurations. Each Remote configuration has a name and either a Push Specification, a Fetch Specification, or both. If a "Remote Configuration" node or any of its children is selected, the Properties view will show a summary of the Remote configuration. In this example: there is a Remote configuration named "origin" which only has a Fetch Specification, but no Push Specification:

Menu actions are provided to add, configure, and remove Remote configurations and Fetch and Push Specifications.

Direct Fetch and Push Support

It is possible to execute fetch and push directly (i.e. without a wizard) on the remote node as well as on the respective "Fetch" and "Push" nodes:

Note that the fetch or push operation will be executed immediately in an asynchronous job; on completion you will get a confirmation pop-up displaying the fetch result.

The "Fetch" node contains a so called fetch specification and the "Push" node contains a so called push specification.

A default fetch specification is created when the repository is cloned. You can edit the fetch specification with the menu entry Configure Fetch.... This opens a wizard. On the first page you can edit the Fetch URI. Ob the second page you can determine the fetch ref specifications, see Fetch Ref Specifications.

You can create or edit a push specification with the menu entry Configure Push.... This opens a wizard. On the first page you can edit the Push URIs. If a fetch is specified the fetch URI is automatically included into the push specification and no additional Push URI is needed. On the second page you can determine the push ref specifications, see Push Ref Specifications.

Adding a Remote Configuration

This is done using a context menu action on the "Remotes" node. A wizard is started asking for the name of the new configuration and whether to configure Fetch, Push, or both:

If the Configure Fetch checkbox was selected, the next wizard page will ask for the URI of the Repository to fetch from:

Click Change... to open a dialog that allows you to select a URI. The next step is to define the Remote Specification for the fetch URI. See Fetch Ref Specifications about the details.

If the Configure Push checkbox was selected, the next wizard page will ask for the URIs of the repositories to push to. This is actually a list, as you can push to multiple repositories at once. Click Add.... to add URIs to the list using the same dialog as above. You can remove URIs by marking them in the list and hitting Remove. This step is completely optional if there is already a fetch URI defined. In this case, the fetch URI will also be used for push. If at least one push URI is defined in this steps, it will override the fetch URI. In this example, there is already a fetch URI, so the Next button is enabled, even though there is no Push URI in the list:

The next step is to define the Remote Specification for the push URIs. See Push Ref Specifications about the details.

Upon completion, the new Remote configuration will be visible:

Changing Remote Configurations

It is also possible to add, remove, or change Fetch/Push Specifications for an existing Remote configuration using the context menu.

Gerrit Configuration

If you work with Gerrit Code Review as remote repository server you can

• specify the push configuration used to push changes to code review
• specify the fetch configuration to fetch the review notes from Gerrit
• configure your repository to select the Compute Change-Id for Gerrit Code Review option in the Commit dialog by default

Select Gerrit Configuration... from the context menu of a Remote. This opens a wizard with one page:

• When you click Finish the wizard sets the repository configuration parameter gerrit.createchangeid to true. This ensures that the checkbox Compute Change-Id for Gerrit Code Review in the Commit dialog is selected by default. See Commit Message for details.

• If you want to configure automatic Change-Id insertion at a later point in time you may use the repository configuration editor (Preferences > Team > Git > Configuration) to set the configuration parameter gerrit.createchangeid to true. If you want this configuration for all your repositories you may put it into ~/.gitconfig then you don't need to repeat this configuration for every new repository you happen to work on.

• Additionally the wizard adds a refspec "refs/notes/*:refs/notes/*" to your fetch specification. Gerrit stores data about the review in git notes. With this refspec these review data will be fetched automatically when you fetch from this remote and they will be displayed in the commit viewer.

• In the section Push URI you can configure the URI which is used for the default push configuration. It is pre-filled depending on the URI you are cloning from. If you clone with the git protocol, the protocol is automatically changed to ssh, and the default Gerrit ssh port 29418 is automatically added. For protocols which require a user there is a user field for convenience.

• The section Push Configuration has one field, Destination Branch. Here you should enter the name of the target branch where changes accepted in the Gerrit code review workflow will be submitted to. This yields an entry HEAD:refs/for/<branchname> in the push configuration of the remote you specified in the clone wizard.

• Repositories which have been configured for Gerrit are displayed with the green Gerrit decorator

Refresh

The view is auto-refreshed periodically. The Refresh button in the toolbar allows to trigger an immediate refresh:

Link with Selection

If the Link with selection toggle is enabled, the file or folder corresponding to the current workbench selection will be displayed automatically:

Link with Editor

If the Link with editor toggle is enabled, the file or folder corresponding to the currently active editor will be displayed automatically:

Hierarchical Branch Layout

If the Hierarchical Branch Layout toggle is enabled, branches will be shown in a hierarchical layout using slash (/) as hierarchy separator:

This can be helpful for organizing large numbers of branches.

Bare Repositories

"Bare" Git Repositories (as opposed to "development" or "standard" Repositories) have no working directory by definition, so all actions related to the working directory (check-out, project import, browsing the working directory) are not available for such Repositories. The "Bare-ness" of a Repository is visualized on the "Working Directory" node, which is always a leaf:

Bare repositories are only changed by pushing changes to them.

Removing Repositories from the Git Repositories View

This is offered as a menu action on the "Repository" node. Note that this does not delete the Repository, but just removes the node from the view. If there are projects in the workspace which are located in the working directory of the Repository, the user will be prompted to confirm deletion of these projects from the Eclipse workspace.

Showing Repository in Related Views

Show in History

The command Show in > History will open the History View showing all changes in the selected repository.

Show in Reflog

The command Show in > Reflog will open the Git Reflog view showing the Git reflog of the selected repository.

Show in Properties

The command Show in > Properties will open the Properties view showing the properties of the selected repository.

Working with Tasks

Since EGit 0.11 a first integration with Mylyn is available to support working with task repositories.

インストール

You need to install the feature "EGit Mylyn" to use the EGit Mylyn integration. This requires also Mylyn to be installed.

Commit Message Template

• Configure the Mylyn commit message template under Preferences > Tasks > Team and edit Commit Comment Template.
• Use the following variables as well as any text to alter the commit message.
  • connector.task.prefix, repository.kind, repository.url, task.assignee, task.cc, task.description, task.id, task.key, task.keywords, task.lastmodified, task.notes, task.priority, task.product, task.reporter, task.resolution, task.status, task.summary, task.type, task.url, task.completiondate, task.creationdate, task.reminderdate

• Before committing your change activate the corresponding Task using the Mylyn UI.

• When launching the commit dialog EGit will pre-populate the commit message using the commit message template.

See the Mylyn User Guide for more information how to work with tasks.

Viewing Commits

The Egit commit viewer allows commits to be opened in the Eclipse editor area.

The EGit commit viewer displays the following commit information:

• Commit tab
  • Links to open parent commits
  • 作者
  • Committer
  • Message
  • List of tags pointing to this commits
  • List of branches that the commit exists on

• Diff tab
  • Text viewer with the output of the file differences
  • The colors used in the viewer can be configured from the Preferences > General > Appearance > Colors and Fonts > Git folder

• Notes tab
  • All Git notes for the commit

Tagging a commit

• Select the Create Tag icon from the commit viewer toolbar
  • The Tag dialog will open allowing you to create a tag from the commit.

Creating a branch from a commit

• Select the Create Branch icon from the commit viewer toolbar.
  • The Branch dialog will open allowing you to create a new branch from the commit

Checking out a commit

This checks out the commit displayed in the commit viewer. The commit will be checked out and HEAD will become detached.

Cherry picking a commit

Applies the change introduced by the commit displayed in the commit viewer on top of the currently checked out commit or branch.

Opening the commit viewer

The commit viewer can be opened from the following places:

• History view table context menu
• Double-clicking commits in the Pull/Fetch dialog results table
• Open commit dialog
• Blame annotation popup
• Reflog View

Searching for commits

EGit supports searching for commits.

Git Search page

Commits can be searched from the Git Search tab in the standard Eclipse Search dialog.

This dialog supports searching for text or patterns present in the different fields of a Git commit such as the message, author line, committer line, and the SHA-1 ids of the commit, its parent(s), and the tree associated with it.

Browsing Search Results

Commit search results are displayed in the standard Eclipse Search view. Results are grouped by repository when in Tree mode. Double-clicking a commit from the Search view will open it in the commit viewer.

Launching Git Search

The Git Search page can be opened by selecting the Git Search option from the Search drop-down on the Eclipse toolbar.

Open commit dialog

EGit has an Open Git Commit dialog similar to the Mylyn Open Task and core Open Resource dialogs. The dialog searches every configured Git repository for the branch, tag, or commit SHA-1 entered into the filter box and displays the matching commits.

The dialog can be opened by selecting the Open Git Commit button on the Eclipse navigation toolbar.

Finding the author of each line in a file

EGit supports showing git blame information inside the editor ruler.

Selecting the Team > Show Annotations action on file selections will open the editor and display an annotation ruler with commit and author information for each line in a file. Hovering over the ruler will display a pop-up showing the commit id, author, committer, commit message and the diff applied by this commit on the selected hunk.

The look and feel of the blame annotation editor ruler can be configured from the Revisions sub-menu available from the ruler context-menu.

Click open commit to open the commit in the commit viewer, click show in history to show the commit in the History View. Click show annotations to show annotations of the parent commit of the commit shown in the hover.

Working with Submodules

You can read more about what Git submodules are and how they work in this Git Community Book chapter.

Cloning Repositories with Submodules

Submodules are repositories nested inside a parent repository. Therefore when doing a clone of a parent repository it is necessary to clone the submodule repositories so that the files/folders are available in the parent repository's working directory.

Checking the Clone Submodules button from the Git Clone wizard will clone all submodule repositories after the clone of the parent repository finishes.

Browsing Submodules

There is a Submodules node displayed in the Git Repositories view for repository's that contain submodules.

All submodules in the given parent repository are displayed under this node as well as information about what commit is currently checked out.

Adding a Submodule

You can add a new submodule to a repository by selecting a repository in the Git Repositories view and selecting the Add Submodule context menu option.

The wizard will prompt for the path and URL of the submodule being added. The path entered will be relative to the parent repository's working directory and the URL will be used to clone the repository locally.

Once the wizard is completed the submodule will be cloned, added to the index, and the submodule will be registered in the .gitmodules file as well as in the parent repository's .git/config file.

Updating Submodules

There are two actions that can be used to update submodules, Update Submodule and Sync Submodule.

Selecting the Update Submodule action on a submodule will check out the commit referenced in the parent repository's index for that submodule. This command will also perform a merge or rebase if that has been configured in the update field for the selected submodule's configuration section in the parent repository's .git/config file.

Selecting the Sync Submodule action on a submodule will update the remote URL used by the submodule from the current value in the .gitmodules file at the root of the working directory of the parent repository.

Team Project Sets

Team project sets (.psf files) are supported by the Git team provider.

Import

To import an existing project set, use the Import... wizard and then select Team Project Set from Team.

You can then select a file which contains the import definitions and optionally choose to add imported projects to a working set.

In the next step, the repositories are cloned, the projects imported and connected. This can take a while depending on the size of the repositories.

Export

To create a project set file for existing Git projects, select the projects/working sets which are already connected to the Git team provider.

Then open the Export... wizard and select Team Project Set from Team. There you can choose to export working sets or projects only and can refine your selection. In the next step, select an output path and finish the wizard.

書式

You can also manually edit a .psf file. Each project has an entry which looks like this:

<project reference="1.0,git://egit.eclipse.org/egit.git,master,org.eclipse.egit"/>

The values are separated by commas and have the following meaning:

1. Format version
2. Git repository URL
3. Name of branch to initially check out
4. Path to the project to import (folder which contains .project), relative to the repository

Each project has one entry. So for multiple projects in the same repository, create such an entry for each project with the same repository URL. The import is smart enough to only clone each repository once.

If the repository contains a project at the root, use . as the project path.

リファレンス

Menus

Project Context Menu

On project nodes in navigation views (Navigator, Package Explorer etc.) the following Git actions are available for projects shared with the Git team provider:

main project menu

"Remote" sub-menu

"Switch To" sub-menu

"Advanced" sub-menu

Resource Context Menu

On resource nodes (files and folders) in navigation views the following Git actions are available for projects shared with the Git team provider:

Repositories View Menus

In the Repositories View the menu depends on the node type which is selected

Menu on repository nodes:

Menu on branch nodes:

Menu on tag nodes:

Menu on Reference nodes:

Menu on Remote nodes:

Menu on Fetch Configuration nodes:

Menu on Push Configuration nodes:

Menu on Working Tree nodes:

History View Menus

Menu on entries in the History View's commit list

Menu entries in the History View's Quickdiff sub menu

Git Workbench Toolbar and Git Workbench Menu

In order to ease use of the most frequently used Git actions the Git Command Group can be activated to show a Git Workbench Toolbar and/or Menu

• Click Window > Customize perspective...
• in the tab Command Groups Availability click Git, this will enable both the Git workbench toolbar and menu
• in the tabs Toolbar Visibility and Menu Visibility you may configure which actions should appear in the Git Workbench toolbar and menu

Menu Actions

• Add
  • Add changes present in the working tree to the git index, also known as staging changes.
  • Put newly created resources under git version control (Git does not automatically start tracking resources).
  • Resolve conflicts.
• Apply Patch - Apply a patch.
• Assume unchanged - Resources can be flagged "assume unchanged". This means that Git stops checking the working tree files for possible modifications, so you need to manually unset the bit to tell Git when you change the working tree file. This setting can be switched on with the menu action Team > Assume unchanged and switched back with the menu action Team > No Assume unchanged.
• Branch, Create Branch - Checkout a branch or create a branch.
• Change Credentials - Change logon credentials of a Fetch or Push Specification, credentials are stored per URL in the Eclipse Secure Store.
• Checkout - Checkout a Branch, Tag, Commit or Reference.
• Cherry-pick - Cherry-pick a single commit onto the tip of the currently checked out branch.
• Clear Credentials - Clear logon credentials of a Fetch or Push Specification, credentials are stored per URL in the Eclipse Secure Store.
• Commit - Commit changes.
• Delete Fetch - Delete a Fetch Specification.
• Delete Push - Delete a Push Specification.
• Configure Fetch - Configure a Fetch Specification.
• Configure Push - Configure a Push Specification.
• Delete Branch - Delete a branch.
• Delete Repository - Delete a repository.
• Disconnect - Disconnect the attached Git Team Provider from this project. The git repository still exists but is no longer integrated with Eclipse.
• Ignore - Add files to .gitignore so that git ignores them.
• Import Projects - Import projects into the Eclipse workbench.
• Merge - Merge branches.
• Merge Tool - Resolve conflicts using the Merge Tool.
• Open Properties View - View and edit the repository configuration.
• Pull - Pull changes from remote branch tracked by currently checked out local branch.
• Remote > Fetch From - Fetch changes from a remote repository
• Remote > Fetch from Gerrit - Fetch changed from a Gerrit Code Review Server
• Remote > Push - Push changes to other repositories
  
• Remote > Configure Fetch from Upstream - Configure Upstream for automated fetch
• Remote > Configure Push to Upstream - Configure upstream for automated push
  
• Rebase - Rebase a branch onto another one.
• Remove Repository - Remove a repository from the Repositories View.
• Rename Branch - Rename a branch.
• Reset - Reset the current HEAD, Index or Working Tree.
• Show in History - Show the selected resource in the History View.
• Show in Repositories View - Show the selected resource in the Repositories View.
• Switch to... - Switch to (also known as checkout) another branch or tag.
• Synchronize - Synchronize local and remote branches with each other.
• Tag - Create, delete tags.
• Untrack - Remove resources from git version control. If you want to delete the resource from the working tree click also Delete in the resource's context menu.

Git Perspective and Views

Git Perspective

Window > Open Perspective > Git Repository Exploring opens the Git Repository Exploring perspective

Git Repositories View

Window > Open View > Git > Git Repositories opens the Git Repositories view which is explained in detail here.

History View

概要

The History View for Resources under Git version control is a commit-centric view of the resources in a given Repository. It can be used to perform the following tasks:

• Inspecting the change history of a given File under Git version control (viewing and comparing the versions of such a File in the Repository)
• Search for a certain commit using different search criteria
• Check-out of a certain commit
• Creation of branches and tags based on a certain commit
• Creation of patches based on the changes in a certain commit
• Resetting the complete Repository to a certain commit
• Setting and resetting of the quickdiff baseline to a certain commit

Opening the History View

The History view can be opened by

• Right-clicking Show In > History View on any resource under Git version control in the explorer (not available in all Perspectives)
• Right-clicking Team > Show in History on any resource under Git version control in the explorer
• Clicking Window > Show View > Other..., then Team > History

Once the view is open, you can activate the Link with Selection button to keep the input of the view in sync with the selection in the explorer automatically.

Organization of the History View

The History view is organized in several panes:

The upper pane is the Commit Graph displaying the commit log (or commit history) in reverse chronological order (newest commit on top). Below the commit graph, there are by default two panes: on the left side, the Revision Comment area, which shows the commit message and a textual Diff of the file or files in the commit, and on the right side, the Revision Detail area, which shows a table of the files that were changed by the commit.

The first column of this table describes the nature of the change for each file:

ADD  the file was added by the commit

MODIFY  the file was modified by the commit

DELETE  the file was deleted by the commit

The content of the lower panes depends on the selection in the upper pane and is updated automatically when this selection changes.

Both lower panes can be switched on and off separately by right-clicking anywhere in the upper pane and selecting Show Revision Comment and Show Revision Details, respectively.

Above the Commit Graph, the current input is visualized. The input is always a workspace resource, either a project, a folder, or a file. After the type of the input, the path is shown, followed by the name of the Repository containing the resource in square brackets.

Using the History View

Inspecting the Commit Graph

The Commit Graph area is the main part of the History View. By default, it shows the currently checked out commit and all its ancestors, i.e. the first entry in the list is the checked out commit. The following picture is used to explain some of the features of the History View:

Each line in the Commit Graph corresponds to a commit. Branches, tags and HEAD are visualized as follows:

• The tips of local branches are shown as green rectangles
• The tips of remote branches are shown as grey rectangles
• The local HEAD is shown as a white rectangle
• Tags are shown as yellow rectangles

(our example doesn't have remote branches).

The line on the left side is the actual commit graph, which shows the parent-child relation of the commits in the list (each commit has at least one parent, except for the very first commit in a Repository). There can be forks, which correspond to a branch operation, and joins, which correspond to a merge operation. In our example, there was a branch "experimental" created after the commit with branch "beforeSplit", and the same file was changed both in the "master" and in the "experimental" branch. The last commit is a merge commit where the content of the "experimental" branch was merged with the "master" branch.

The exact change can be inspected by marking a commit and looking at the Revision Comment area. When scrolling down in the Revision Comment area, a textual diff for the changes will be visible, in our example it says that the content of Project1/f1/file1.txt was changed from "modified" to "modified in master". When selecting the next commit (which corresponds to the "experimental" branch), a similar diff would be displayed, saying that the content of that file was changed from "modified" to "modified in experimental". The newest commit is the result of merging "experimental" into "master". Accordingly, the new commit has two ancestors and the "master" and "experimental" lines are joined again.

Displaying and Comparing versions of a File

If the current input is already a file, right-clicking Open on a commit will open an editor with the file content corresponding to the currently selected commit. If the file does not exist in the selected commit, an error message will be displayed. Clicking Compare with working tree will open a compare editor comparing the file content of the currently selected commit with the file content in the workspace.

The Open and Compare with working tree actions can also be executed by double-clicking on a commit: if the "Compare Mode" toolbar button (see below) is down, Compare with working tree will be executed, otherwise Open.

It is possible to compare the contents of two commits filtered by the current input by selecting the two commits and right-clicking on Compare with each other. If the current input is not a file, there is an additional menu action Compare with each other in Tree. The first action opens an Eclipse compare editor, the second opens the Git Tree Compare View.

Furthermore, it is possible to select any number of commits and right-click Open to see all versions of the file corresponding to the selected commits (one editor will be opened per version).

If the current input is not a file, then there won't be menu actions for Open. However, it is possible to double-click on an entry the Revision Detail area. If compare mode is active, a compare editor will be opened showing the changes for the file being double-clicked in the currently selected commit (i.e. a diff of the file content in the currently selected commit against the file content of this commit's ancestor). If compare mode is not active, an editor with the file content corresponding to the currently selected commit is shown.

Working with the Filter Settings

The filter settings can be changed using the corresponding toolbar actions (see below). By default, the "Resource" setting is active, i.e. only those commits are shown in the list that contain changes for the current input. If the current input is not a file, all commits are shown that contain changes for any child of the current input.

If the filter setting is "Resource" and the current input is a file, then the list of commits contains only those commits that contain changes for that file. This is useful when analyzing the history of that file. In some cases, however, it is helpful to also see other commits which do not change the actual file. For example, it may be interesting to see whether a given change in the file was before or after some other commit which does not change that file itself. In our example, we might want to know whether a given change was "before" or "after" the commit tagged as "Project1". By changing the filter setting from "Resource" to "Repository", this is easily done:

The behavior of the other two settings ("Folder" and "Project") is similar in that they include the commits that change any resource in the parent folder of the current input or any resource in the project of the current input, respectively. In our example above, if filter setting "Project" would be used, the commit "Add Project2 to Repository" would not be shown, is it doesn't change anything in the project of the current input (Project1/f1/file1.txt).

Alternatively, in order to see all commits pertaining to a specific project, one could change the history view input to that project. However, the file-specific menu actions would then not be available.

Toolbar actions

The first four buttons in the History View's toolbar are the standard buttons for Refresh, Link with Selection, Pinning and Navigation History.

Find

If the "Find" toolbar button is down, a search bar is displayed in the lower part of the view which allows to search for commits in the commit log. Depending on the setting in the drop-down list in the search bar the commit's title, comment, author or committer are searched.

The found search hits are high-lighted in bold and the "Next" and "Previous" buttons allow to jump to the next or previous commit matching the search criteria:

Filter settings

The next four toggle buttons in the view toolbar control how the displayed commits are filtered with respect to the current input:

The buttons are working as radio buttons, i.e. one of the four buttons must always be down.

• If the "Repository" button is down, the commit log is not filtered and shows all commits reachable from the currently checked out branch (or all commits, see below about the "All Branches" action)

• If the "Project" button is down, the commit log is filtered to show all commits which affected any of the resources in the project containing the current input

• If the "Folder" toggle is down, the commit log is filtered to show all commits which affected any of the resources in the parent folder of the current input

• If the "Resource" button is down, the commit log is filtered to show only commits which affected the current input; the view menu item Show > Follow Renames allows to toggle whether renames of the selected resource should be followed by this filter

Note that not all combinations of filter setting and current input are meaningful; for example, if the current input is a project, the "Project" option is in fact the same as the "Resource" option.

Compare Mode

The next button is again a toggle, activating "Compare Mode". If it is down, certain double-click actions (see above) will open a compare editor instead of a normal editor.

All Branches

This toggle activates the "All Branches" mode. By default, only those commits are shown in the commit log that can be reached from the currently checked out commit, i.e. the Commit Graph ends with the currently checked out commit and newer commits are not shown. If this button is down, all commits will be shown in the commit log. This is illustrated in the following picture from our example. The branch "beforeSplit" is currently checked out; by activating the toggle, the newer branches will become visible:

View Menu actions

Configuring the View

Most of the toolbar actions are available in the View Menu, too. In addition, the following toggles are available:

and the Filter submenu allows to configure filter settings

"Additional Refs" toggles the visibility of certain Refs created during actions like fetch, rebase, merge, for example FETCH_HEAD, ORIGIN_HEAD... This can be helpful to remove clutter from the history view.

"Notes History" toggles the displaying of Gerrit's review notes branch/ref in the History view

"Follow Renames" toggles whether renames of a selected resource should be followed in the History View, if the "Resource" filter is used. This preference can also be configured in the preference wizard Preferences > Team > Git > History > Follow Renames.

"Revision Comment" toggles the visiblity of the Revision Comment area.

"Revision Details" toggles the visibility of the Revision Detail area.

If "Relative Dates" is checked, the commit dates are shown as relative dates instead of absolute dates.

"E-mail Adresses" toggles the display of committer e-mails.

The sub-menu "In Revision Comment" opens a sub-menu with some more toggles that govern the appearance of the Revision Comment area:

"Tag sequence" allows to show/hide a couple of lines indicating the last tag in the list of ancestors of the given commit and the next tag in the list of successors of the given commit, i.e. the tags preceding/following the given commit.

The "Wrap Comments" and "Fill paragraphs" toggles govern the formatting within the Revision Comment area.

"Revision Details" and "Revision Comments" are also available by right-clicking anywhere in the Commit Graph area.

"Tag sequence", "Wrap Comments" and "Fill paragraphs" are also available by right-clicking anywhere in the Revision Comment area.

Context Menu actions

The context menu in the Commit Graph area is slightly different, depending on whether the current is a File or a Folder/Project, respectively. The following menu entries are always available:

If the current input is a File, there are some other actions available; if exactly one commit is selected, there are three additional options:

and if exactly two commits are selected, the menu will appear like this:

If more than two commits are selected, only the "Open" action and the "Quickdiff" menu will be available.

Compare with working tree

This action is only available if the current input is a file and a single commit is selected. It will open a compare editor comparing the file content of the selected commit with the file content in the working tree.

Compare with each other

This action is only available if the current input is a file and exactly two commits are selected. It will open a compare editor comparing the file content of the selected commits with each other.

Open

This action is only available if the current input is a file. It will open an editor for each selected commit displaying the content of the file for the given commit.

Checkout

This checks out the currently selected commit. If a branch exists for this commit, the branch is checked out, if more than one branch exists for this commit, a dialog will be shown asking which branch should be checked out. If no branches exist for the commit, the commit will be checked out and HEAD will become detached.

Create Branch...

Creates a branch on the currently selected commit. A dialog will be shown asking for a branch name and whether the newly created branch should be checked out.

Delete Branch

This action will be enabled if a branch exists for the currently selected commit, which is not checked out. If there is a single branch on this commit, which is not checked out, this action will delete this branch immediately. If multiple such branches exist, a dialog will be shown asking which branches should be deleted. If commits become unreachable on "Delete Branch" a confirmation dialog will be shown to prevent accidental unreachability of commits.

Create Tag...

Creates a tag on the currently selected commit. A dialog will be shown asking for a tag name and a tag message.

Create Patch...

This action is not available on the very first commit of a Repository. It will create a patch containing the changes of the currently selected commit compared to that commit's predecessor. A dialog will be shown asking whether the patch should be created as file or in the clipboard and whether to use the Git patch format of the generic patch format.

Cherry Pick

Applies the change introduced by the selected commit on top of the currently checked out commit.

Revert Commit

Reverts the changes that the selected commit introduces by creating a new commit on top of the currently checked out commit.

Merge

Merges the selected commit into the currently checked out branch.

Rebase on top of

Rebases the currently checked out branch on top of the selected commit.

Reset > Soft/Mixed/Hard

This action resets the Repository containing the current input to the currently selected commit. Depending on the choice of the sub-menu, a soft, mixed, or hard reset will be performed.

Quickdiff > Reset Quickdiff Basline to first parent of HEAD

These two actions set the quickdiff basline for the repository to HEAD or to the parent of HEAD. These actions are always available, even if more than one commit is selected.

Quickdiff > Set as Baseline

This action is only available if a single commit is selected; it will st the quickdiff baseline for the repository to the selected commit.

Copy

Copies the IDs of the currently selected commit or commits into the clipboard.

Show Revision Comment

Toggles the visibility of the Revision Comment area.

Show Revision Details

Toggles the visibility of the Revision Details area.

Wrap Comments

Only available when right-clicking on the Revision Comment area. If active, the comments will be auto-wrapped to fill the display area, otherwise the wrapping of the commit message will be used.

Fill Paragraphs

Only available when right-clicking on the Revision Comment area. If active, the commit message will be displayed without unnecessary line breaks.

Drag and Drop Support

You may drag and drop commits from the commit graph either onto a Mylyn Task or into a folder on your harddisk. In both cases, EGit will automatically create a patch you may attach to a bug or store on disk.

Working with the Revision Details Area

The Revision Details Area shows a table of the files that were changed by the selected commit. Selecting the context menu action Show Annotations on selected files will open the file in a (read-only) editor and display an annotation ruler with commit and author information for each line in a file. See this section.

Synchronize View

The menu command Team > Synchronize Workspace will launch the Synchronize View. This view allows you to inspect the differences between the resources in the local workspace and a local or remote tracking branch. Alternatively you may compare a local and a remote tracking branch. Comparison of two remote tracking branches as well as menu commands on the Synchronize View are not yet available in this EGit version and will be provided in a future release.

Here is what the Git Synchronize View looks like:

Synchronization State

The Synchronize View shows the synchronization state of resources in your workspace or a local branch compared to those in another local or remote tracking branch representing the state of a branch from a remote repository. This state is shown by using icons and can also be configured to show the state as text appended to the resource name.

A description of the icons is shown in the table below:

Icon	説明
	An incoming addition means that a resource has been added to the target branch.
	An incoming change means that the file has changed in the target branch.
	An incoming deletion means that a resource was deleted from the target branch.
	An outgoing addition means that the file was added to your workspace or source branch and is not yet in the target branch.
	An outgoing change means that the file was changed in your workspace or source branch.
	An outgoing deletion is a resource that has been deleted in your workspace or source branch.
	A conflicting addition means that the resource has been added in your workspace or source branch and in the target branch.
	A conflicting change means that the file has been changed in your workspace or local branch and in the target branch. A manual or automatic merge will be required. Also, any entries in the view that contain children that are conflicts will also be decorated with the conflict icon. This is done to make conflicts easy to find.
	A conflicting deletion means that the resource was deleted in your workspace or source branch and in the target branch.

モード

The Synchronize View can be filtered using modes using either the toolbar actions or the menu items in the view's drop down menu. Modes can be used to show only incoming, outgoing or conflicting changes.

Models

The Synchronize View is capable of displaying different model representations of the resources. Each product may contain its own product specific representations. The Eclipse SDK comes with three models:

Workspace Model

displays a resource based model. Layout options for this model can be controlled from the Preferences dialog in the drop down menu. The layout options for the Workspace model are

• Flat layout

  shows all the out-of-sync resources as direct children of their project.

  Tree layout

  shows the resource hierarchy as it is shown in the Project Explorer.

  Compress Folders

  shows changes grouped by project and then by folder. This results in a hierarchy that is at most three levels deep with folder paths being compressed into a single level (similar to a Java package).

Java Model

displays a Java based model (similar to what appears in the Package Explorer).

Git Commits

displays a Git Commit based model. This model shows incoming changes grouped by commit which is handy for seeing who released what and why. For outgoing changes, you can create commits by creating commits. The display format of the Git commit description can be configured in the preferences under Team > Git > Label Decorations in the tab Other.

In addition to to the models, there is also a Flat Presentation which displays all the out-of-sync elements as top level elements.

ナビゲーション

The Synchronize view provides toolbar actions for navigating through the changes in the view. These actions not only navigate between files but also go from change to change within a file.

The tree in the Synchronize View can easily be expanded and collapsed from the tool bar.

Git Tree Compare View

This view will be opened by some of the Compare With actions (see Comparing Content). When started from a resource (e.g. a project or folder), it will look similar to the resources in the workspace. However, the usual icons on the files will be replaced with icons showing the change state (added, deleted, changed, or unchanged).

The changes can be browsed and a double-click on a file will open a compare editor for this file (this only makes sense on "changed" files, in case of added or deleted files, one side of the compare editor will be empty, whereas unchanged files will show the same content on both sides of the editor):

It is possible to hide unchanged files by clicking the "Hide files with equal content" button in the toolbar.

The Git Tree Compare View can also be started without having workspace resources as starting point (for example by comparing two commits in the history view when the input of the history view is a Repository and not a workspace resource). In this case, the complete content of the Repository is shown and both projects and folders appear as simple "folder" icons:

Git Staging View

This view provides an equivalent for git status showing changes made in the working tree. Unstaged changes which have not yet been transferred to the git index are displayed in the Unstaged Changes pane, changes which have already been "added" (staged) to the Git index are shown in the Staged Changes pane. By default these panes are displayed in a row layout, which can be changed to a column layout by the Column Layout option. The Staged- and Unstaged Changes panes by default show the full path of the files. They can be configured by the Show File Names First option to show the file names first, followed by the directory that the files are located in.

Double-click modified files to open a compare view. If fired from the "unstaged" pane the compare view will show the not-yet staged changes. When fired from the "staged" pane it will display the already staged changes. To open a file in the editor, use the Open Workspace Version action on the file's context menu.

To stage a file, drag it from the Unstaged Changes pane to the Staged Pages pane. Alternatively, use the Add to Git Index action on the file's context menu in the Unstaged Changes pane. The Replace with File in Git Index action will replace the selected file in the working tree. If the file is unstaged, it will be reset. If it is staged, the working tree version will be replaced with the staged version from the Git index.

To unstage a file, drag it from the Staged Changes pane to the Unstaged Changes pane. Alternatively, use the Remove from Git Index action on the file's context menu.

The commit action will commit the staged changes only -- similar to what git commit does in native git. An integrated commit message editor allows to edit the commit message for the commit. In contrast to the commit dialog, the staging view can be kept open while doing changes. This allows for incrementally writing the commit message along with the changes. The commit message being edited is associated with the repository, the staging view is linked with. It is not stored persistently and will get lost if the staging view or Eclipse are closed.

To commit, press Ctrl+Enter ('Command+Enter on Mac OS X) in the commit message text field, or click on the Commit or Commit and Push button.

The Staging View's view menu allows to configure the Staging View

If you are working on a large change and many files are displayed in the Staging View you may use the "Filter Files" filter field which will filter the content of the Staging View to only show the files matching the filter you entered.

Partial Staging

Sometimes it's useful to commit only some changes of a file. An example is when working on a feature and noticing a typo or small bug, which is unrelated to the feature.

To commit only certain changes, these changes have to be staged first. To do this, double-click on the file in the Unstaged Changes pane. This will open the compare editor. On the left side is the workspace version, on the right is the index (staged) version.

Both sides of the compare editor are editable. When changing something in the right side (index) and saving, the file will turn up in the Staged Changes pane and when committing, exactly that content will be committed.

To stage a group of changed lines, the Copy Current Change from Left to Right toolbar button (arrow icon) can be used.

Git Reflog View

The Reflog View shows the Git reflog for a selected repository. It supports showing the reflog for a specific branch by selecting the hyperlink ref name in the top right of the view. Double-clicking or selecting the context menu action Open in Commit Viewer on a reflog entry opens the corresponding commit in the commit viewer. The context menu action Checkout will checkout the selected commit and the HEAD will become detached.

Git URLs

Git URLs in general consist of transport protocol scheme, address of the remote server and the repository path within the remote server and for some authenticating protocols also the user ID.

EGit supports the following protocols

• file - Direct file system access to the repository.
• git - 最も効率的な組み込みのgitプロトコル (デフォルトのポート 9418). このプロトコルは認証を提供しません。一般的にリポジトリへの匿名読み込みアクセスに使われます。
• ssh - secure shell (SSH) プロトコル上のGit。一般的にリポジトリへの認証書き込みアクセスに使われます。
• http - ハイパーテキスト転送プロトコル はファイアウォールを超えてトンネルすることができます。
• https - ハイパーテキスト転送プロトコル セキュア はファイアウォールを超えてトンネルすることができます。
• ftp - ファイル転送プロトコル
• sftp - SSH ファイル転送プロトコル

Git URLs are used when

• cloning repositories
• fetching changes from another repository
• pushing changes to another repository

Git References

Git References are also known shortly as Refs.
They comprise

• branches
• remote-tracking branches
• tags

They all are named with a path using '/' as path separator and are starting with "refs".

• Local branches start with "refs/heads/"
• Remote tracking branches start with "refs/remotes/". Remote tracking branches proxy branches located in a remote repository so that their state at the time of the last transport operation can be queried also when no connection to the repository is available (offline).
• Tags start with "refs/tags/"

Ref names can be abbreviated as long as the abbreviated form is unique.
例えば、

• "master" is short for "refs/heads/master"
• "origin/master" is short for "refs/remotes/origin/master"
• "v1.0.1" is short for "refs/tags/v1.0.1"

There is also a number of "reserved" names for Refs that are useful for certain scenarios:

Ref Name	Remark
HEAD	Points to the currently checkout out commit
FETCH_HEAD	Points to the result of the last fetch operation
ORIG_HEAD	Points to the commit that was checked out before a merge or rebase operation was started

For a complete list for Ref names and the order of precedence if multiple references have the same shorthand form see the section "Specifying Revisions" section of git rev-parse.

Refspecs

A "refspec" is used by fetch and push operations to describe the mapping between remote Ref and local Ref. Semantically they define how local branches or tags are mapped to branches or tags in a remote repository. In native git they are combined with a colon in the format <src>:<dst>, preceded by an optional plus sign, + to denote forced update. In EGit they can be displayed and also edited in tabular form in the Push Ref Specification and the Fetch Ref Specification and other dialogs.

The "left-hand" side of a RefSpec is called source and the "right-hand" side is called destination. Depending on whether the RefSpec is used for fetch or for push, the semantics of source and destination differ: for a Push RefSpec, the source denotes a Ref in the source Repository and the destination denotes a Ref in the target Repository.

Push Refspecs

A typical example for a Push RefSpec could be

HEAD:refs/heads/master

This means that the currently checked out branch (as signified by the HEAD Reference, see Git References) will be pushed into the master branch of the remote repository.

Fetch Refspecs

A typical example for a Fetch RefSpec could be

refs/heads/*:refs/remotes/origin/*

This means that all branches from the remote repository will be fetched into the corresponding remote tracking branches of the local repository.

Remotes

Remotes are used to manage the repositories ("remotes") whose branches you track from your repository.

In EGit Remotes are defined when

• Cloning a repository from another repository, by convention this repository the newly cloned one has been created from is named "origin". If you prefer a different name the clone wizard allows to specify that.
• Defining Remotes in the Repositories View

A Remote first of all defines a name for the repository whose branches you track, this is important since you may want to track branches from different repositories so the name helps to understand what repository a certain operation is dealing with. In addition Refspecs specified for a given Remote define a mapping of branches and tags in your local repository to branches and tags in the remote repository. You may want to use different mappings for inbound or outbound transport operations hence there are editors to define Fetch and Push Configurations available in EGit.

Git Ignore

.gitignore files located in the working tree specify files that intentionally should not be tracked by git. They only concern files that are not yet tracked by git. In order to ignore uncommitted changes in already tracked files refer to the assume unchanged action.

Each line in .gitignore files defines a pattern. Git checks ignore patterns following the hierarchy of the working tree from highest to lowest. Patterns defined in higher level .gitignore files are overridden by those defined in lower levels. Files which shall be ignored for all working on a given project are usually included in the project's repository to easily share them in the team.

Pattern format definition:

• blank lines are ignored
• lines starting with # serve as comments
• the optional prefix ! negates the pattern. Files excluded by a matching previous pattern become included again. Patterns ending with a slash only match directories but not files or symbolic links.
• patterns not containing a slash are treated as shell glob patterns matched against the path relative to the location of the .gitignore file
• git treats patterns as shell globs as defined in fnmatch(3)
• wildcards in patterns do not match / in path names
• a leading slash matches the beginning of a pathname

The EGit Ignore menu action adds the selected resource to the .gitignore file in the resource's parent directory. To enter other ignore patterns use a text editor.

Git Fetch Factory for PDE Build

As part of EGit's PDE Tools, there's a PDE Build fetch factory for Git included in the org.eclipse.egit.fetchfactory plug-in.

The map file's file format: type@id,[version]=GIT,args

Where args is a comma-separated list of key-value pairs.

Accepted args include:

• tag* - mandatory Git tag
• repo* - mandatory repo location
• path - optional path relative to repo which points to the element (otherwise it's assumed that the element is at the repository root)
• prebuilt - optional boolean value indicating that the path points to a pre-built bundle in the repository

Fetching is implemented as a three-step process:

• The repository is cloned to local disc. If it already exists, it is assumed that it was previously cloned and just new commits will be fetched
• The specified tag will be checked out in the local clone
• The content of the path will be copied to the final build location