What makes lazygit better than the integrated Git tools of IDEs/editors?

[OfficialCRUGG]

So, I've recently seen a lot of people use lazygit and heard very well of it, but I've been wondering, what are its advantages over just using the integrated git tools of your IDE or editor (Visual Studio Code in my case)? Using Git, I need to make commits, choose what should be in them, push, pull, create and switch branches, and I can do all that right in my editor. What else is there that makes you use lazygit instead?

(To clarify: I'm genuinely just interested in everyone's reasoning to use lazygit, no negativity towards the project whatsoever)

[proudparrot2]

I use it alongside Zed, since it doesn't have a built-in version control UI

[baptisteArno]

Did you manage to make the edit redirect to zed? I tried setting EDITOR var to zed but it still opens up vim.

[mark2185]

@baptisteArno it should work, this PR adds zed as one of the possible editors.

[mark2185]

In my case it's vim so the choice is either vim-fugitive or lazygit and I opted out for a mix of both (fugitive is mostly for blaming and sending links to snippets of code).

lazygit shows the state of several things at once, without me having to specifically ask for it, e.g. the currently staged files/hunks, how far behind are my branches etc.

Out of the most "magical" features to me is the custom patch feature.

And generally lazygit is fun to use, cherry-picking commits to other branches, rewording them, reordering. Opening up a pull request from the branches panel, sending someone a link to a specific commit, filtering log by a specific file and many other things, these are just those that I mostly work with.

[KennethHoff]

I use JetBrains IDEs, which many say have one of the best integrations, but I consider it near-unusable; The various features like Interactive rebase and force push are disabled 19/20 times, so I just use the integration as a diff tool at this point.

[rakoo]

Not being tied to my editor is actually a plus for me. I like that the articulating point is the OS. The affordances of a text editor are not necessarily what is best for managing your commits, it's good that an independent tool exists

[goyalyashpal]

• update 2025.03.30:

  • now git rewrite functionality (ammend, rebase) feels like a second nature. earlier, it used to be a good mental undertaking and required elevated care.
  • it was only with this, that i was able to separate out a chunk of system config (users.packages in configuration.nix file) (spanning over several sparse and old commits), and move it to dedicated new file (usr-pkgs.nix). I faced and solved several merge conflicts, and it became repetitive to solve them in bare bones editor xed, but at least it was straightforward, and the rewrite succeeded without hiccups.

• update 2024.12.01: lazygit:

  • allows fine tuning which lines to un/stage
  • makes the git stash from "never used headache" to now "very easy & frequently used function" for me.
  • eases accessibility of reflog for recovering in case smth goes wrong.
  • exposes a clear view of branches which helped me resolve issue in tracking upstream branches with shallow clones which are no longer shallow now.

  none of these is even remotely possible with such clarity in vscodium.

• the command log doesn't work for cherry-picking from reflog, but its good enough otherwise.

• update 2024.11.24:
  i decided to use lazygit today as:

  • mouse movements in vscodium, and same same repetitive commands in git-cli were feeling tiresome. and
  • i am really liking the lazygit: the rebase, commit log, stash, reflog, files view, command log etc.., especially now that i am fairly comfortable in git's concepts.

  this is also good as i want to reduce the dependence on the vscodium or any other gui bloat.

---

I also use vscodium (FOSS binaries of vs code), and the git stuff i do there is mostly just:

• using its git-diff views of the current unstaged and staged area
• rarely selecting some paricular line of the change for staging/unstaging

The reason i installed lazygit today is that i just noticed using the btm task manager that vscodium v1.93.1 takes a 0.7 GiB of RAM alone, the full GiB with extensions..... and that is just for a single editor tab.

combine it with 0.8 GiB for browser, 1.3 GiB for the DE & system etc... 3 out of 8 GiB gone just like that.

so, the TUI options will save that RAM.

[KennethHoff]

I found a new niche use-case; You can use it in termux, which is a terminal for Android. IDEs can't be used there

[code-hunger]

Lazygit is much better than Intellij IDEA's git viewer at being FAST to use for the features it supports. For example, when I want to commit my changes on a new branch, I press n <branch-name> tab space c <commit-message> enter. n here is for a new branch, tab is to go to the list of changes, space is to (un)stage the hihglighted file, c is for commit. Apart from the text, it's Just 4 keystrokes!

In InteliJ the same operation is much more tedious to do and requires using the mouse or unintuitive shortcuts. That said, Intellij has features currently lacking in lazygit like squashing consecutive commits in the history. (incorrect - see reply). Acntually, I can't think of any git operation that is easier to do in intellij than in lazygit (except for viewing diffs, if it counts).

Lazygit does one job, and does it fantastically well. It lets you focus on performing git commands with as little overhead as possible, each operation being a press of a keyboard button.

[stk-ableton]

That said, Intellij has features currently lacking in lazygit like squashing consecutive commits in the history.

That's certainly possible in lazygit as well. For example, you could range-select a bunch of commits (using shift-down) and then press f to fix them all up into the commit below. Or s to do the same but keep all the commit messages (you'd still have to reword the final commit to edit the final message, probably).

Let me know if this is not what you meant.

[code-hunger]

woww, this is awesome. I never suspected that such a visual-line-mode select could work in lazygit. I just did some squashes now, and also accidentally discovered the Ctrl+J binding in the help menu, which makes squashing even more powerful than what Intellij's git view offers.

Thanks for replying!

[goyalyashpal]

• lazygit is so powerful that it has almost nullified the appeal to Jujutsu's Working-copy-as-a-commit feature for me

[rakoo]

Definitely. Moreover since everything is in a commit you can just push it with P and be sure it's also available remotely, so you have a backup.

Once you're done you can interactively select the changes from the existing commit and then extract them into another commit. It is as easy as adding new changes to a staging area and creating a new commit. This really is magic.

Really, I like the idea behind jj but lazygit shows that it's first and foremost a tooling issue, not necessarily a design issue

[cskeeters]

Having used fugitive.vim, I think it's great for reviewing and committing changes, reviewing the logs, and is good at interactive rebases. I suspect that most Git tools built into IDEs serve similar purposes well. I didn't migrate to lazygit because it's so much better at these things. Instead, I found that if I did other more complex operations on my repository, the tool didn't have a convenient way to do this. fugitive.vim, for example, allows most commands to be run with :Git rather than :!git, but I still have to remember the commands and flags. Plus, I'd rather drop out of the editor to avoid any complications and allow the editor to be opened in a particular way -- as the mergetool.

I think lazygit is a better way to interface to git than the command line for these more complicated operations because:

• You can see what you're doing
• There is less syntax to learn
• Fewer keystrokes are required
• There is a quick-to-use help menu
• It understands workflows that require multiple git commands and customizes the interface to be efficient.

I now use it for the basic operations I was using fugititve.vim for, not because it's so much better at those operations, but because I've learned the shortcuts and can parse the UI quickly.

Of course, the specific reasons why "lazygit is better than X" is hard to answer because they are both moving targets, and you have to know quite a bit about both tools before the reasons can be given and understood in the context of your work. In general, tools are great when a lot of time has been put into them by good developers. Jesse Duffield has done a wonderful job. Also, the community of users, contributors, and donors has only pushed lazygit to be that much better. It's nice to be on the bandwagon of a tool that's already great, keeping up with changes in git, and improving.