Git version control with Eclipse (EGit) - Tutorial

http://www.vogella.com/articles/EGit/article.html

Git version control with Eclipse (EGit) - Tutorial

Lars Vogel

Version 3.3

Copyright © 2009, 2010, 2011, 2012, 2013 Lars Vogel

27.03.2013

Revision History
Revision 0.1	11.12.2009	LarsVogel	Created
Revision 0.2 - 3.3	12.12.2009 - 27.03.2013	LarsVogel	bug fixes and enhancements

Git with Eclipse (EGit)

This tutorial describes the usage of EGit; an Eclipse plug-in to use the distributed version control system Git. This tutorial is based on Eclipse 4.2 (Juno).

---

Table of Contents

1. Scope of this descriptioin

2. What is EGit

3. Command line Git

4. Installation of Git into Eclipse

5. Setting up Git in Eclipse

5.1. Eclipse preferences

5.2. Setup rules for ignoring files and directories

5.3. Activating the Git toolbar

6. Working with a local Git repository in Eclipse

6.1. Introduction

6.2. Creating an Eclipse project

6.3. Creating a local Git repository

6.4. Create .gitignore file

6.5. Using the Git Staging view

6.6. Using the Git Staging view for committing changes

6.7. Staging and committing files in the Git commit dialog

7. Package Explorer integration

8. View the commit history

9. Repository view

9.1. Working with your Git repositories

9.2. Content area

9.3. Open a commit

9.4. Possible operations from a commit

10. Clone existing project

11. Performing Git operations in Eclipse

11.1. Basic operations

11.2. Commit amend

12. Branching in Eclipse

13. Merging in Eclipse

13.1. Merge

13.2. Solving merge conflicts

14. Use cases for git reset

14.1. Moving the HEAD pointer

14.2. Not moving the HEAD pointer with git reset

15. Resetting in Eclipse

16. Create patches

17. Blame annotations

18. The stash command

19. Stash via the Git repository view

20. Git repository for multiple projects

20.1. Create a new repository

20.2. Add a project to an existing Git repository

21. Tutorial: Create Git repository for multiple projects

22. Using EGit with Github

22.1. Github

22.2. Create repository in Github

22.3. Clone project

22.4. Push changes

23. Mylyn integration with Github

24. Writing good commit messages

24.1. Importance of Git commit messages

24.2. Guidelines for useful commit messages

24.3. Example message

24.4. Example histories

25. Contributing to EGit - Getting the source code

26. Thank you

27. Questions and Discussion

28. Links and Literature

28.1. EGit and Git Resources

28.2. vogella Resources

1. Scope of this descriptioin

Note

This description contains sufficient information about working with Git in Eclipse but it does not cover all concepts for Git.
For a detailed description of the Git concepts and different options please see the following link or the corresponding Git book from Lars Vogel: Mastering the Git command line from Lars Vogel

2. What is EGit

EGit is an Eclipse plug-in (software component) which allows you to use the distributed version control system Git directly within the Eclipse IDE.
EGit is based on the JGit library. JGit is a library which implements the Git functionality in Java.

3. Command line Git

This tutorial describes the usage of EGit. If you want to learn about the usage of the Git command line you can use the Git Tutorial as a reference.
This tutorial also explains the basic Git terminology, e.g. what is a commit, branch, etc.

4. Installation of Git into Eclipse

The EGit plug-in can be installed into every Eclipse IDE installation. Usually EGit supports the last two Eclipse releases.
Most Eclipse 4.2 and Eclipse 4.3 downloads from Eclipse.org contain EGit in their default configuration. In this case no additional installation is required.
If the EGit plug-in is missing in your Eclipse installation, you can install it via the Eclipse installation manager. Start this manager via the Help → Install new Software menu entry.
EGit can be installed from the following URL:

http://download.eclipse.org/egit/updates 

The dialog to install EGit is depicted in the following screenshot.

5. Setting up Git in Eclipse

5.1. Eclipse preferences

Before using EGit you should configure your name and email address which is used to fill the author and committer information of commits you create.
Git configuration settings can be configured using the EGit configuration preference page but this configuration is not stored in the Eclipse preference store but in git configuration files in order to ensure that native git sees the same configuration.
The Eclipse Git functionality allows you to configure your default user and email address for a commit. Select Window → Preferences → Team → Git → Configuration to set them up.
You can add entries to your Git configuration by pressing the Add Entries button on the Git Configuration preference page. To add your user, use the user.name as key and your real name as value. Repeat the procedure for your email address.

