You can also rebase interactively. This is often used to re-write your

own commit objects before pusing them somewhere. It is an easy way to

split, merge or re-order commits before sharing them with others. You

can also use it to clean up commits you've pulled from someone when

applying them locally.

If you have a number of commits that you would like to somehow modify

during the rebase, you can invoke interactive mode by passing a '-i' or

'--interactive' to the 'git rebase' command.

$ git rebase -i origin/master

This will invoke interactive rebase mode on all the commits you have made

since the last time you have pushed (or merged from the origin repository).

To see what commits those are beforehand, you can run log this way:

$ git log github/master..

Once you run the 'rebase -i' command, you will be thrown into your editor

of choice with something that looks like this:

pick fc62e55 added file_size

pick 9824bf4 fixed little thing

pick 21d80a5 added number to log

pick 76b9da6 added the apply command

pick c264051 Revert "added file_size" - not implemented correctly

# Rebase f408319..b04dc3d onto f408319

#

# Commands:

# p, pick = use commit

# e, edit = use commit, but stop for amending

# s, squash = use commit, but meld into previous commit

#

# If you remove a line here THAT COMMIT WILL BE LOST.

# However, if you remove everything, the rebase will be aborted.

#

This means that there are 5 commits since you last pushed and it gives you

one line per commit with the following format:

(action) (partial-sha) (short commit message)

Now, you can change the action (which is by default 'pick') to either 'edit'

or 'squash', or just leave it as 'pick'. You can also reorder the commits

just by moving the lines around however you want. Then, when you exit the

editor, git will try to apply the commits however they are now arranged and

do the action specified.

If 'pick' is specified, it will simply try to apply the patch and save the

commit with the same message as before.

If 'squash' is specified, it will combine that commit with the previous one

to create a new commit. This will drop you into your editor again to merge

the commit messages of the two commits it is now squashing together. So,

if you exit the editor with this:

pick fc62e55 added file_size

squash 9824bf4 fixed little thing

squash 21d80a5 added number to log

squash 76b9da6 added the apply command

squash c264051 Revert "added file_size" - not implemented correctly

Then you will have to create a single commit message from this:

# This is a combination of 5 commits.

# The first commit's message is:

added file_size

# This is the 2nd commit message:

fixed little thing

# This is the 3rd commit message:

added number to log

# This is the 4th commit message:

added the apply command

# This is the 5th commit message:

Revert "added file_size" - not implemented correctly

This reverts commit fc62e5543b195f18391886b9f663d5a7eca38e84.

Once you have edited that down into once commit message and exit the editor,

the commit will be saved with your new message.

If 'edit' is specified, it will do the same thing, but then pause before

moving on to the next one and drop you into the command line so you can

amend the commit, or change the commit contents somehow.

If you wanted to split a commit, for instance, you would specify 'edit' for

that commit:

pick fc62e55 added file_size

pick 9824bf4 fixed little thing

edit 21d80a5 added number to log

pick 76b9da6 added the apply command

pick c264051 Revert "added file_size" - not implemented correctly

And then when you get to the command line, you revert that commit and create

two (or more) new ones. Lets say 21d80a5 modified two files, file1 and file2,

and you wanted to split them into seperate commits. You could do this after

the rebase dropped you to the command line :

$ git reset HEAD^

$ git add file1

$ git commit 'first part of split commit'

$ git add file2

$ git commit 'second part of split commit'

$ git rebase --continue

And now instead of 5 commits, you would have 6.

The last useful thing that interactive rebase can do is drop commits for you.

If instead of choosing 'pick', 'squash' or 'edit' for the commit line, you

simply remove the line, it will remove the commit from the history.

Interactive Adding is a really nice way of working with and visualizing

the Git index. To start it up, simply type 'git add -i'. Git will show

you all the modified files you have and their status.

$>git add -i

staged unstaged path

1: unchanged +4/-0 assets/stylesheets/style.css

2: unchanged +23/-11 layout/book_index_template.html

3: unchanged +7/-7 layout/chapter_template.html

4: unchanged +3/-3 script/pdf.rb

