Copyright © 2008 Marius Vollmer

     Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts.

Magit User Manual
*****************

Magit is an interface to the version control system Git, implemented as an extension to Emacs.

Introduction
************

With Magit, you can inspect and modify any number of Git repositories. You can review and commit the changes you have made to the tracked files, for example, and you can browse the history of past changes. There is also support for cherry picking, reverting, merging and rebasing, and other common Git operations.

Magit is not a complete interface to Git; it just aims to make the most common Git operations convenient.  Thus, Magit will likely not save you from learning Git itself.

This manual provides a tour of all Magit features.  It does not give a introduction to version control in general, or to Git in particular.

The main entry point to Magit is M-x magit-status, which will put you in Magit's status buffer.  You will be using it frequently, so it is probably a good idea to bind magit-status to a key of your choice.

In addition to the status buffer, Magit will also create buffers that show lists of commits, buffers with diffs, and other kinds of buffers. All these buffers are in magit-mode and have the same key bindings.  Not all commands make sense in all contexts, but a given key will always do the same thing in all Magit buffers.

Acknowledgments
***************

From day one of the first Magit announcement, John Wiegley, Linh Dang, and Christian Neukirchen have contributed fixes, UI improvements, and new features.  Thanks!

Phil Hagelberg joined a few days later.  Thanks!

Status
******

Running M-x magit-status displays the main interface of Magit, the status buffer.  You can have multiple status buffers active at the same time, each associated with its own Git repository.

You need to explicitly refresh the status buffer when you have made changes to the repository from outside of Emacs.  You can type g in the status buffer itself, or just use M-x magit-status instead of C-x b when switching to it.  You also need to refresh the status buffer in this way after saving a file in Emacs.

The header at the top of the status buffer shows a short summary of the repository state: where it is located, which branch is checked out, etc.  Below the header are a number of sections that show details about the working tree and the staging area.  Only sections that are not empty are shown.

You control how much of a section is visible by moving point to its title and hitting TAB or S-TAB.  Hitting TAB will toggle between hiding and showing the section.  A hidden section only shows its first line.  You can also control the visibility of sub-sections in this way.  Hitting S-TAB will fully expand a section by showing it and all of its sub-sections.  If a section is already fully expanded, S-TAB will collapse it: the section itself remains shown, but all its immediate sub-sections are hidden.

The first section shows Untracked files, if there are any.  See Untracked files for more details.

Two section show your local changes.  They are explained fully in the next chapter, Staging and Committing.

If the current branch is associated with a remote tracking branch, the status buffer shows the differences between the current branch and the tracking branch.  See Pushing and Pulling for more information.

Typing a digit in the status buffer will move point to a section header: 1 will move to Untracked files, 2 will move to Unstaged changes or Changes, 3 will move to Staged changes, and 4 will move to Unpushed commits.  Note that these relations are fixed, 3 always moves to Unstaged changes, not the third visible section.

Untracked files
***************

Untracked files are shown in the Untracked changes section.

You can instruct Git to ignore them by typing i.  This will add the filename to the .gitignore file.  Typing C-u i will ask you for the name of the file to ignore.  This is useful to ignore whole directories, for example.  The I command is similar to i but will add the file to .git/info/exclude instead.

To delete a untracked file forever, use k.

Staging and Committing
**********************

Comitting with Git is conceptually a two step process: first you add the changes you want to commit to a 'staging area', and then you commit them to the repository.  This allows you to only commit a subset of your local changes.

Magit allows you to ignore the staging area if you wish.  As long as your staging area is unused, Magit will show your uncomitted changes in a section named Changes.

When the staging area is in use, Magit uses two sections: Unstaged changes and Staged changes.  The Staged changes section shows the changes that will be included in the next commit, while the Unstaged changes section shows the changes that will be left out.

To move a unstaged hunk into the staging area, move point into the hunk and type s.  Likewise, to unstage a hunk, move point into it and type u.  If point is in a diff header when you type s or u, all hunks belonging to that diff are moved at the same time.