You can add more values in this dialog. These values are stored in the same way the Git command line would store them, so that you can use EGit and Git for the same Git repository.
You can also enter the default folder for storing Git repositories via the Window → Preferences → Git → Team → Default Repository Folder entry.

Note

You can also use Eclipse configuration variables to define this path, e.g. if you want to store repositories in the folder "git" under the Eclipse workspace you may use ${workspace_loc}/git.

Eclipse also supports the .gitignore file for excluding certain files from the Git repository.

5.2. Setup rules for ignoring files and directories

5.2.1. Creating a .gitignore file for your repository

Git can be configured to ignore certain files and directories. This is configured in a .gitignore file. This file can be in any directory and can contain patterns for files.
You can use certain wildcards in this file. * matches several characters. The ? parameter matches one character. More patterns are possible and described under the following URL: gitignore manpage
For example, the following .gitignore file tells Git to ignore the bin and target directories and all files ending with a ~.

# ignore all bin directories
# matches "bin" in any subfolder
bin/

# ignore all target directories
target/

# ignore all files ending with ~
*~ 

You can create the .gitignore file in the root directory of the working tree to make it specific for the Git repository.

Note

Files that are committed to the Git repository are not automatically removed if you add them to a .gitignore file. You can use the git rm -r --cached [filename] command to remove existing files from a Git repository.

Tip

The .gitignore file tells Git to ignore the specified files in Git commands. You can still add ignored files to the staging area of the Git repository by using the --force parameter, i.g. with the git add --force [filename] command.
This is useful if you want to add for example auto-generated binaries but you need to have a fine control about the version which is added and want to exclude them from the normal workflow.

5.2.2. Global (cross-repository) .gitignore settings

You can also setup a global .gitignore file valid for all Git repositories via the core.excludesfile setting. The setup of this setting is demonstrated in the following code snippet.

# Create a ~/.gitignore in your user directory
cd ~/
touch .gitignore

# Exclude bin and .metadata directories
echo "bin" >> .gitignore
echo ".metadata" >> .gitignore
echo "*~" >> .gitignore
echo "target/" >> .gitignore

# Configure Git to use this file
# as global .gitignore

git config --global core.excludesfile ~/.gitignore 

The local .gitignore file can be committed into the Git repository and therefore is visible to everyone who clones the repository. The global .gitignore file is only locally visible.

5.2.3. Local per-repository ignore rules

You can also local per-repository rules by editing the .git/info/exclude file in your repository. These rules are not committed with the repository so they are not shared with others.
This allows you to exclude for example locally generated files.

5.3. Activating the Git toolbar

To simplify access to the common Git operations you can activate the Git toolbar. For this select Window → Customize perspective... and check the command groups Git and Git Navigation Actions in the Command Groups Availability tab.

6. Working with a local Git repository in Eclipse

6.1. Introduction

The following section explains how to create a local Git repository for one project with Eclipse. This allows you to keep track of your changes in the project and allows you to revert to another state at a later point in time.

6.2. Creating an Eclipse project

Create a new Java project called de.vogella.git.first in Eclipse. Create the de.vogella.git.first package and the following class.

package de.vogella.git.first;

public class GitTest {
  public static void main(String[] args) {
    System.out.println("Git is fun");
  }
} 

6.3. Creating a local Git repository

To put your new project under version control with Git, right-click on your project, select Team → Share Project → Git.
Depending on your installation you may have to select that you want to use Git as a version control system.

On the next dialog press the Create button.

It is recommended to separate your Git repository from any additional meta-data which Eclipse might create, it is recommended to place your Git repositories outside the Eclipse workspace. Eclipse follows this recommendation and the EGit plug-in proposes a directory outside your workspace. Placing Git repositories directly in the workspace may cause performance issues since the Git support in Eclipse then may need to scan a large number of files reachable under the workspace.
Enter your project name as Name for your local Git repository. Select the Finish button.

After pressing the Finish button, the wizard displays the settings for your local Git repository. Select the Finish button again to put your repository under Git version control.

You have created a local Git repository. The Git repository is in this case directly stored in the specified folder in a .git folder. The following screenshot shows the generated directory structure.

6.4. Create .gitignore file

Git can be configured to ignore certain files and directories. This is configured via the .gitignore file.
Create a .gitignore file in your Git repository with the following content.

bin
.metadata 