5: unchanged +121/-0 text/14_Interactive_Rebasing/0_ Interactive_Rebasing.markdown

*** Commands ***

1: status 2: update 3: revert 4: add untracked

5: patch 6: diff 7: quit 8: help

What now>

In this case, we can see that there are 5 modified files that have not been

added to our index yet (unstaged), and even how many lines have been added to

or removed from each. It then shows us an interactive menu of what we can

do in this mode.

If we want to stage the files, we can type '2' or 'u' for the update mode.

Then I can specify which files I want to stage (add to the index) by typing

in the numbers of the files (in this case, 1-4)

What now> 2

staged unstaged path

1: unchanged +4/-0 assets/stylesheets/style.css

2: unchanged +23/-11 layout/book_index_template.html

3: unchanged +7/-7 layout/chapter_template.html

4: unchanged +3/-3 script/pdf.rb

5: unchanged +121/-0 text/14_Interactive_Rebasing/0_ Interactive_Rebasing.markdown

Update>> 1-4

staged unstaged path

* 1: unchanged +4/-0 assets/stylesheets/style.css

* 2: unchanged +23/-11 layout/book_index_template.html

* 3: unchanged +7/-7 layout/chapter_template.html

* 4: unchanged +3/-3 script/pdf.rb

5: unchanged +121/-0 text/14_Interactive_Rebasing/0_ Interactive_Rebasing.markdown

Update>>

If I hit enter, I will be taken back to the main menu where I can see that

the file status has changed:

What now> status

staged unstaged path

1: +4/-0 nothing assets/stylesheets/style.css

2: +23/-11 nothing layout/book_index_template.html

3: +7/-7 nothing layout/chapter_template.html

4: +3/-3 nothing script/pdf.rb

5: unchanged +121/-0 text/14_Interactive_Rebasing/0_ Interactive_Rebasing.markdown

Now we can see the first four files are staged and the last one is still not.

This is basically a compressed way to see the same information we see when

we run 'git status' from the command line:

$ git status

# On branch master

# Changes to be committed:

# (use "git reset HEAD <file>..." to unstage)

#

# modified: assets/stylesheets/style.css

# modified: layout/book_index_template.html

# modified: layout/chapter_template.html

# modified: script/pdf.rb

#

# Changed but not updated:

# (use "git add <file>..." to update what will be committed)

#

# modified: text/14_Interactive_Rebasing/0_ Interactive_Rebasing.markdown

#

There are a number of useful things we can do, including unstaging files (3: revert),

adding untracked files (4: add untracked), and viewing diffs (6: diff). Those

are all pretty straightforward. However, there is one command that is pretty

cool here, which is staging patches (5: patch).

If you type '5' or 'p' in the menu, git will show you your diff patch by patch

(or hunk by hunk) and ask if you want to stage each one. That way you can

actually stage for a commit a part of a file edit. If you've edited a file

and want to only commit part of it and not an unfinished part, or commit

documentation or whitespace changes seperate from substantive changes, you can

use 'git add -i' to do so relatively easily.

Here I've staged some changes to the book_index_template.html file, but not all

of them:

staged unstaged path

1: +4/-0 nothing assets/stylesheets/style.css

2: +20/-7 +3/-4 layout/book_index_template.html

3: +7/-7 nothing layout/chapter_template.html

4: +3/-3 nothing script/pdf.rb

5: unchanged +121/-0 text/14_Interactive_Rebasing/0_ Interactive_Rebasing.markdown

6: unchanged +85/-0 text/15_Interactive_Adding/0_ Interactive_Adding.markdown

When you are done making changes to your index through 'git add -i', you simply

quit (7: quit) and then run 'git commit' to commit the staged changes. Remember

**not** to run 'git commit -a', which will blow away all the careful changes

you've just made and simply commit everything.

You can also use stashing to queue up stashed changes.

If you run 'git stash list' you can see which stashes you have saved:

$>git stash list

stash@{0}: WIP on book: 51bea1d... fixed images

stash@{1}: WIP on master: 9705ae6... changed the browse code to the official repo

Then you can apply them individually with 'git stash apply stash@{1}'. You

can clear out the list with 'git stash clear'.