text: This tutorial describes the usage of the Eclipse IDE to perform Git operations.
  1. Git support for Eclipse
  Via the Eclipse IDE you can perform Git commands like staging, commit, merge, rebase, pull and push.
  2. Installation of Git support into Eclipse
  Most Eclipse IDE distributions from Eclipse.org already contain support for Git. In this case no additional installation is required.
  If the Git tooling is not available, you can install it via the Eclipse installation manager. Select themenu entry. Enter one of the following update site URLs:
  # Use this update site to get the latest release # use this update site to get the night build
  The dialog to install the Eclipse Git team provider is depicted in the following screenshot.
  3. Configuration for Git usage via the Eclipse IDE
  3.1. Configure user and email
  In your Eclipse IDE, select theentry. 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.
  3.2. Configure Git to rebase during pull operations
  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 recommended setting by the author of this text.
  3.3. Validate the setup
  After this setup, the configuration should look similar to the following screenshot.
  3.4. Configuring the proxy settings
  If you are using a proxy server, you can configure it via.
  4. Exercise: Working with Git repository in Eclipse
  The following exercise explains how to use the Eclipse IDE to perform Git operations. To ensure that you have a Git repository, you first create a new local Git repository via the Eclipse IDE.
  4.1. Create a new Git repository via Eclipse
  Open the Git Repositories view via themenu entry. From the toolbar, select the Create a new Git repository and add it to this view entry.
  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 users home directory.
  Press the Create button. Now the Git repository is created and a reference to it is added to the Git Repositories view.
  4.2. Create .gitignore file
  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 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.
  bin *.class
  4.3. Create a new project
  Create a new Java project called
  com.vogella.git.first via the menu entry.
  Right-click on the source folder and select
  com.vogella.git.first package.
  Right-click on the package folder and selectand create the following class.
  package com.vogella.git.first; public class GitTest { public static void main(String[] args) { System.out.println("Git is fun"); } }
  4.4. Put project under Git version control
  To put your new project under version control with Git, right-click on your project, select.
  Afterwards, select your existing Git repository from the drop-down list and press the Finish button.
  Press the Finish button. Your project is now moved to your Git repository.
  The following screenshot shows the directory in the Git Repository view.
  The
  .git directory contains the Git repository, the other directories contain the files of the working tree.
  4.5. Using the Git Staging view for the initial commit
  Open the Git Staging view, via. In this view drag all files into the Staged Changes area, write a meaningful commit message and press the commit button.
  4.6. Change a file and commit the change
  Change the
  System.out.println message in your
  GitTest class.
  package com.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.adoc.
  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.
  4.7. Commit more files
  Commit the
  Readme.adoc file.
  By now you should know that you have to stage the file and commit it.
  4.8. Configure the History view
  Open the History view via themenu entry.
  In the History view click all toggle buttons as shown in the screenshot
  Link with Editor and Selection
  Show all changes in repository containing the selected resources
  Show all Branches and Tags
  Afterwards, use the History view to review which files were included in your individual commits.
  4.9. Open an older version with the current version of a file via the History view
  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, find the file selected in the commit and select Open this version via the context menu.
  4.10. Accidently add a unwanted file an remove it
  Create a new file nammed 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 it to your .gitignore file.
  Make a change to your test.unwanted file
  Git shows it as change, as changes in .gitignore only apply to new files You need to untrack the file.
  Select the file and select Team → Untrack (or Team → Advanced → Untrack on latest Git support for Eclipse).
  Stage and commit the change.
  4.11. Add more projects to your Git repository
  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.
  Select your Git repository in the following dialog and add both projects to this repository. Press the Finish button.
  4.12. Validate the project move and commit changes
  Afterwards validate that the projects have been moved. You can checking your workspace directory and your Git repository directory via a file explorer. You see that the projects have been moved from there 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.
  5. Exercise: Clone an existing repository
  In this exercise you will clone a Git repository and import the existing projects from this repository into your workspace.
  For this, select.
  Select Clone URI in the next dialog.
  Enter the URL to your Git repository which you want to clone. You can use the following example URI.
  git://github.com/vogella/eclipse4book.git
  The above link uses the git protocol, alternatively you can also use the http protocol:
  After pressing the Next button the system will allow you to import the existing branches. Select at least the master branch.
  The next dialog allows you to specify where the repository should be copied to and which local branch should be created initially.
  After the Git repository is cloned, you can import existing projects.
  Once this dialog is completed, you have clone the remote repository into a local Git repository. You can use Git operation on these projects.
  6. Exercise: Import projects from an existing repository
  If you have already an existing Git repository you can add it to the Git Repostory view. Afterwards you can import the projects into your workspace via themenu entry.
  Select Local if you want to important from a local repository or Clone URL if you first want to clone the repository.
  The following screenshot shows multiple local repositories. To import the project contained in one of them, select one entries and press the Next button. To add a new local repository to this dialog (and the Git repositories view) use the Add… button.
  The wizard allows you to specify the projects to import. After the import the Eclipse IDE is aware that these projects are part of a Git repository.
  7. Exercise: Using interactive rebase in Eclipse
  Git allows to adjust the local commit history via the interactive rebase functionality. Eclipse provides support for simplified versions of this as well as support for full interactive rebase operations. This includes changing the order of commits or combining, removing and adjusting commits.
  7.1. Simple interactive rebase operations available via the History view
  To reword a commit, right-click on it in the History view and selectto change the commit message.
  You can squash several commits by selecting them in the History view. Select afterwards themenu entry from the context menu.
  The above options are simplified ways to do an interactive rebase.
  7.2. Performing a full interactive rebase via Eclipse
  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.
  8. Additional configuration options for Git
  8.1. Git user settings in Eclipse
  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. Selectto see the current configuration and to change it.
  8.2. Default clone location
  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 theentry in the Default Repository folder field.
  8.3. Configuring the toolbar and the menu for Git usage
  To simplify access to the common Git operations you can activate the Git toolbar. For this selectand 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.
  8.4. Eclipse support for SSH based authentication
  You can create an SSH key pair in Eclipse for SSH based communication. This can be done via.
  9. Details on the Git views
  9.1. Using the Git Repositories view
  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
  The toolbar allow you to:
  add an existing local repository to the view
  clone a repository
  create a new repository
  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.
  9.2. Using the Git Staging view
  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 list 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 themenu.
  9.3. Git integration into the Package and the Project Explorer
  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 the information 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.
  9.4. Using the History view for viewing the Git history
  9.4.1. Purpose of the history view
  The History view allows you to analyze the history of your Git repository and to see to which commits the branches and tags points. This view displays author, date, commit message and the modified files of a commits.
  This view is depicted in the following screenshot.
  You can open this view via. Alternatively you can open it via the repository node in the Git Repositories view. For this click on the entry. Some views, e.g., in the Java EE-Perspective, do not have this shortcut, in this case use .
  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.
  You can also configure the History view to display the history of the current selection. Select the highlighted button in the following screenshot for that.
  If you select a commit you see the commit message and the involved files.
  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.
  9.4.2. The History view filters
  The History view has quite some options to configure which commits are displayed. Its toolbar allows you to customize which commits are displayed. By default, the History view filters the history based on the current selection and shows only the active branch.
  If you work with several branches, e.g., because you are using Gerrit for code reviews, you typically want to see all branch information and remove the filter based on the resource.
  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 highlighted buttons with the Show all changes in this repository and Show all branches and tags tooltips.
  The following listing gives an overview of the purpose of the different buttons.
  Depending on your use case you may want to select the following option:
  show only those commits which are reachable from the current branch. Hide all commits on other topic branches.
  see only those commits which changed the selected resource (file, project, subfolder) or it’s children. E.g. display only those commits which touched the selected java file. The current selection is shown in the top right corner of the History view.
  see only those commits which changed anything in the parent folder of the selected resource (file, project, subfolder) or it’s children. E.g. display only those commits which changed the same package as the selected java source.
  see only those commits which changed anything in the same project as the selected resource or it’s children. Used when you are working in a repository which contains multiple projects.
  don’t filter at all. Show all commits of the current repository
  The options b., c. and d. are tied to the currently selected resource. Button g. allows that the history view automatically updates when you change the selection.
  9.4.3. Using search
  You can also search for commits based on committer, author, ID or comment. For this turn on the Show Find toolbar (f) and type in a search string in the Find field. The commits fitting to your search are highlighted. You can combine this search with the filters explained above.
  9.4.4. Showing details of a commit
  If you want to see more details about a commit, right-click it and select the Open in Commit Viewer entry.
  9.5. Commit Viewer
  The Eclipse IDE allows 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 themenu 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.
  10. Performing Git operations in Eclipse
  10.1. Pull, push and fetch
  You can use the Git Repositories view to pull, push and fetch to remote repositories. Right click on your repository and select the appropriated operation.
  10.2. Basic team 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:
  , to add the selected resource(s) to the Git index
  , to open the commit dialog to create a new commit
  , to create a patch
  , to apply a patch to your file system
  , to add a file to the .gitignore file
  , to display the history of the selected resources(s)
  10.3. Team operations available on the project
  If you select a project you can use additional team operations from the context menu.
  to pull in changes from your remote Git repository
  to fetch the current state from the remote repository
  to checkout existing or create new branches
  to push changes to your remote Git repository
  to create and manage tags.
  10.4. Amending a commit
  Git amend allows adjusting 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.
  10.5. Creating and switching branches in Eclipse
  Right-click your project and selectto create new branches or to switch between existing branches.
  You can also switch branches in the History view or the Git repositories view.
  10.6. Starting a merge operation in Eclipse
  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 into and select your project andto start the merge dialog.
  10.7. Rebasing a branch onto another branch
  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.
  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.
  If you want to skip the conflicting commit and continue with the rebase operation use.
  To cancel the rebase operation select.
  10.8. Solving conflicts created by merge, rebase or other operations
  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.
  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 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, selectfrom the context menu of the resource to mark the conflicts as resolved and commit the merge commit via .
  10.9. Git reset and Git reflog
  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.
  10.10. Finding "invisible" commits with the Reflog view
  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.
  10.11. Selecting individual commits via git cherry-pick
  In the History view, you can cherry-pick a commit via the context menu. Cherry-pick allows to move selected changes describes by a commit to another branch. You can also use it in combination with a Git reset to perform a simplified interactive rebase.
  Lets 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.
  10.12. Comparing and replacing files based on the Git history
  10.12.1. Comparing files
  Eclipse Git allows you to compare a selected file, folder or project with another commit or with the Git index. Useto open the menu. Afterwards select with what you want to compare. The HEAD Revision selection is depicted in the following screenshot.
  10.12.2. Replacing files
  Themenu entry allows you to replace the current selection with the version contained in the selected commit or the Git index.
  11. See Git information line by line (aka git blame)
  Eclipse allows to display the information which commit and person change a line. To enable this, right-click on your file and select.
  Afterwards, you can place the mouse on the left side of the editor. A popup dialog shows the commit information and the change applied by the shown commit.
  11.1. 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.
  11.2. Creating patches
  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.
  The resulting file can be used to get applied to another Git repository, via. 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.
  12. Using Eclipse Git with GitHub
  12.1. Clone project
  Copy the URL from GitHub and select in Eclipse from the menu the
  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 thepreference setting. This setting is depicted in the following screenshot.
  12.2. Push changes
  After you made changes and committed them to your local repository, you can selecton the project folder, to push your changes to your GitHub. This requires write access to the GitHub repository.
  13. Writing good commit messages
  13.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. It should help the user to understand the history of the repository.
  A commit message should therefore be descriptive and informative without repeating the code changes.
  13.2. Guidelines for useful commit messages
  A commit message should have a header and a body. The header should be less than 50 with a maximum of 72 characters. The body should wrap its text at 72. The body is separated from the header by an empty line.
  This ensures that the commit message is displayed well on the command line or in graphical tools.
  The body describes 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., "Adds better error handling" instead of "Added better error handling".
  The last paragraph can also contain metadata as key-value pairs. This data is also referred to as the commit message footer.
  This metadata can be used to trigger a certain behavior. For example, the Gerrit code review system uses the Change-Id key followed by a change-id. 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'. Or it may link to a bug tracking system, e.g., 'Bug: 1234'.
  13.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
  13.4. Good and bad example for a Git history
  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 Adds search and filter to the model editor tree 9a84a8a Missing DynamicMenuContribution in child selector 952e014 Fixes spelling error in Toolbar/Add child 71eeea9 Adds option to import model elements from legacy RCP 123672c New Application wizard is missing dependencies 97cdb9a Creates an id for handlers
  The above example also adds the corresponding bug number to the commit message. Some teams (like the Eclipse platform team) use this approach, others prefer to add the bug number to the commit messages.
  14. Contributing to EGit - Getting the source code
  This support is provided by the EGit project via a set of plug-ins (software component).
  Eclipse uses the JGit library to perform the Git commands. JGit is a library which implements the Git functionality in Java.
  EGit is hosted on git://git.eclipse.org.
  See EGit contributor guide for a description how to work with the EGit and JGit source.
  15. Eclipse Git