All files and directories which apply to the pattern described in this file will be ignored by Git. In this example all files in the bin and the .metadata directory will be ignored.
You can also create a local .gitignore file by right-clicking on a resource (file or folder) and by selecting the Team → Ignore context menu entry. But excluding individual files should be avoided, you should prefer to define a pattern in your .gitignore file in the root directory of the repository.

Note

You can also configure Eclipse to automatically ignore derived resources, e.g. class files via the Window → Preferences → Team → Git → Projects → Automatically ignore derived resources .. setting.

6.5. Using the Git Staging view

Eclipse gives you several options to stage and commit your changes. The Git Staging view provides a convenient compact overview on all changes you have done since checking out a branch.
The Git Staging view is non-modal, you can switch between different repositories without loosing a commit message and it allows incremental staging for changes.
Open the Git Staging view via the Window → Show View → Other... → Git → Git Staging menu.
In this view you select all files which have changed and drag them into the Staged Changes area. To commit the staged changes you write a descriptive commit message and press the Commit button which is hightlighted in the following screenshot.

Perform these actions for your initial changes. Afterwards the first version of your Java project is under version control. If you don't experience any hardware error your data is now savely stored in your local Git repository and you can always restore your Eclipse project to this initial point.

6.6. Using the Git Staging view for committing changes

Change the System.out.println message in your GitTest class.

package de.vogella.git.first;

public class GitTest {
  public static void main(String[] args) {
    System.out.println("Git is cool");
  }
} 

Also create a new file called readme.txt
We want to commit the changes of GitTest class but not add and commit the readme.txt file to the Git repository.
Using the Git Staging view drag only the GitTest class into the Staged Changes area, write a good commit message and press the commit button.

This change is now also stored in your local Git repository. The readme.txt is neither staged nor committed to the Git repository.

6.7. Staging and committing files in the Git commit dialog

The Git Staging view is a very convenient way of working with Git as it gives you a grouped view of all the pending changes without an additional dialog.
If you prefer to invoke the Git commit dialog directly you can do this via selecting the Team → Commit dialog.
The dialog allows you to add changed and new files to the staging area and commit the changes.

7. Package Explorer integration

The Package Explorer view shows indicators on the files to show their status. The most important icon decorators are depicted in the following screenshot.

The file name describes the state of the file from the following list:

• added to index - staged but not yet committed, i.e. snapshot of this file has been stored in the git database. This status is the same as the staged but the file wasn't under Git version control before
  
• dirty - file has changed since the last commit
  
• ignored - flagged to be ignored by Git
  
• staged - staged to be included in the next commit
  
• tracked - commit and not changed
  
• untracked - neither staged nor committed

Note

Combination of the staged and dirty status means: some parts of the changed file have been staged while some are still unstaged. This can happen if you stage a file and then again modify the file before creating the next commit. You can also change the staged parts using the compare editor opened by double clicking files in the staging view.

On a project level the Package Explorer view adds to the label of the project name the information which Git repository is used. It also adds the number of commits that are different between local and remote tracking branch. This way you can quickly see if your local branch is ahead or behind the remote branch it is tracking.

8. View the commit history

The History view allows you to analyze the commit timeline, see the branches, and to which commits they point, etc. This view is despited in the following screenshot.

To see the history of a resource, select your project, a file or a folder, right-click on it and select the Show in → History context menu entry. Alternative you can use the Alt+Shift+W shortcut and select the History entry.
If you select a commit you see the commit message and the involved files.

Note

If you want to see more details about a commit, right-click it and select the Open in Commit Viewer entry.

Via right-click on an individual file you can compare this file with its ancestor (the commit before that) or with the current version in the workspace.
The History view allows you to filter based on resources. See the tooltips of the toolbar for the meaning of the different filter options. In order to see all commits click the Show all changes in this repository and Show all branches and tags buttons.
Commits which are not reachable from any branch, tag or symbolic link, e.g. HEAD are not displayed in the History view.

You can also search for commits based on committer, author, ID or comment. The find feature of the history view is mainly interesting to quickly move to a commit you are searching.

Note

The Git Search available in the Search → Search menu is much more powerful and consumes less memory since it doesn't need to also display the history.

9. Repository view

9.1. Working with your Git repositories

EGit has a Git repository view which allow you to browse your repositories, clone Git repositories, checkout projects, manage your branches and much more.
The toolbar entries allow you to add an existing local Git repository to the view, clone a Git repository and to create a new Git repository.

9.2. Content area

The content area show the existing Git repositories and the structural elements of this view. The following screenshot highlights the different main elements of this view.

