Support free tutorials

vogella training Training Books

Git version control with Eclipse (EGit) - Tutorial

Lars Vogel

Version 3.6

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.3 (Kepler).

Table of Contents

1. Scope of this description
2. What is EGit
3. Command line Git
4. Installation of Git into Eclipse
5. Setting up Git in Eclipse
5.1. Git and Eclipse configuration
5.2. Default clone location
5.3. Git and Eclipse configuration
5.4. Configure files and directories to ignore
5.5. 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. History view to view the commit history
8.1. Purpose of the history view
8.2. Important settings in the history view
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. Using rebase in Eclipse
15. Working with commits
15.1. git reset
15.2. Finding lost commit with the Reflog view
15.3. Move a commit with git cherry-pick
16. Create patches
17. Blame annotations
18. Stash via the Git repository view
19. Git repository for multiple projects
19.1. Create a new repository
19.2. Add a project to an existing Git repository
20. Tutorial: Create Git repository for multiple projects
21. Using EGit with Github
21.1. Github
21.2. Create repository in Github
21.3. Clone project
21.4. Push changes
22. Eclipse integration with Github
22.1. The Eclipse Mylyn plug-in
22.2. Github issue integration
22.3. Manage pull requests in Eclipse
22.4. Import projects directly from Github
22.5. More infos about the Github Mylyn integration
23. Writing good commit messages
23.1. Importance of Git commit messages
23.2. Guidelines for useful commit messages
23.3. Example message
23.4. Example histories
24. Contributing to EGit - Getting the source code
25. Git series
26. Get the Book
27. About this website
27.1. Donate to support free tutorials
27.2. Questions and discussion
27.3. License for this tutorial and its code
28. Links and Literature
28.1. Source Code
28.2. EGit Resources
28.3. vogella Resources

Get the book Eclipse IDE book

1. Scope of this description


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 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 HelpInstall new Software menu entry.

EGit can be installed from the following URL: 

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

Installing EGit

5. Setting up Git in Eclipse

5.1. Git and Eclipse configuration

Eclipse uses the same configuration files as the Git command line tools hence if you have configured your Git setup via Eclipse or via the command line, both will be using the same setup.

Before using Git you must configure your name and email address which is used to fill the author and committer information of commits you create.

The Git configuration settings can be adjusted via the Eclipse preference setting. Select WindowPreferencesTeamGitConfiguration to see the current configuration and to change it.

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 as key and your real name as value. Repeat the procedure for your email address.

Configuration of EGit user and email default

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.

5.2. Default clone location

You can also configure in Eclipse the default folder for storing Git repositories via the WindowPreferencesGitTeamDefault Repository Folder entry.

EGit default repository folder


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.

5.3. Git and Eclipse configuration

Eclipse also supports the .gitignore file for excluding files and directories from the Git operations.

5.4. Configure files and directories to ignore

5.4.1. Ignoring files and directories with a .gitignore file

Git can be configured to ignore certain files and directories for repository operations. This is configured via one or several .gitignore files. Typically, this file is located at the root of your Git repository but it can also be located in sub-directories. In the second case the defined rules are only valid for the sub-directory and below.

You can use certain wildcards in this file. * matches several characters. 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

# ignore all target directories

# 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.


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.e. with the git add --force [paths] 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.

It is good practice to commit the local .gitignore file into the Git repository so that everyone who clones this repository have it.

5.4.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
# for Mac
echo ".DS_Store" >> .gitignore
echo "._*" >> .gitignore

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

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

The global .gitignore file is only locally available.

5.4.3. Local per-repository ignore rules

You can also create 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.5. Activating the Git toolbar

To simplify access to the common Git operations you can activate the Git toolbar. For this select WindowCustomize 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 TeamShare ProjectGit.

Depending on your installation you may have to select that you want to use Git as a version control system.

Git repository creation wizard - Step 1

On the next dialog press the Create button.

Git repository creation wizard - Step 1

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.

Git repository creation wizard - Step 2

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.

Git repository creation wizard - Step 3

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.

