# Neogit: a Magit-style Git interface inside Neovim

> Neogit puts staging, committing and history browsing into a Neovim buffer instead of a terminal pane. It is a good fit for people who already live in Neovim, and a poor fit for anyone who wants a Git client that works without one.

**NeogitOrg/neogit** — An interactive and powerful Git interface for Neovim, inspired by Magit

- Repository: https://github.com/NeogitOrg/neogit
- Stars: 5,640 · Forks: 358
- Language: Lua
- License: MIT
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/neogitorg-neogit

## The problem Neogit solves for Neovim users

Git's command line is fine until you need to stage part of a file, review what changed across several files, and then rewrite a commit message. Doing that with git add -p and git commit --amend means switching between the editor and a shell, and losing the buffer context you had. Neogit's answer is to render the repository state as a normal Neovim buffer, so the same keybindings, search and window management you already use apply to Git operations.

The README describes it plainly as "A git interface for Neovim, inspired by Magit". That is the audience: people who already run Neovim and want Magit's interaction model, not a general-purpose Git GUI. If you do not use Neovim, there is nothing here for you, because the whole interface is a Neovim buffer and the Lua API is the only programmatic entry point.

## How the status buffer and popups are put together

The visible mechanism is a status buffer plus popups. Opening Neogit gives you a buffer listing sections such as unstaged changes, staged changes and recent commits; acting on a line triggers the corresponding git operation. The README exposes a kind option that decides how that buffer appears: tab (the default), replace, split, split_above, split_above_all, split_below, split_below_all, vsplit, floating and auto, where auto picks vsplit if the window would have 80 columns and split otherwise.

Popups are the second half. :Neogit commit opens the commit popup directly, and the Lua API accepts a popup name as the first argument, so neogit.open({ "commit" }) does the same thing from a keymap. Configuration is a single setup table. Two entries are worth noting because they change behaviour rather than appearance: filewatcher watches the .git directory and refreshes the status buffer on filesystem events, with an interval default of 1000, and git_executable defaults to "git" but can point at a wrapper script. The git_services table builds URLs for the branch popup actions "pull request", "open commit" and "open tree", with templates for github.com, bitbucket.org, gitlab.com, azure.com and codeberg.org. That is a hardcoded list, so a self-hosted forge gets no link unless you add an entry yourself.

## Installing Neogit and opening it for the first time

The README gives a spec for Lazy, and notes you are free to use whichever plugin manager suits you. The dependencies are all optional, and the README marks the alternatives: diffview.nvim or codediff.nvim for diffs, baleia.nvim for a custom log pager, and one of telescope.nvim, fzf-lua, mini.pick or snacks.nvim for pickers. The cmd and keys entries mean the plugin loads when you first call :Neogit rather than at startup.

```lua
{
  "NeogitOrg/neogit",
  lazy = true,
  dependencies = {
    "sindrets/diffview.nvim",
    "nvim-telescope/telescope.nvim",
  },
  cmd = "Neogit",
  keys = {
    { "<leader>gg", "<cmd>Neogit<cr>", desc = "Show Neogit UI" }
  }
}
```

After the plugin manager installs it, the command form is the shortest path. The README shows cwd and kind as the two arguments, plus a bare form that opens the status buffer in a new tab. Running :Neogit with no arguments in a repository should give you the status buffer; if you are outside a repository, the cwd argument is how you point it at one, for example :Neogit cwd=%:p:h to use the repository of the current file.

```vim
:Neogit             " Open the status buffer in a new tab
:Neogit cwd=<cwd>   " Use a different repository path
:Neogit kind=<kind> " Open specified popup directly
:Neogit commit      " Open commit popup
```

For a keymap, the README shows both the command form and the Lua function form. The Lua form is the one to use if you want to pass options such as kind without writing a wrapper command string.

```lua
local neogit = require('neogit')

neogit.open()
neogit.open({ "commit" })
neogit.open({ kind = "split" })
neogit.open({ cwd = "~" })
```

## Configuration choices that change how Git behaves

Most of the setup table is cosmetic, but three keys change what Git does rather than how it looks. prompt_force_push defaults to true and asks before force pushing when branches diverge; prompt_amend_commit defaults to true and asks for confirmation when amending an already published commit. Setting either to false removes a confirmation step, which is a real trade-off: fewer interruptions, more chance of rewriting history you did not mean to touch.

disable_insert_on_commit defaults to "auto", which the README explains as entering insert mode if the commit message is empty and staying in normal mode otherwise. That is a small detail with a large effect on muscle memory, and it is the kind of default worth reading before you adopt the plugin rather than after.

```lua
require("neogit").setup {
  prompt_force_push = true,
  prompt_amend_commit = true,
  disable_insert_on_commit = "auto",
  git_executable = "git",
  filewatcher = {
    interval = 1000,
    enabled = true,
  },
}
```

## Where Neogit is the wrong tool

The dependency on Neovim 0.10 or newer is the first hard boundary. The README badge states Neovim 0.10+, and the release list shows v1.0.0 labelled "Neovim 0.10" and v0.0.1 labelled "Neovim 0.9 Compatible", so anyone pinned to an older Neovim is looking at an older line of the project rather than the current one.