A right-click (context menu) on an element in the Git repository view allows you to perform related Git operations. For example if you click on a branch you can checkout the branch or delete it.

9.3. Open a commit

If you are in the Git repository view you can open a commit via Navigate → Open Git Commit menu entry.

9.4. Possible operations from a commit

If you open a commit you can create a tag or branch from it. You can also revert it, cherry pick it or check it out.

10. Clone existing project

Eclipse allows you to clone an existing Git repository and to import existing projects from this repository into your Eclipse workspace by using a wizard.
Select File → Import → Git → Project from Git.

Select URI in the next dialog.

Enter the URL to your Git repository. Git supports several protocols, e.g. git:// and https://. You only have to paste the URL to the first line of the dialog, the rest will be filled out automatically.
Please note that some proxy servers block the git:// protocol. If you face issues, please try to use the https:// or http:// protocol.
For example the following URI can be used to clone the example projects of the Eclipse 4 application development book: git://github.com/vogella/eclipse4book.git
The above links uses the git protocol, alternatively you can also use the http protocol: http://github.com/vogella/eclipse4book.git

After pressing the Next button the system will allow you to import the existing branches. You should select at least master as this is typically the main development branch.

The next dialog allows you to specify where the project should be copied to and which branch should be initially selected.

After the Git repository is cloned, EGit opens an additional import dialog which allows to import the Eclipse projects from the Git repository.

Once this dialog is completed, you have checked out (cloned) the projects into a local Git repository and you can use Git operation on these projects.

11. Performing Git operations in Eclipse

11.1. Basic operations

Once you have placed a project under version control you can start using team operations on your project. The team operations are available via right-click on your project or file.

The most important operations are described in the following list. Select:

• Team → Add to index, to add the selected resource(s) to the index of Git
  
• Team → Commit, to open the commit dialog for committing to your Git repository
  
• Team → Create Patch..., to create a patch
  
• Team → Apply Patch..., to apply a patch to your file system
  
• Team → Ignore, to add the file to a .gitignore file
  
• Team → Show in History, to display the selected files and folders in the History view

If you select a project you can use additional team operations from the context menu.

• Team → Pull to pull in changes from your remote Git repository
  
• Team → Fetch to fetch the current state from the remote repository
  
• Team → Switch To to switch or create new branches
  
• Team → Push to push changes to your remote Git repository
  
• Team → Tag to create and manage tags.

11.2. Commit amend

Git amend allows to adjust the last commit. For example you can change the commit message. The Git Staging view allows you to perform the Git amend command via the highlighted button in the following screenshot.

12. Branching in Eclipse

Right-click your project and select Team → Branch to create new branches or to switch between existing branches. You can also switch branches in the History view.

13. Merging in Eclipse

13.1. Merge

EGit supports merging of branches to add the changes of one branch into another. Select your project and Team → Merge to start the merge dialog.

13.2. Solving merge conflicts

If you pull in changes or merge a branch and you have conflicting changes, EGit will highlight the affected files. EGit also supports the resolution of these merge conflicts.
Right-click on a file with merge conflicts and select Team → Merge Tool.

Tip

Use the Git staging view to find the conflicting files, in large projects that is usually faster than navigating the Package Explorer view.

This opens a dialog, asking you which merge mode you would like to use. The easiest way to see the conflicting changes is to use the Use HEAD (the last local version) of conflicting files as merge mode. This way you see the original changes on the left side and the conflicting changes on the right side.

You can manually edit the text on the left side or use the Copy current change from right to left button to copy the conflicting changes from right to left.

Once you have manually merged the changes, select Team → Add from the context menu of the resource to mark the conflicts as resolved and commit the merge resolution via Team → Commit.

14. Use cases for git reset

14.1. Moving the HEAD pointer

The git reset command allows you to set the current HEAD to a specified state, e.g. commit. This way you can continue your work from another commit.
Depending on the specified parameters the git reset command performs the following:

1. If you specify the --soft parameter the git reset command moves only the HEAD pointer.
   
2. If you specify the --mixed parameter (also the default) the git reset command moves the HEAD pointer and resets the staging area to the new HEAD.
   
3. If you specify the --hard parameter the git reset command moves the HEAD pointer and resets the staging area and the working tree to the new HEAD.

Via parameters you can define if the staging area and the working tree is updated. As a reminder, the working tree contains the files and the staging area contains the changes which are marked to be included in the next commit. These parameters are listed in the following table.

Table 1. git reset options

