Magit: a Git porcelain that lives inside Emacs

The problem Magit solves for Emacs users

Git's command line is a set of verbs with flags, and its output is text meant for reading, not for acting on. Magit's premise is that a Git client should be a porcelain: an interface that presents repository state as something you manipulate directly. The README states that Magit "aspires to be a complete Git porcelain" and that while it cannot yet claim to wrap every Git command, it is complete enough for experienced Git users to perform almost all of their daily version control tasks from inside Emacs.

The audience is therefore narrow and specific. You need to be an Emacs user first. Magit is implemented as an Emacs package in Emacs Lisp, so it inherits Emacs's buffer model, its keybinding conventions and its configuration system. Someone who does not run Emacs gets nothing from it. Someone who does gets a Git interface that shares the same editor, the same window management and the same extension language as the rest of their work.

The README makes a strong claim about the category: "While many fine Git clients exist, only Magit and Git itself deserve to be called porcelains." Treat that as the maintainers' position rather than a measured comparison. It does tell you what the project is optimising for: not a friendlier subset of Git, but a full replacement surface for it, with Git underneath doing the actual object manipulation.

How the status buffer drives every action

The mechanism visible in the README is that Magit renders repository state into buffers and binds keys to the things shown there. The getting-started article describes it plainly: "Almost everything that you see in Magit can be acted on by pressing some key, but that's not obvious from just seeing how Magit looks." That sentence is the whole design in miniature. The status buffer is not a report; it is a menu whose entries happen to be your files, hunks, branches and commits.

This is why Magit differs from a Git GUI that presents forms and dialogs. In a dialog-driven client, you decide what to do first and then supply the arguments. In Magit you look at the current state first, and the available actions are attached to the lines in front of you. Staging a hunk, amending the previous commit, or starting an interactive rebase are all operations on a visible object rather than entries in a menu tree.

The README points to two written introductions for this reason: a visual walk-through with screenshots and accompanying text, and a more abstract article on why the interface behaves as it does. If the screenshots alone do not convey the model, that is expected; the project itself says the advantages "are not immediately obvious simply from looking at a few screenshots".

Underneath, Magit is still Git. It is an interface to the version control system Git, not a reimplementation of it. Anything Magit does not cover remains reachable by running Git commands in a shell buffer or by invoking Git directly, which is the escape hatch the "cannot yet claim to wrap every command" wording quietly leaves open.

Installing Magit from ELPA or MELPA and running the status buffer

Magit is distributed through Emacs package archives. The README's badges link to NonGNU ELPA, MELPA Releases and MELPA Snapshots, and the packaging badge on Repology is filtered to versions 4.7 and above. The repository also ships a Makefile, so building from a checkout is possible, but for most users the package archive is the path the project advertises.

If your Emacs is already configured with NonGNU ELPA or MELPA, installation goes through the package interface. The package name is magit. The README does not print the exact invocation, so check your Emacs version's package commands; the archive name to look for is magit.

After installation, open a file inside a Git repository and start the status buffer. The README does not spell out the entry command in the text shown here, but Magit's status buffer is the interface the getting-started articles are built around, and the manual linked from the README covers the full key reference.

What you should see is a buffer listing the repository's state: untracked and modified files, staged changes, recent commits and the current branch. From that buffer, pressing the key bound to an action performs it on the item at point. The README's own advice is to read the visual walk-through before expecting the screen to explain itself.

If you prefer to build from source, the repository's Makefile documents the targets. The help target prints the available variables and the build, install, clean and test targets.

make help

The Makefile's help output lists separate targets for compiling lisp, generating docs in texi, info, html, pdf and epub formats, and installing either or both. That split matters if you package Magit for a distribution rather than installing it into your own Emacs. The install targets named there are install, install-lisp, install-docs and install-info.

make install

Where Magit is the wrong tool