Git repository creation result

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.


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 TeamIgnore context menu entry. Excluding individual files can be time consuming. Preferrably you define a pattern in your .gitignore file in the root directory of the repository.


You can also configure Eclipse to automatically ignore derived resources, e.g. class files via the WindowPreferencesTeamGitProjectsAutomatically 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 WindowShow ViewOther...GitGit 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 highlighted in the following screenshot.

Git Staging View - Commit

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 meaningful commit message and press the commit button.

Git Staging View - Add to staging area

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 TeamCommit dialog.

The dialog allows you to add changed and new files to the staging area and commit the changes.

Adding a file via the EGit commit dialog

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.

Icon decorator

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

Table 1. Sample Table

State Description
staged Changes in the file will be include be included in the next commit.
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 status, but the file wasn't under Git version control before.
dirty File has changed since the last commit.
Ignored File is flagged to be ignored by Git operations.
tracked File is committed to the Git repository and has not changed.
untracked File is neither staged nor committed.


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.

Git icon decorator in the Package Explorer

8. History view to view the commit history

8.1. Purpose of the history view

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

History view of changes

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.


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

Commit Viewer

History View

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.

Filter options for Git 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.

Search in the Git history view


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

Git search

8.2. Important settings in the history view

The toolbar of the History view allows you to customize the displayed elements. By default the History view filters the history based on the current selection and shows only the activate branch.

If you work with several branches, e.g., because you using Gerrit for code reviews, you typically want to see all branch information and remove the filter based on the resource. This selection is highlighted in the following screenshot.

Toolbar settings in history view

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.

Git repository toolbar

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.

Git repository 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.

Git repository view context menu

9.3. Open a commit

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

Open Git Commit dialog

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.

Possible operation from a Git commit

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 FileImportGitProject from Git.

Importing projects via EGit

Select URI in the next dialog.

URI selected in EGit

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://

The above links uses the git protocol, alternatively you can also use the http protocol:

URI entered in the dialog

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.

URI entered in the dialog

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

Define target directory for Git repository

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

Importing projects

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.

Context menu

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

  • TeamAdd to index, to add the selected resource(s) to the index of Git

  • TeamCommit, to open the commit dialog for committing to your Git repository

  • TeamCreate Patch..., to create a patch

  • TeamApply Patch..., to apply a patch to your file system

  • TeamIgnore, to add the file to a .gitignore file

  • TeamShow 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.

Context menu

  • TeamPull to pull in changes from your remote Git repository

  • TeamFetch to fetch the current state from the remote repository

  • TeamSwitch To to switch or create new branches

  • TeamPush to push changes to your remote Git repository

  • TeamTag 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.

Git amend in the Git Staging view

12. Branching in Eclipse

Right-click your project and select TeamBranch 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 TeamMerge 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 TeamMerge Tool.


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.

Selecting the merge model

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.

Seeing merge conflicts

Copy changes from right to left

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

14. Using rebase in Eclipse

The Git Repositories view allows you to rebase your currently checkout branch onto another branch. Right-click on a repository node and select Rebase as depicted in the following screenshot.

Rebase in EGit

In the following dialog you can select the branch onto which you want to rebase.

Rebase in EGit, selecting the branch for rebase


You can also select directly the branch to rebase onto from the Branches node of the tree.

If the rebase was successful a dialog is shown. You have to resolve rebase conflicts if they occur. After resolving them, select RebaseContinue or if you want to cancel the rebase operation select RebaseSkip and RebaseAbort.

15. Working with commits

15.1. git reset

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.

Reset in EGit

15.2. Finding lost commit with the Reflog view

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.

15.3. Move a commit with git cherry-pick

A combination of git reset and git cherry-pick allows you to move a commit. Assume you have a bad commit which you would like to remove from the history of branch followed by a good commit. This situation is depicted in the following screenshot.

Situation before the cherry pick

For this you would make a hard reset on the commit of origin/master.

Situation before the cherry pick

Afterwards you can cherry-pick the good commit.

Situation before the cherry pick