Reset	HEAD	Working tree	Staging area
soft	Yes	No	No
mixed (default)	Yes	No	Yes
hard	Yes	Yes	Yes

Tip

The git reset command does not remove untracked files. Use the git clean command for this.

14.2. Not moving the HEAD pointer with git reset

If you specify a path for the git reset command Git does not move the HEAD pointer but only updates the staging area or also the working tree depending on your specified option.
See ??? and ??? for examples.

15. Resetting in Eclipse

The History view allows you to reset your current branch to a commit. Right-click on a certain commit and select Reset and the reset mode you would like to use.

The Git Reflog view keeps track of the movements of the HEAD pointer. This view allows you to find commit again, e.g. if you used the git reset --hard command to remove certain commits.

16. Create patches

A patch is a text file which contains instructions how to update a set of files to a different state.
If you use Git you can create a patch for the changes you made. This patch can be applied to the file system.
To create a patch for a set of changes with EGit, select the resources for which you want to create a patch in the Package Explorer view, right click and select Team → Create Patch.

The resulting file can be used to get applied to another Git repository, via Team → Apply Patch.

17. Blame annotations

EGit allows to add annotations to see which line was last changed by whom and which commit. To enable this, right-click on your file and select Team → Show Annotations.
Afterwards you can place the mouse on the left side of the editor and a popup will show the commit information.

18. The stash command

Git provides the git stash command which allows you to record the current state of the working directory and the staging area and go back to the last committed revision.
This allows you to pull in the latest changes or to develop an urgent fix. Afterwards you can restore the stashed changes, which will reapply the changes to the current version of the source code.
In general using the stash command should be the exception in using Git. Typically you would create new branches for new features and switch between branches. You can also commit frequently in your local Git repository and use interactive rebase to combine these commits later before pushing them to another Git repository.

Tip

You can avoid using the git stash command. In this case you commit the changes you want to put aside and use the git commit --amend command to change the commit later. If you use the approach of creating a commit, you typically put a marker in the commit message to mark it as a draft, e.g. "[DRAFT] implement feature x".

19. Stash via the Git repository view

The git stash command is available in the Git repositories view. Right-click on your Git repository and select Stash Changes.

20. Git repository for multiple projects

20.1. Create a new repository

Eclipse allows to work with projects that are not included in the workspace.
To put several Eclipse projects into the same Git repository you can create a folder inside or outside your workspace and create the projects inside this folder. Then create a Git repository for this folder and all projects in this folder will be handled by the same repository. The best practice is to put the Git repository outsite of the Eclipse workspace.
You can import these projects into your workspace via File → Import → Git → Projects from Git as explained before.

20.2. Add a project to an existing Git repository

To add a new Eclipse project to an existing Git repository, select the project, right-click on it and select Team → Share → Git and select the existing Git repository.

EGit moves the projects to the repository and imports the project automatically into your workspace.

21. Tutorial: Create Git repository for multiple projects

Create two Java projects called com.vogella.egit.multi.java1 and com.vogella.egit.multi.java2.
Create at least one Java class in each project.

Note

Git doesn't track the history of empty folders, it is tracking file content and content changes.

Afterwards select both projects, right-click on them and select Team → Share Project... → Git. Eclipse may ask you which version control system you want to use, e.g. CVS or Git. Select, of course, the Git entry.
Now create a new Git repository outside your workspace similar to the process you used for the creation of your first Git repository in the tutorial.

You created a new Git repository which contains both projects. Both projects are moved to this new repository.
Now perform your initial commit for all files in the projects to store the file in the new Git repository.

22. Using EGit with Github

22.1. Github

Github is a popular hosting provider for Git projects and if your repository is a public repository the hosting at Github is free. A public repository is visible to everyone and can be cloned by other people at any point in time.
To use GitHub create an account on the Github Website.
Github allows you to use the authentication via password or via SSH key to access your repositories.

22.2. Create repository in Github

Create a new repository on Github for example de.vogella.git.github.

After creation of your new repository Github displays the information what you have to do if you want to connect to this repository via the command line. As we are going to use EGit you can ignore this information.

22.3. Clone project

Copy the URL from Github and select in Eclipse from the menu the File → Import → Git → Projects from Git
Eclipse fills out most of the fields based on the URL in the clipboard. Enter your user and password to be able to push to Github. Alternative you can also use an SSH key. You can configure Eclipse to know your SSH via the Window → Preferences → General → Network Connection → SSH2 preference setting. This setting is depicted in the following screenshot.