The second boundary is the graph. graph_style defaults to "ascii", which the README describes as the graph the git CLI generates; "unicode" gives the vim-flog style, and "kitty" requires the Kitty terminal plus flog-symbols if you do not use Kitty. So the nicer graph is not free, and the default is the plainest one.

The third is the absence of any non-Neovim surface. There is no standalone binary, no terminal UI, no web view. If your team includes people who do not use Neovim, Neogit cannot be the shared Git interface, and the git_services URL templates do not change that: they generate links for branch popup actions, they do not give anyone else a UI. The README also does not document rollback or undo behaviour for Git operations performed through the interface, so if you need a guaranteed recovery path for a mistaken amend or force push, that is something to establish before relying on it.

## Neogit compared with Lazygit and vim-fugitive

Lazygit is a separate terminal application. It runs outside the editor, so it works with any editor or none, and it does not depend on a Neovim version. Neogit inverts that: it only exists inside Neovim, which is why it can reuse Neovim buffers, keymaps and pickers, and why it cannot help someone who does not run Neovim. The practical difference is where your hands are. With Lazygit you leave the editor; with Neogit the repository view is another buffer in the same session.

vim-fugitive takes a third approach. It is a Vim plugin that exposes Git through Ex commands and buffers rather than through a status buffer with sections and popups. Neogit is closer to Magit's model, where the status buffer is the hub and actions open transient popups. If you already have a fugitive workflow built around :Git commands, Neogit is an additional interface rather than a drop-in replacement, and the two can coexist.

The dependency lists point at the same split. Neogit's optional diff dependency is diffview.nvim or codediff.nvim, and its optional pickers are telescope.nvim, fzf-lua, mini.pick or snacks.nvim, so the plugin is designed to plug into a Neovim configuration that already has those pieces rather than to bundle its own.

## Maintenance, licence and what a Neovim upgrade costs

The repository is not archived, and the last push was on 2026-08-22. The most recent release in the list is v2.0.0 from 2024-11-07, so releases are much less frequent than commits. Anyone tracking the project should decide whether they follow tagged releases or the default branch, because those are not the same thing here.

The licence is MIT, which is permissive and imposes no copyleft obligation on your configuration. That is a statement about the licence identifier, not legal advice; if you redistribute Neogit inside a product, read the LICENSE file in the repository.

Upgrade cost is mostly tied to Neovim itself. The 0.10 requirement is the gate, and the release history shows the project renamed a release around it (v1.0.0 is labelled "Neovim 0.10"). A Neovim upgrade is therefore also a Neogit upgrade decision. The repository has a Makefile with test, specs, lint, format and typecheck targets, and the test target sets GIT_CONFIG_GLOBAL and GIT_CONFIG_SYSTEM to /dev/null, which is a deliberate choice to keep the test suite independent of your local Git configuration. That tells you the maintainers treat Git configuration as an input worth isolating, but it says nothing about whether a given upgrade will break your keymaps.

## Conclusion

Adopt Neogit if you already work in Neovim and want staging, committing and log browsing in a buffer rather than a terminal pane. Do not adopt it if you want a standalone Git client, since it has no interface outside Neovim. Before committing to it, verify that your Neovim is 0.10 or newer, that the plugin manager can install the optional dependencies you want, and that :Neogit opens the status buffer in your repository.

## FAQ

### What are the key differences between Lazygit and Neogit?

Lazygit is a separate terminal application that runs outside the editor, while Neogit is a Neovim plugin that renders the repository as a Neovim buffer and requires Neovim 0.10 or newer. The practical difference is where you work: Lazygit takes you out of the editor, Neogit keeps the Git view inside the same session.

### How do I use Neogit in Neovim?

The README shows the :Neogit command opening the status buffer in a new tab, with cwd and kind as optional arguments, and :Neogit commit opening the commit popup directly. The same operations are available through the Lua API with neogit.open(), which accepts a popup name or a table with kind and cwd.

### How does Neogit compare with vim-fugitive?

vim-fugitive exposes Git through Ex commands and buffers, while Neogit follows the Magit model of a status buffer with sections and transient popups for individual actions. They are different interaction models rather than one replacing the other, and nothing in the documentation prevents running both.

### How does Neogit compare with gitsigns?

The README does not mention gitsigns, so there is no documented comparison to report. What the README does state is that Neogit's optional diff dependency is diffview.nvim or codediff.nvim, which is the integration it describes.

### Is there a Neogit alternative?

Lazygit is the alternative the README's own framing points to, since it is a separate terminal application rather than a Neovim plugin. vim-fugitive is the other option for Vim users who prefer Ex commands and buffers over a status buffer with popups.

## Sources

- [Issues](https://github.com/NeogitOrg/neogit/issues)
- [License: MIT](https://github.com/NeogitOrg/neogit/blob/master/LICENSE)
- [NeogitOrg/neogit on GitHub](https://github.com/NeogitOrg/neogit)
- [README](https://github.com/NeogitOrg/neogit/blob/master/README.md)
- [Releases](https://github.com/NeogitOrg/neogit/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/neogitorg-neogit