I have never used intelliJ's integration for git so I can't tell you how good it is. One sure thing though, is that to learn the basics of git, you will probably be better off using the CLI for quite some time before using some IDE's integration. Those tend to hide away important stuff about how git works and in the first days, you don't want that. I have seen several devs using only webstorm's git integration (they never used the CLI) and they had some weird misconceptions about the basic git workflow, basically making the whole team lose quite some time. If you want to go on the CLI path, one of the key things to configure on your git setup is the difftool . It will behave just like git diff, but will pass the differences to a tool you chose. git diff is cool but it does not do a great job to compare several nested files in a project tree. I know this is not everybody's cup of tea, but I have been using beyond & compare for this for several years now; when I want to control big diffs and it never failed me. Here is what it looks like .

Make sure you've staged some changes. Otherwise, git commit -v will show you a block similar to what you posted, but not do anything. You can stage changes manually with git add, or if the files are already versioned, you can use git commit -a -v to stage and commit the changes.

For example:

$ echo "more foo" >> foo.txt
$ git commit -v
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   foo.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

Staging the change shows the diff with git commit -v:

:: git add foo.txt
:: GIT_EDITOR=cat git commit -v

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   foo.txt
#
diff --git a/foo.txt b/foo.txt
index 257cc56..a521556 100644
--- a/foo.txt
+++ b/foo.txt
@@ -1 +1,2 @@
 foo
+more foo
Aborting commit due to empty commit message.

If you just want to see the diff without committing, use git diff to see unstaged changes, git diff --cached to see changes staged for commit, or git diff HEAD to see both staged and unstaged changes in your working tree.

UPDATE: given your edit, what you really want are the git diff derivatives above. I'm not sure how Aptana Studio works. It may not follow the typical command line git flow. On the command line, you'd stage your changes, and then commit. And the above git diff commands are what you'd use to examine those changes. I typically alias them as git unstaged, git staged, and git both by adding this to my ~/.gitconfig:

[alias]
    # show difference between working tree and the index
    unstaged = diff

    # show difference between the HEAD and the index
    staged = diff --cached

    # show staged and unstaged changes (what would be committed with "git commit -a")
    both = diff HEAD

Hi Brandon, I'd recommend that you go and have a quick read of the git add (https://git-scm.com/docs/git-add) and the git commit (https://git-scm.com/docs/git-commit) commands documentation. As documentation goes it's quite approachable. Basically you use the 'git add' commands to make sure that git is aware of the changes that you have been making to files. Then you use the 'git commit' commands to well ... commit those changed files to your repository. "git add can be performed multiple times before a commit. It only adds the content of the specified file(s) at the time the add command is run; if you want subsequent changes included in the next commit, then you must run git add again to add the new content". So I believe that if you make a change to a file, use git add to stage that file ready for your commit but then make further changes to the file then you will need to run a git add against the file again otherwise it will only commit the changes from the last add. Maybe Running 'git commit' will commit all of the file snapshots that are currently staged using the 'git add' commands. But you can selectively commit files by using the file name as an argument to the commit command ... but I'm not sure if that will use the latest version of that file that you staged or if it will just take the file directly including any updates that you had not staged using an add. Hmm ... I think the best think to do is to set yourself up a git repository and have a play. Have a look at the docs and try a few things out. So as Steve has already said "I hope that helps - I'm not sure it did!" :-) "how does git know what change you're commiting?" - The direct answer would be that if you are not specifying a filename as part of the commit command, then it will commit all of the changes that you have previously staged using the git add commands since your last full commit. You can use the git status command to get the listing of the files that are currently staged and will be committed.

Thanks all, I have found the correct way, here it is.

#!/bin/bash
from_id=$1
to_id=$2
#echo $from_id
#echo $to_id
diffpath='patch/diff.log'
newpath='patch/new/'
oldpath='patch/old/'
rm -rf patch
mkdir -p $newpath
mkdir -p $oldpath
git diff $from_id $to_id --raw > $diffpath
cat $diffpath | while  read line
do 
    #echo =====================================
    #echo $line
    OLD_IFS="$IFS"
    IFS=" "
    arr=($line)
    IFS="$OLD_IFS"   
    #echo ${arr[4]}
    filepath=${arr[4]##* }
    #echo $filepath
    newid=${arr[2]%%...}
    #echo $newid
    oldid=${arr[3]%%...}
    #echo $oldid  

   if [ "$newid"x != "0000000"x  ]; then   
     newfilepath=${newpath}${filepath}
     echo $newfilepath
     dirpath=${newfilepath%/*}
     echo $dirpath
     mkdir -p ${dirpath}
     git cat-file -p $newid >  ${newfilepath}
   fi

   if [ "$oldid"x != "0000000"x  ]; then 
     oldfilepath=${oldpath}${filepath} 
     echo $oldfilepath
     dirpath=${oldfilepath%/*}
     echo $dirpath   
     mkdir -p ${dirpath}
     git cat-file -p $oldid >  ${oldfilepath}
   fi   
done 

You will found the new directory named patch in current working directory after doing this.