22.4. Push changes

After you made changes and committed them to your local repository, you can select Team → Push to upstream on the project folder, to push your changes to your Github. This requires write access to the Github repository.

23. Mylyn integration with Github

Eclipse Mylyn provides task integration for Github issues, Github pull and Gist (short text snippets) into the Eclipse IDE.
There is a GitHub connector for Mylyn available, please see Github Mylyn User Guide for details.
You install it via Help → Install new Software and the update site of your release.

Now you can integrate your Github issues into Eclipse via File → Import... → Task → GitHub Task Repositories and by following the wizard.

You can also import now directly projects from Github repositories.

For a detailed description of the Mylyn and EGit integration please see the following webpage.

http://wiki.eclipse.org/EGit/GitHub/UserGuide 

24. Writing good commit messages

24.1. Importance of Git commit messages

A commit adds a new version to the repository. This version is described by a commit message.
The commit message describes the changes recorded in a commit and helps the user to understand the history of the files contained in a Git repository.
A commit message should therefore be descriptive and informative without repeating the code changes.

24.2. Guidelines for useful commit messages

A commit message should have a header and a body. The header should be less than 50 characters and the body should wrap its text at 72 so that the commit message is displayed well on the command line or in graphical tools displaying the history. The body should be separated from the header by an empty line.
The body should mainly describe the reason why the change was made. The changes in the file can be reviewed with the help of Git.
The commit message should be in present tense, e.g. "Add better error handling" instead of "Added better error handling".
The last paragraph can also contain metadata as key-value pairs, also referred to as the commit message footer. This metadata can be used to trigger certain behavior. For example the Gerrit code review system uses the Change-Id key followed by a change-id, which does not change across different versions of the same code review. This changed id is used to identify to which review the message belongs.
The commit message footer can also have e.g. 'Signed-Off-By' and may be used to link to a bug tracking system e.g. 'Bug: 1234'.

24.3. Example message

The following can serve as an example for a commit message.

Short summary (less than 50 characters)

Detailed explanation, if required, line break at around 72 characters
more stuff to describe...

Fixes: bug #8009
Change-Id: I26b5f96ccb7b2293dc9b7a5cba0760294afba9fd 

24.4. Example histories

Note

A Git commit object is identified by its SHA-1 which consists out of 40 bytes. In a typical Git repository you need less characters to uniquely identify a commit object, e.g. you need only 7 or 8 characters. The git log --oneline command lists the commit history in one line using the shortened SHA-1 of the commit objects.

The following listing shows the output of the git log --oneline command of a Git repository with bad commit messages. The first value in each line is the shortened SHA-1, the second the commit message. This history is not useful.

21a8456 update
29f4219 update
016c696 update
29bc541 update
740a130 initial commit 

The next listing shows the history of another Git repository in which better commit messages have been used. This history already gives a good overview about the activities.

7455823 bug 391086: Search and filter the model editor tree.
9a84a8a [404207] Missing DynamicMenuContribution in child selector
952e014 [404187] Spelling error in Toolbar/Add child
71eeea9 bug 402875: Importing model elements from legacy RCP
123672c Bug 403679 - New Application wizard is missing dependencies
97cdb9a Bug 388635 creates an id for handlers 

25. Contributing to EGit - Getting the source code

EGit is self-hosted on git://egit.eclipse.org. You can clone the EGit code from the repository using EGit using the following URL git://egit.eclipse.org/jgit.git and git://egit.eclipse.org/egit.git.
You also need some libraries from Orbit. See Libraries from Orbit for getting these libraries.

26. Thank you

Please help me to support this article:

27. Questions and Discussion

Before posting questions, please see the vogella FAQ. If you have questions or find an error in this article please use the www.vogella.com Google Group. I have created a short list how to create good questions which might also help you.

28. Links and Literature

28.1. EGit and Git Resources

Eclipse IDE book from Lars Vogel
http://www.vogella.com/articles/Eclipse/article.html EGit IDE Tutorial
http://wiki.eclipse.org/EGit/User_Guide EGit User Guide
http://wiki.eclipse.org/EGit/Contributor_Guide EGit contributor guide
Git Tutorial

28.2. vogella Resources

vogella Training Android and Eclipse Training from the vogella team
Android Tutorial Introduction to Android Programming
GWT Tutorial Program in Java and compile to JavaScript and HTML
Eclipse RCP Tutorial Create native applications in Java
JUnit Tutorial Test your application
Git Tutorial Put everything you have under distributed version control system