There’s neogit for Neovim. I haven’t used it but I’m going to add it to the collection for sure. Dunno if that’s faithful enough to expand your criterion here by one. 
This is also my answer to the topic question, although I fall back on VSCode sometimes for debugging.
I never was a power user of magit, but I was using it and liked it when I still used spacemacs, now I use LazyVim and it has Lazygit integration and for what I use, it makes practically no difference. (For others that might be different, but I haven’t compared them in depth)
One part that I prefer about Lazygit is that I also can use it standalone from the terminal.
So far LazyVim was the best “batteries included” variant of both emacs and neovim “distributions” that I have tried, very good defaults, lots of easy customization options and still very good performance without having to do everything from scratch.
However people who are willing to go the minimalist route and invest some time may still be happier with something like GitHub - nvim-lua/kickstart.nvim: A launch point for your personal nvim configuration.
When I decided to get serious about Neovim I went with Kickstart, which does use Lazy as its package manager. LazyVim looks like a good out-of-the-box way to go, especially if editing a bunch of Lua isn’t one’s style (it’s very much mine fwiw).
I admit I do almost everything git using… git, with a little bit of tig thrown in. I like LazyGit’s pitch on doing better interactive checkins, I’ll want to take a closer look at that. Any time things go a bit sideways with git I end up trawling through manpages looking for that one flag I vaguely remember…
Re: “sideways”. You are not alone, friend …
Or you can simply dodge the whole git problem and use jujutsu (“jj”) for source control instead.
As a Mercurial expat, jujutsu has been so much more pleasant than anything git that it’s absurd.
So, I’m very tempted to give this a try. But it’s possibly going to take a while to get around to it. Would you mind opening an enhancement issue so it doesn’t get lost? You can just copy your post here verbatim to github.
Personally I’m using vim-fugitive. Seems solid to me. Looking at the intro for magit, I can’t really see what benefits would it offer me over vim-fugitive.
kakoune, zls
I’m a fan of fossil when I can get away with it. It’s very different, in that the repo is a one-file SQLite database, and the VCS is a single batteries-included application. That doesn’t scale well, mostly the second part, but you get a lot out of the box.
Having never been spoiled by Mercurial to begin with, jj scans to me as not different enough to justify the dearth of tooling support: it isn’t literally a reskin of git, so there’s a whole fountain of edge cases and source-of-truth problems which come with colocating it with a git repo, and my public remote is definitely going to be git, it’s what the interactive tools I have understand and work with, and so on.
The future I want is for pijul to become a credible git competitor, because I think treating the unit of change as the fundamental abstraction is fundamentally correct.
All of these face the huge uphill battle of git’s dominance, especially the ecosystem which has sprung up around it. I think that’s important though, there are many ways in which the git model and UI could be considerably improved, which would benefit basically everyone writing software.
emacs, eglot, zls, zig-mode and magit! absolutely seamless.
I’m quite surprised that CLion hasn’t been mentioned yet. Using CLion with FalsePattern’s ZigBrains plugin is rather pleasant and a smooth sailing experience. If you are looking for a traditional IDE VisualStudio-style programming (and debugging!) experience with Zig, this is currently (I think 
) the best way.
Agree specially because native support of C
Two problems:
For non-commercial projects use RustRover with ZigBrains plugin