The first limitation is structural: Magit only exists inside Emacs. There is no standalone binary, no terminal client and no editor plugin for other editors. If your workflow involves reviewing a colleague's branch in a browser, or if you pair with people who do not use Emacs, Magit is not a shared surface. It is a personal interface to a shared repository.

The second limitation is stated by the project itself. The README says Magit "cannot (yet) claim that Magit wraps and improves upon each and every Git command". So there will be Git operations you perform outside it. That is not a defect in the same way a missing feature is; it is an explicit scope boundary, and it means you still need to know Git rather than only Magit.

Third, the project has a maintainer-capacity constraint that it states openly: "Magit has many users and very few maintainers." The README asks users to read guidelines before making contact, routes feature requests to GitHub Discussions rather than issues, and asks people to consider asking other users for help first. If your organisation needs a vendor with a support contract or a fast guaranteed response to a bug report, that is not what this is.

Finally, the interface has a learning cost that the project does not hide. The README recommends reading an article before using it precisely because the keybindings are not discoverable from the screen. Users who want a client that explains itself on first launch will find the first hour frustrating.

Magit compared with lazygit and other Git clients

The most common comparison for Magit is lazygit, a terminal user interface for Git. The difference in approach is where the interface lives and what it is allowed to assume. lazygit is a separate program that runs in a terminal and manages its own screen; it works for anyone with a shell, regardless of editor. Magit assumes Emacs and gives up standalone use in exchange for integration with the editor's buffers, windows and Lisp configuration.

That trade-off cuts both ways. With lazygit you can hand a colleague a command and they can run it. With Magit, the interface is part of your Emacs configuration, so a keybinding you rely on may not exist in someone else's setup. In return, Magit can present repository state in the same environment where you edit the files, and it can be extended in the same language as everything else you use.

Compared with Git's own command line, the README's position is that both are porcelains rather than one being a wrapper over the other. In practice the difference is that the command line makes you name the operation first, while Magit makes you look at the state first. Which of those is faster depends on whether you already know what you want to do before you look.

Compared with a graphical client like a standalone desktop app, the difference is again the host environment. A GUI client is discoverable and self-contained. Magit is neither, and it does not try to be. The project's own framing is that its advantages are not obvious from screenshots, which is an admission that it will lose a first-impression comparison.

Maintenance, releases and the GPL-3.0 licence

The repository is not archived, and the last push was on 2026-09-21. Releases are frequent: v4.6.0 on 2026-07-01, v4.7.0 on 2026-07-31 and v4.7.1 on 2026-09-01. That cadence, combined with the recent push, means upgrade cost is a real consideration rather than a theoretical one. If you install from MELPA Releases you get tagged versions; if you install from MELPA Snapshots you get builds from the development branch, and the README links to both.

For a package installed through an Emacs archive, upgrading goes through the same package interface you used to install. For a source checkout, the Makefile separates compiling, generating documentation and installing, so you can rebuild the lisp without regenerating manuals. The relevant targets are lisp, redo, docs and install-lisp.

make lisp

Magit is licensed GPL-3.0. That is a copyleft licence, and it matters most if you plan to redistribute Magit itself or a modified version of it. Using Magit as an end user to operate your own repositories does not raise the same question. If you embed Magit in a product you ship, or fork it, read the licence text in the repository's LICENSE file rather than relying on a summary. This is a description of the licence identifier, not legal advice.

The project is funded by donations, with links to GitHub Sponsors, Liberapay, OpenCollective and PayPal in the README. That is worth knowing before you file a demanding bug report against a project that describes itself as having very few maintainers.

Editorial conclusion

Adopt Magit if you already live in Emacs and want almost all daily version control work to happen in one buffer tree rather than a terminal. Do not adopt it if your team standardises on a standalone GUI client or if you cannot commit to Emacs keybindings, because Magit is not usable outside Emacs. Before installing, verify which package archive your Emacs is configured for, since the README and badges point at NonGNU ELPA and MELPA, and check that the version your archive offers is at least 4.7 if you want the current release line.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. magit/magit on GitHub
3. Project website
4. README
5. Releases