In this post I will continue to use the same remote repository which was used in the previous post.

Basic operations

In the first post about Git we discussed the basic Git operations. Now let’s see how you can do the same using EGit plugin.

Add files

Create com.churbanov.tutorial.egit package and the following two classes:

1
2
3
4
5
6
7
8
9
10
11
12
13

package com.churbanov.tutorial.egit;

/**
 * Represents workshop where different works with cars, boats
 * and other vehicles can be done.
 *
 * @author Dmitry Churbanov
 */
public class Workshop {
  public static void main(String[] args) {
    System.out.println("Welcome to our Workshop!");
  }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

package com.churbanov.tutorial.egit;

public class Part {
  private Long id;
  private String name;

  public Long getId() {
    return id;
  }
  public void setId(Long id) {
    this.id = id;
  }
  public String getName() {
    return name;
  }
  public void setName(String name) {
    this.name = name;
  }
}

Now we need to tell Git to start tracking just added classes. To do so, we select Part.java and Workshop.java classes in eclipse package explorer -> Team -> Add

Commit changes

To commit changes select Team -> Commit. The “Commit Changes” window will pop up and you will need to enter commit message and select what files you want to commit or unselect the files you don’t want to commit. Press “Commit” and all the changes will be committed.

After commit you can see that Workshop.java and Part.java files icons are changed in package explorer.

Push changes

To push the changes to the remote repository select Team -> Push. The current version of EGit (0.8.4) has a bug and in most cases push will not work (more is here). There is a small workaround (see Comment #2 in that bug discussion), but it still didn’t work for me on my Ubuntu 10.04. So I did it in command line. (Just after I had published this post I found that EGit doesn’t support pushing via https. More is here.)

Other useful things

The other useful things which you can do with EGit are:

Tags

Select “eclipse_git” project folder -> Team -> Tag. Enter tag name, tag message and press OK button.

History of a particular resource

Select any resource (project, package, class, etc) -> Show In -> History. And you can see all the history of the selected resource in the Git repository.

Branches

If you want to make a branch, select “eclipse_git” project folder -> Team -> Branch.

In the appeared window select “master” in the “Local Branches” category -> press “New branch” button -> enter new branch name -> press OK button. New branch will be created.

To switch to the new branch select “eclipse_egit” project folder -> Team -> Branch -> select the branch you want to switch to -> press Checkout button.

Useful links

• Using Git: http://www.churbanov.com/blog/2010/07/08/using-git-part-1/
• Eclipse EGit plugin: http://www.churbanov.com/blog/2010/07/12/eclipse-egit-plugin/
• EGit user guide: http://wiki.eclipse.org/EGit/User_Guide
• Git community book: http://book.git-scm.com/
• Git reference site: http://gitref.org/index.html

In this tutorial I will show the basic steps of creating Java project in eclipse using EGit plug-in. Eclipse “Helios” and EGit version 0.8.4 are used in this tutorial.

Install EGit plugin

Start eclipse. Go to Help -> Install New Software… In the “Work with” select “All Available Sites”. And then in the search box enter git. You will see the following picture:

Select “Eclipse EGit (Incubation)”:

Click Next. Eclipse JGit plugin will be installed automatically as a dependency of EGit plugin:

Press “Next”, accept the terms of the licence agreement:

press Finish and after some time plugins will be installed. Restart eclipse.

Import Git repository and create new project

After eclipse is restarted select File -> Import…, and you will see the new category: Git. Expand it and select “Projects from Git”. Press next.

The next window will ask you about Git repository location. You can see two buttons there: Clone and Add. Add button should be used when you already have a local copy of Git repository. If you don’t have such copy, you need to press Clone button.

In this tutorial we will import remote Git repository, i.e. at this moment we do not have a local copy of this repository on our hard drive. The Git repository which we are going to import has been already created on github.

So, press Clone button and enter all location parameters. If you go to the github project properties, you can select what protocol are you going to use. I have selected https. Here is an example (if you just copy and past url from github to URI field all other fields, except password, should be filled out automatically):

If all parameters are correct, after pressing Next button you will see the branch selection window. In my case I do not have any branches, therefore I just press Next and select where the local copy of the Git repository will be stored. And here is the problem. You should save the copy of your Git repository in the same folder where you plan to create eclipse project. If you save Git repository in another folder, you will not be able to “share” your project with that repository. There is a solution which solves this problem, but we will talk about it later.

After that select just added Git repository and press Next button:

and “Import Projects from Git” window will appear. As we are going to create new project select “Use the New Projects wizard” and press Finish.

Now we will create new Java Project using default parameters:

and here it is:

We can see the name of eclipse project (“eclipse_git”), name of Git repository (“eclipse_git”) and repository branch (“master”).

Let’s start – Configuration

Git comes with a git config tool. It helps you to set and get configuration parameters and control all aspects of Git. All configuration parameters can be found at three places:

• /etc/gitconfig – contains global parameters for all users of your system. Gets and sets parameters if you pass --system option to git config.
• ~/.gitconfig – contains parameters specific to current user. Works if you pass --global option to git config.
• .git/config – contains parameters specifically for the git repository you are currently using. Don’t need to pass any parameters when using git config. Works by default.

All parameter values overwrite values on other levels, i.e. if some value for some parameter is specified in /etc/gitconfig file and another value for the same parameter is specified in ~/.gitconfig file, the value from the last file will be used. The same works for values in ~/.gitconfig and .git/config files. In that case the value from .git/config file will be used.

First things which you need to do is to define your identity:

1
2

$ git config --global user.name "Dmitry Churbanov"
$ git config --global user.email dmitry.churbanov@someemail.com

that code will assign git user name and email address for current user of a system. If you want to set up user name and email just for current project which you are working on right now you need to run the following code:

1
2

$ git config user.name "Dmitry Churbanov"
$ git config user.email dmitry.churbanov@someemail.com

If you want to check the value of any parameter you need to run the next code:

1

$ git config parameter-name

where parameter-name is the name of a parameter. For example, to see the name of a user or email you can check it in the following way:

1
2
3
4

$ git config user.name
Dmitry Churbanov
$ git config user.email
dmitry.churbanov@someemail.com

Initialise repository

To initialise git repository go to the directory where you want the repository to be placed and run:

1

$ git init

After this command is executed you will see .git subdirectory which contains all the repository files. This is the only repository where Git stores its configuration files and the history of all changes.

Add files

After you initialised the repository it does not contain any files. To tell Git to start tracking a file you first need to create it in the directory or to copy it to the directory and run:

1

$ git add filename

where filename is a name of a file to start to track. You can also run:

1

$ git add .

and Git will start to track all the files in the current directory and all the subdirectories which it doesn’t track at this moment. You can also use some kind of regular expression. If you want to add only .java files you need to run the following command:

1

$ git add *.java

Committing files and file states

After you added some files you told Git that you want to start to keep track these files in the future, i.e. you want to include these files in your next commit command. This state of files in the Git repository is called: staged. After you added all the files and are ready to make commit you need to run:

1

$ git commit -m "commit message"

where commit message is a message which goes with this commit and should describe the purpose of the commit. For example, when you fixed a bug and commit you changes you most probably will include some information which describes what bug it is or its number or something else.

If you just run git commit (or git commit -a) command you then will be asked to write “commit message”. It is recommended to run commit command without -m flag if your message is longer than one line. And in most cases it will and should be longer and detailed.

After you made commit, all files which were committed got a committed state. If file was committed and them modified, it got a modified state. So, there are three states which tracked files can have:

• staged – when you told to include the file in the next commit (run add command)
• commit – when file was committed and was not changed after this
• modified – when file was committed and was changed after this

I wrote tracked earlier to point out that these are the files which Git is tracking. If file is not tracked by Git, it is called untracked. Untracked files are all files which are not tracked.

Status of the files

To check status of all files and to find their states, you need to run:

1
2
3
4
5

$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#
nothing to commit (working directory clean)

You can see something like you see above. It means that I made commit and didn’t push my changes (push command is discussed later). Or you can see:

1
2
3

$ git status
# On branch master
nothing to commit (working directory clean)

which means that your local (working) copy is in the same state as a remote repository.

Ignoring files

Sometimes you don’t want to include some files in the repository but you still want these files to be present in the folder. This can be some of your personal files, logs or anything else. You can say Git to ignore these files. To do so you need to create .gitignore file and write file names or file name patters there.

For example, if you want to say Git to ignore all .txt files you need to have the following in the .gitignore file:

1

*.txt

If some file matches the regular expression which is in the ignore file but you want to tell Git to keep track that particular file, you can do it in the next way:

1
2
3

#Text files should be ignored (this is a comment, which is ignored in the .gitignore file)
*.txt
!important.txt

In such case important.txt file will be tracked by Git, even if all .txt files are ignored.

Diff command

When changes are made and git status command is executed, you can be wondered, what exactly is changed in the files which are modified. You can use git diff command. This command shows you what changes have been made. The following command:

1

git diff [path]

will show you what changes have been made in a specific file, if instead of path you write path to the file; or what changes have been made in all files of a specific folder if instead of path you write path to that folder. To see all options of diff command run git diff --help.

One very important note: If you have already added a file, say file1.txt, by running git add file1.txt command. And after that you made some changes in that file, then if you run git diff file1.txt you will not see the latest changes. It is because after you run git add file1.txt Git cached the context of file1.txt file at that moment. To see cached changes you need to run:

1

git diff --cached [path]

And if you run git commit your latest changes will also not be committed. To add the latest changes you need to run git add after each modification. But there is one trick. You can use -a option with the git commit command to commit all files which were previously tracked and were modified. It allows you to skip git add every time you make any change and run it only once.

Removing files

If you want to remove file, i.e. to remove it from the repository (and remove it from your hard drive) you need to run:

1

$ git rm [path]

This command tells Git to remove file. After the next commit command this file will be removed from the repository. But if you want to leave file on your hard drive and only stop to keep tracking that file, you need to run:

1

$ git rm --cached readme.txt

Moving files

To move file or rename it you need to run the following command:

1

$ git mv [file-name] [new-file-name]

But it is very interesting that Git doesn’t actually track if you moved your file or not. It is somehow explicitly figures out that you renamed the file after you run something like this:

1
2
3

$ mv file.txt new_file.txt
$ git rm file.txt
$ git add new_file.txt

Try to run git status and see what happens. It is very convenient because you can rename or move file using whatever tool or program you want and them just remove and add it using Git rm and add commands.

Help

If you need help with any command use git help [command] or git [command] --help. For example, to get help with commit command you need to run:

1

$ git help commit

This is it for the first post in the “Using Git” series. I think you have read pretty enough material to start using Git.

Mercurial repository is self-contained. It means that all changes you have made will exist only in your local repository until you decide to propagate these changes to the remote one.

This series of posts is how to start working with Mercurial. If you are looking for a book, there is a very good one which is publicly available: Mercurial: The Definitive Guide by by Bryan O’Sullivan. And I advise you to read it.

In the beginning

All Mercurial commands starts from hg. The hg command provides a command line interface to the Mercurial system. In general each command has the following syntax:

1

hg command [options]...[arguments]...

Setting up a new Mercurial project

Let’s say you want to create a local repository named repository-main:

1
2
3

$ mkdir repository-main
$ cd repository-main
$ hg init

init command initializes new repository in the current folder. Here is a more shorter way of creating the local repository:

1

$ hg init repository-main

If you check repository-main folder you can see .hg folder there.

1
2
3
4

$ ls -la
$ .
$ ..
$ .hg

.hg folder is the only folder where Mercurial keeps all repository related information.

But hardly ever you will create repository on you local computer. Most probably you will use one of the many hosting services to host your repository there. One of the lists of such places you can find here.

Working with existing Mercurial repository

Let’s assume you are using one of the services to host your Mercurial repository (for this post I have used Project Kenai). To clone files from remote repository and create a local copy on your machine use clone command:

1
2
3
4

$ hg clone ssh://dzmitryc@hg.kenai.com/project-test1~source-code-repository project-test1
no changes found
updating working directory
0 files updated, 0 files merged, 0 files removed, 0 files unresolved

clone command created new directory project-test1 and checked out the latest version of the default branch. In Mercurial, the newest version of the branch is called tip. To see the logs about the newest version of the repository you can execute the tip command:

1
2
3
4
5
6

$ cd project-test1
$ hg tip
changeset:   -1:000000000000
tag:         tip
user:
date:        Thu Jan 01 00:00:00 1970 +0000

As our repository is new and empty we don’t see much info.

What about adding new files?

Now lets create the file HelloWorld.java with the following content:

1
2
3
4
5

public class HelloWorld {
  public static void main(String args[]) {
    System.out.println("Hello World!");
  }
}

We have the next in our folder project-test1:

1
2
3
4
5

$ ls -la
$ .
$ ..
$ HelloWorld.java
$ .hg

If we run hg status command we’ll see the following:

1
2

$ hg status
? HelloWorld.java

The status command shows the status of files in the repository. In our case we can see ? (question mark) before the HelloWorld.java file. It means that this file is not tracked by Mercurial. The next codes are used to show the status:

• M = modified
• A = added
• R = removed
• C = clean
• ! = missing (deleted by non-hg command, but still tracked)
• ? = not tracked
• I = ignored

Now if you want to tell Mercurial to start to track the file and add it to the repository you need to execute hg add command:

1

$ hg add HelloWorld.java

You can check that Mercurial is tracking just added file by executing hg status command:

1
2

$ hg status
A HelloWorld.java

Committing changes

To commit the changes you need to execute hg commit command:

1

$ hg commit

Just after you press Enter button Mercurial will run a text editor and ask you to write a comment:

1
2
3
4
5
6
7
8

_

HG: Enter commit message.  Lines beginning with 'HG:' are removed.
HG: Leave message empty to abort commit.
HG: --
HG: user: dmitry@dmitry-laptop
HG: branch 'default'
HG: added HelloWorld.java

Lines started with HG will be removed. It is better to wright a good and clear comment so later you can find out what was the purpose of the commit. In our case we can wright something like: “Add new file HelloWorld.java”.

Another way of committing is to execute:

1

$ hg commit -m 'Commit message'

where instead of ‘Commit message’ text you can write your commit comment.

Now if you execute hg status command you see nothing. It is because status command only shows files with which something needs to be done. Files which have already been tracked and were not changed will not be shown. After executing hg commit command all changes will be saved in your local repository.

Moving changes to the remote repository

As it has been said, each local repository is a full copy of a working repository. And if you make any changes in a local repository and make commit, changes are not automatically propagated to the working repository until you decide to do so.

Let’s say you are fixing bugs. And every day you are fixing only one bug. And after the work was done you commit your changes to the local repository. But at the end of each week you decide to move all your changes from your local repository to the working one. To do so you need to execute hg push command:

1
2
3
4
5
6
7

$ hg push
pushing to ssh://dzmitryc@hg.kenai.com/project-test1~source-code-repository
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files

Our changes were pushed to the remote repository and new changeset was created.