In your Eclipse IDE, select the Window  Preferences  Version Control (Team)  Git  Configuration entry. Configure your full name and email in the user settings. As the Eclipse IDE uses the same settings as the Git command line, this might already be done.

For the user the user.name key is used, for the email the user.email key is used.

If these keys are not available press the Add Entry…​ button and add them.

Repeat the procedure for your email address via the user.email key.

To use rebase during the pull operation set the pull.rebase parameter to true. It avoids merge commits if you pull from a remote repository and have divergent changes and instead rebases your local branch on the remote branch it tracks.

This is the recommended setting by the author of this text.

After this setup, the configuration should look similar to the following screenshot.

If you are using a proxy server, you can configure it via Windows  Preferences  General  Network Connection.

Use Ctrl+3 (or Cmd+3) and type Create a new Git repository in the dialog.

This opens a dialog which allows you to specify the directory for the new Git repository. Select a new directory outside of your workspace. By convention, this directory is a subdirectory in the git folder of the user’s home directory.

Press the Create button. Now the Git repository is created and a reference to it is added to the Git Repositories view which you use later.

We want to ignore certain file types in our Git repository. We want Git to ignore the bin folder and *.class files.

Create a .gitignore file in the top-level folder of your Git repository. This means, the file should be placed at the same level as the .git directory.

Eclipse Git does not allow you to create a file directly in the top-level folder of your repository. You have to do this step outside of the Eclipse IDE, either via the command line or via your system project explorer.

It should contain the following content.

Projects in Eclipse are folders which can have a special configuration, e.g. they can be configured to support Java development. Use Ctrl+3 (or Cmd+3) and type Create a Java project to open the wizard to create a Java project.

Enter com.vogella.git.first as name and leave the rest of the values to their default value.

Accept the default values for a module-info.java file and press Create .

Skip this part of the exercise in case you are not familiar with Java and go directly to the next part.

Use Ctrl+3 (or Cmd+3) and type Create a Java class to open the wizard to create a Java class. Enter:

Leave the rest of the values to their default value. Press the Finish button, this creates the class and opens the editor.

Now change the code of the class to the following.

To put your new project under version control with Git, right-click on your project, select Team  Share Project. If another version control system is installed you have to select that you want to use Git as the version control system.

Select your existing Git repository from the drop-down list.

Press the Finish button.

Your project location has now moved into the folder of the Git repository.

Use Ctrl+3 (or Cmd+3) and type Git Repositories in the dialog to open the Git repositories view. This view shows you the Git repositories you can work with in Eclipse and allows you to add existing repositories to Eclipse, create or clone repositories. It also allows you to perform Git operations.

Use Ctrl+3 (or Cmd+3) and type Git Staging to open the Git staging view.

In this view use the ++ button to stage all files. Write a meaningful commit message and press the Commit button.

Create a new file named Readme.adoc via right mouse click on your project and New  File from the context menu. Do not commit it yet.

If you did not do the optional Java part, skip this part of the exercise also.

Otherwise, change the System.out.println message in your GitTest class.

Commit the changes of the GitTest class, but do not add and commit the Readme.adoc file to the Git repository.

In the Git Staging view drag only the GitTest class into the Staged Changes area, write a meaningful commit message and press the commit button.

This change is now also stored in your local Git repository. The Readme.adoc file is neither staged nor committed to the Git repository.

Stage and commit the Readme.adoc file. By now you should know how to do this.

Use Ctrl+3 (or Cmd+3) and type History, ensure that the entry belongs to the Views category to open the History view.

In the History view click all toggle buttons as shown in the screenshot

Afterwards, use the History view to review which files were included in your individual commits.

We want to see the version of the GitTest.java file as it was in the first commit. Select the first commit in the history view. You see the changed files of a commit in the right bottom part of the commit details. Select your file in the commit details of the History view and select Open this version via the context menu.

Create a new file named test.unwanted via right mouse click on your project and New  File from the context menu. Stage and commit the new file.

Now add *.unwanted to your .gitignore file. Make a change to your test.unwanted file

Git shows it as a change in .gitignore only apply to new files You need to untrack the file.