If the region is active when you type s or u, only the changes in the region are staged or unstaged.  (This works line by line: if the beginning of a line is in the region it is included in the changes, otherwise it is not.)

To move all hunks of all diffs into the staging area in one go, type S.  To unstage everything, type U.

You can discard uncommitted changes by moving point into a hunk and typing k.  The changes to discard are selected as with s and u.

Before committing, you should write a short description of the changes.

Type c to pop up a buffer where you can write your change description.  Once you are happy with the description, type C-c C-c in that buffer to perform the commit.  When your stagin area is unused at this point, all your uncommitted changes are committed. When the staging area is in use, only the staged changes are committed.

You can type C-c C-a in the buffer with the change description toggles a flag that determines whether the next commit will be a amending one.

Typing C will also pop up the change description buffer, but in addition, it will try to insert a ChangeLog-style entry for the change that point is in.

History
*******

To show the repository history of your current head, type l.  A new buffer will be shown that displays the history in a terse form. The first paragraph of each commit message is displayed, next to a representation of the relationships between commits.

Typing L will ask for the starting and end point of the history. This can be used to show the commits that are in one branch, but not in another, for example.

You can move point to a commit and then cause various things to happen with it.  (The following commands work in any list of commit, such as the one shown in the Unpushed commits section.)

Typing RET will pop up more information about the current commit and move point into the new buffer.  Typing SPC and DEL will also show the information, but will scroll the new buffer up or down when typed again.

