Sunday, June 23, 2013

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

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

Installing EGit


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

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.
You can also enter the default folder for storing Git repositories via the WindowPreferencesGitTeamDefault Repository Folder entry.

EGit default repository folder

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

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 TeamIgnore 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 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 hightlighted 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 good 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 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.

Git icon decorator in the Package Explorer


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.

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.

Note

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

Note

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


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

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.

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.

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


Git reset

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.

Reset in EGit

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

Stash changes in EGit


Stash changes in EGit


Stash changes in EGit


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 FileImportGitProjects from Git as explained before.

Import project from Git repository

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

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

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



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.

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.

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

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

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

Install Mylyn Github connector

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

Importing tasks into Eclipse

You can also import now directly projects from Github repositories.

Importing projects from Github into EclipseF

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:
Flattr this


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

No comments:

Post a Comment