Situation before the cherry pick

This results in a history without the bad commit.

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 TeamCreate Patch.

Create Patch via EGit menu path

Create Patch via EGit

The resulting file can be used to get applied to another Git repository, via TeamApply 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 TeamShow Annotations.

Afterwards you can place the mouse on the left side of the editor and a popup will show the commit information.

Blame annotations in EGit

18. 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.

Stash changes in EGit

Stash changes in EGit

Stash changes in EGit

19. Git repository for multiple projects

19.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 outside of the Eclipse workspace.

You can import these projects into your workspace via FileImportGitProjects from Git as explained before.

Import project from Git repository

19.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 TeamShareGit and select the existing Git repository.

Adding a project to an existing Git repository

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

20. 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.


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 TeamShare 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 book.

Both projects committed to new Git repository in Eclipse

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.

Both projects committed to new Git repository in Eclpise

21. Using EGit with Github

21.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.

21.2. Create repository in Github

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

Creating Github repository step 1

Creating Github repository step 2

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.

21.3. Clone project

Copy the URL from Github and select in Eclipse from the menu the FileImportGitProjects 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 PreferencesGeneralNetwork ConnectionSSH2 preference setting. This setting is depicted in the following screenshot.

SSH settings

21.4. Push changes

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

22. Eclipse integration with Github

22.1. The Eclipse Mylyn plug-in

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 HelpInstall new Software and the update site of your release.

Install Mylyn Github connector

22.2. Github issue integration

You can integrate your Github issues into Eclipse via FileImport...TaskGitHub Task Repositories and by following the wizard.

Importing tasks into Eclipse

22.3. Manage pull requests in Eclipse

You can integrate your pull requests at Github into Eclipse by creating a new query from the Task List view. This is demonstrated via the following screenshots.

Integrating Gitpull requests into Eclipse

Integrating Gitpull requests into Eclipse

Integrating Gitpull requests into Eclipse

Integrating Gitpull requests into Eclipse

Integrating Gitpull requests into Eclipse


Unfortunately the Github connect does currently not support that you merge the pull request.

22.4. Import projects directly from Github

You can also import now directly projects from Github repositories.

Importing projects from Github into EclipseF

22.5. More infos about the Github Mylyn integration

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

23. Writing good commit messages

23.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.

23.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'.

23.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 

23.4. Example histories


A Git commit object is identified by its SHA-1 which consists 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 

24. Contributing to EGit - Getting the source code

EGit is self-hosted on git:// See EGit contributor guide for a description how to work with the EGit and JGit source.

25. Git series

This tutorial is part of a series about the Git version control system. See the other tutorials for more information.

26. Get the Book

This tutorial is part of a book available as paper print and electronic form for your Kindle.

27. About this website

27.1. Donate to support free tutorials

Please consider a contribution Support free tutorials if this article helped you. It will help to maintain our content and our Open Source activities.

27.2. Questions and discussion

Writing and updating these tutorials is a lot of work. If this free community service was helpful, you can support the cause by giving a tip as well as reporting typos and factual errors.

If you find errors in this tutorial, please notify me (see the top of the page). Please note that due to the high volume of feedback I receive, I cannot answer questions to your implementation. Ensure you have read the vogella FAQ as I don't respond to questions already answered there.

27.3. License for this tutorial and its code

This tutorial is Open Content under the CC BY-NC-SA 3.0 DE license. Source code in this tutorial is distributed under the Eclipse Public License. See the vogella License page for details on the terms of reuse.

28. Links and Literature

28.1. Source Code

Source Code of Examples

28.2. EGit Resources

EGit User Guide

EGit contributor guide

28.3. vogella Resources

The vogella company provides comprehensive training and education services from experts in the areas of Eclipse RCP, Android, Git, Java, Gradle and Spring. We offer both public and inhouse training. Whichever course you decide to take, you are guaranteed to experience what many before you refer to as “The best IT class I have ever attended”. The vogella company offers expert consulting services, development support and coaching. Our customers range from Fortune 100 corporations to individual developers.