Select the file and select Team  Advanced  Untrack.

Stage and commit the change.

You can of course have multiple projects in a Git repository. To validate that, create two more Java projects called com.vogella.egit.multi.java1 and com.vogella.egit.multi.java2. Create at least one Java class in each project.

Afterwards select the new projects, right-click on them and select Team  Share Project…​  Git.

Select your Git repository in the following dialog and add both projects to this repository. Press the Finish button.

Afterwards validate that the projects have been moved. You can check your workspace directory and your Git repository directory via a file explorer. You see that the projects have been moved from their original location to the Git repository.

The changes have not yet been committed. Now commit all files in the two projects to your Git repository.

To reword a commit, right-click on it in the History view and select Modify  Reword to change the commit message.

You can squash several commits by selecting them in the History view. Select afterwards the Modify  Squash menu entry from the context menu.

The above options are simplified ways to do an interactive rebase.

To start the full interactive rebase open the History view and click Rebase Interactive on the context menu. Select the last commit preceding the oldest commit you want to rewrite. Often this is the one origin/master points to.

This opens the Git Interactive Rebase view. The Git Interactive Rebase view allow you perform the full interactive rebase functionality.

It shows the rebase plan populated with the commits to be modified. They are sorted in topological order of the sequence in which they will be processed. This order is the reverse order which you see via the git log command or in the History view. The initial action for all commits is "Pick".

The following actions are available.

Use this view to finalize the rebase plan. For example, you can reorder commits with the arrow buttons and select the rebase action you want to apply to the commit. The following screenshot demonstrates a possible selection.

When the rebase plan is finalized, click the Start button to start the interactive rebase command. Eclipse Git processes the plan. It stops at all commits with an action which needs user feedback. For example, the reword action which requires entering the new commit message. The dialog for changing the commit message is depicted in the following screenshot.

Here is the result of the rebase operation displayed in the History view.

To use Git you must configure your full name and email address. This information is used to fill the author and committer information of commits you create. These Git configuration settings can be adjusted via the Eclipse preference setting. Select Window  Preferences  Version Control (Team)  Git  Configuration to see the current configuration and to change it.

If you clone a new repository via the Eclipse IDE, it will be cloned by default to a new sub-folder in a default directory. This default path can be configured via the Windows  Preferences  Version Control (Team)  Git entry in the Default Repository folder field.

To simplify access to the common Git operations you can activate the Git toolbar. For this select Window  Perspective  Customize perspective…​ and check the Git and Git Navigation Actions entries in the Action Set Availability tab.

Afterwards you can configure which Git operations should be available via the Tool Bar Visibility or the Menu Visibility tab.

You can create an SSH key pair in Eclipse for SSH based communication. This can be done via Window  Preferences  General  Network Connection  SSH2.

The Git Repositories view allows you to browse, add. initialize or clone repositories. It also allows to import projects, manage your branches and much more. You can open this view via Window  Show View  Other…​  Git  Git Repositories

The toolbar allows you to:

The content area of the Git Repositories view shows the existing Git repositories and the important data of each repository. The following screenshot shows an example entry.

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

The Git Staging view allows staging and committing as well as reverting changes.

This view presents which files you have touched and which files will be included in the next commit. Unstaged Changes lists those changes which you have done locally but which you have not yet added to the staging area. Staged Changes lists those changes which you already have added to the staging area. You can drag and drop files from one area to the other. To commit the staged changes you write your commit message and press the Commit button which is highlighted in the following screenshot.

You can switch between different repositories or even restart Eclipse without losing a commit message and it allows incremental staging for changes.

You can open the Git Staging view via the Window  Show View  Other…​  Git  Git Staging menu.

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

A 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 explorer view adds information about which Git repository is used to the project name. 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.

The Eclipse IDE allows you to view the content of a commit. For example,if you are in the Git repositories view you can open a commit via the main Eclipse menu. To do this select the Navigate  Open Git Commit menu entry.

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. You can also reveal it in the history view.

You can use the Git Repositories view to pull, push and fetch to remote repositories. Right click on your repository and select the appropriate operation.

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:

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