Typing a will apply the current commit to your current branch. This is useful when you are browsing the history of some other branch and you want to `cherry-pick' some changes from it.  A typical situation is applying selected bug fixes from the development version of a program to a release branch.  The cherry-picked changes will not be committed automatically; you need to do that explicitly.

Typing A will cherry-pick the current commit and will also commit the changes automatically when there have not been any conflicts.

Typing v will revert the current commit.  Thus, it will apply the changes made by that commit in reverse.  This is obviously useful to cleanly undo changes that turned out to be wrong.  As with a, you need to commit the changes explicitly.

Typing = will show the differences from the current commit to the marked commit.

You can mark the current commit by typing ..  Some commands, such as =, will use the current commit and the marked commit as implicit arguments.  Other commands will offer the marked commit as a default when prompting for their arguments.

Reflogs
*******

You can use h and H to browse your reflog, the local history of changes made to your repository heads.  Typing H will ask for a head, while h will show the reflog of HEAD.

The resulting buffer is just like the buffer produced by l and L that shows the commit history.

Diffing
*******

To show the changes from you working tree to another revision, type d.  To show the changes between two arbitrary revisions, type D.

You can use a within the diff output to apply the changes to your working tree.  As usual when point is in a diff header for a file, all changes for that file are applied, and when it is in a hunk, only that hunk is.  When the region is active, the applied changes are restricted to that region.

Typing v will apply the selected changes in reverse.

Resetting
*********

Once you have added a commit to your local repository, you can not change that commit anymore in any way.  But you can reset your current head to an earlier commit and start over.

If you have published your history already, rewriting it in this way can be confusing and should be avoided.  However, rewriting your local history is fine and it is often cleaner to fix mistakes this way than by reverting commits (with v, for example).

Typing x will ask for a revision and reset your current head to it.  No changes will be made to your working tree and staging area. Thus, the Staged changes section in the status buffer will show the changes that you have removed from your commit history.  You can commit the changes again as if you had just made them, thus rewriting history.

Typing x while point is in a line that describes a commit will offer this commit as the default revision to reset to.  Thus, you can move point to one of the commits in the Unpushed commits section and hit x RET to reset your current head to it.

Type X to reset your working tree and staging area to the most recently committed state.  This will discard your local modifications, so be careful.

Branching
*********

The current branch is indicated in the header of the status buffer. You can switch to a different branch by typing b.  This will immediately checkout the branch into your working copy, so you shouldn't have any local modifications when switching branches.

Similar to x, typing b while point is at a commit description will offer that commit as the default to switch to. This will result in a detached head.

To create a new branch and switch to it immediately, type B.

Merging
*******

Magit offers two ways to merge branches: manually and automatic.  A manual merge will apply all changes to your working tree and staging area, but will not commit them, while a automatic merge will go ahead and commit them immediately.

Type m to initiate a manual merge, and type M for a automatic merge.

A manual merge is useful when carefully merging a new feature that you want to review and test before even committing it.  A automatic merge is appropriate when you are on a feature branch and want to catch up with the master, say.

After initiating a manual merge, the header of the status buffer will remind you that the next commit will be a merge commit (with more than one parent).  If you want to abort a manual merge, just do a hard reset to HEAD with X.

Merges can fail if the two branches you merge want to introduce conflicting changes.  In that case, the automatic merge stops before the commit, essentially falling back to a manual merge.  You need to resolve the conflicts and stage the resolved files, for example with S.

You can not stage individual hunks one by one as you resolve them, you can only stage whole files once all conflicts in them have been resolved.

Rebasing
********

Typing R in the status buffer will initiate a rebase or, if one is already in progress, ask you how to continue.

When a rebase is stopped in the middle because of a conflict, the header of the status buffer will indicate how far along you are in the series of commits that are being replayed.

Of course, you can initiate a rebase in any number of ways, by configuring git pull to rebase instead of merge, for example. Such a rebase can be finished with R as well.

Rewriting
*********

As hinted at earlier, you can rewrite your commit history.  For example, you can reset he current head to an earlier commit with x.  This leaves the working tree unchanged, and the status buffer will show all the changes that have been made since that new value of the current head.  You can commit these changes again, possibly splitting them into multiple commits as you go along.

Amending your last commit is a common special case of rewriting history like this.

Another common way to rewrite history is to reset the head to an earlier commit, and then to cherry pick the previous commits in a different order.  You could pick them from the reflog, for example.

Magit has several commands that can simplify the book keeping associated with rewriting.  These commands all start with the r prefix key.

Typing r s will start a rewrite operation.  You will be prompted for a base commit, and all commits between the current head and this commit are put in a list of Pending commits (including the base commit).  The current head will then be reset to the parent of the base commit.

You would then typically use a and A to cherry pick commits from the list of pending commits in the desired order, until all have been applied.  Magit shows which commits have been applied by changing their marker from * to ..

Using A will immediately commit the commit (as usual).  If you want to combine multiple previous commits into a single new one, use a to apply them all to your working tree, and then commit them together.

Magit has no explicit support for rewriting merge commits.  It will happily include merge commits in the list of pending commits, but there is no way of replaying them automatically.  You have to redo the merge explicitly.

You can also use v to revert a commit when you have changed your mind.  This will change the . mark back to *.

Once you are done with the rewrite, type r t to remove the book keeping information from the status buffer.

If you rather wish to start over, type r a.  This will abort the rewriting, resetting the current head back to the value it had before the rewrite was started with r s.

Typing r f will finish the rewrite: it will apply all unused commits one after the other, as if you would us A with all of them.

You can change the * and . marks of a pending commit explicitly with r * and r ..

In addition to a list of pending commits, the status buffer will show the Pending changes.  This section shows the diff between the original head and the current head.  You can use it to review the changes that you still need to rewrite, and you can apply hunks from it, like from any other diff.

Pushing and Pulling
*******************

Magit will run git push when you type P.  You can type $ to pop up a buffer with the transcript of running these commands.

Typing f will run git remote update and F will run git pull.

That's almost all the support for remote repositories that Magit offers.  You should have setup your Git configuration to do the right thing for git push and git pull.

If you have configured a default remote repository for the current branch (by setting the Git config option branch.<branch>.remote), Magit will show that repository in the status buffer header.

In this case, the status buffer will also have a Unpushed commits section that shows the commits on your current head that are not in the branch named <remote>/<branch>.  This section works just like the history buffer: you can see details about a commit with RET, compare two of them with . and =, and you can reset your current head to one of them with x, for example.

When the remote branch has changes that are not in the current branch, Magit shows them in a section called Unpulled changes.  Typing F will merge them into the current branch.