Git amend allows you to adjust the last commit. For example you can change the commit message or add another modification.

The Git Staging view allows you to perform the Git amend command via the highlighted button in the following screenshot.

Right-click your project and select Team  Switch to  New Branch to create new branches or to switch between existing branches.

You can also switch branches in the History view or the Git repositories view.

Eclipse supports merging of branches to add the changes committed on one branch into another branch.

Checkout the branch into which you want to merge the changes and select your project and Team  Merge to start the merge dialog.

The Git Repositories view allows you to rebase your currently checked out branch onto another branch.

Right-click on a repository node and select Rebase as depicted in the following screenshot.

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

If the rebase was successful a dialog is shown. You have to resolve rebase conflicts if they occur. After resolving them, select Rebase  Continue.

If you want to skip the conflicting commit and continue with the rebase operation use Rebase  Skip.

To cancel the rebase operation select Rebase  Abort.

If during a Git operation, two changes are conflicting, you have to solve these conflicts manually. Eclipse highlights the affected files in the Package Explorer and Project Explorer view.

Eclipse Git supports the resolution of these merge conflicts.

To trigger this via the explorer views, right-click on a file with merge conflicts and select Team  Merge Tool.

You can also use the Git staging view to find the conflicting files. In large projects this is usually faster than navigating the Package Explorer or Project 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 and non-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 changes from right to left.

Eclipse also allows you to show the common ancestor of both commits to make the merge easier. Press the Hide/Show Ancestor Pane button for that. This is demonstrated by the following screenshots.

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 commit via Team  Commit.

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.

Commits are not visible in the Git history if they can’t be reached from a branch or tag. This might happen during a reset, commit amend or rebase operation. By default, such invisible commits are removed after two weeks by the Git system.

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

In the History view, you can cherry-pick a commit via the context menu. Cherry-pick allows you to move selected changes described by a commit to another branch. You can also use it in combination with a Git reset to perform a simplified interactive rebase.

Let’s assume the following situation, in which you would like to remove the "Bad commit" from the history described by the master branch.

You could start with a hard reset of the branch to origin/master. This will move the master branch pointer to the commit described by origin/master. The Good and the bad commit are not reachable anymore by the master branch.

To re-apply the changes by the "Good commit", cherry-pick the good commit.

This results in a history without the bad commit.

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

To create a patch for a set of changes with Eclipse, select the resources for which you want to create a patch in the Package Explorer view. Now, right click and select Team  Create Patch.

The resulting file can be used to get applied to another Git repository, via Team  Apply Patch. You can also apply the patch on a system where Git isn’t installed at all, i.e., you don’t need a Git repository to apply a patch.

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

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.

A commit adds a new version to the repository. This version is described by a commit message.

The commit message details the changes recorded in a commit. It should help users understand the repository’s history.

A commit message should be descriptive and informative without repeating the code changes.

A commit message should consist of a header and a body. The header should be less than 50 characters and the body should wrap at 72 characters. The body is separated from the header by an empty line.

This format ensures the commit message displays well on the command line and in graphical tools.

The body should explain why the change was made. The actual changes can be reviewed with Git.

Use the imperative mood for commit messages, e.g., "Add better error handling" rather than "Added better error handling".

The last paragraph may also include metadata as key-value pairs. This data is known as the commit message footer.

This metadata can trigger specific behaviors. For example, the Gerrit code review system uses the Change-Id key followed by a change-id. This change-id identifies the review associated with the message.

The commit message footer can also include items such as 'Signed-off-by' or link to a bug tracking system, e.g., 'Bug: 1234'.

The following example illustrates a well-structured commit message.

This example includes a reference to an issue. GitHub and other Git hosting services automatically recognize such references.

The following listing shows the output of the git log --oneline command from a repository with poor commit messages. The first value in each line is the shortened SHA-1, and the second is the commit message. This history is less informative.

The next listing shows the history of another repository with improved commit messages. This history provides a clearer overview of the activities.

If you need more assistance we offer Online Training and Onsite training as well as consulting

See License for license information.