I use git in the terminal. On Windows I used git for Windows. I even used that MSYS CLI it provided as my daily driver terminal.
this post was submitted on 24 Feb 2026
32 points (97.1% liked)
Git
4568 readers
59 users here now
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
Resources
Rules
- Follow programming.dev rules
- Be excellent to each other, no hostility towards users for any reason
- No spam of tools/companies/advertisements. It’s OK to post your own stuff part of the time, but the primary use of the community should not be self-promotion.
Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License.
founded 2 years ago
MODERATORS
i use git. got a tree alias a tree-like log. and an amend alias to add changes to the prev comit to keep the message
I found this one recently which is really good:
https://github.com/sourcegit-scm/sourcegit
Much better than most of the standalone Git GUIs, even the commercial ones.
However I don't actually use it, because I use VSCode and there's a great extensions called Git Graph that integrates nicely into it. It is abandoned unfortunately but it still works fine so I still use it.
Here's my rating of all the Git GUIs I've tried (that I remember):
- SourceTree: works ok but just so incredibly slow.
- GitKraken, SmartGit, Tower, Sublime Merge: Commercial and I don't like the UX of any of these.
- Git Extensions: This one is actually really good. Terrible name though. Also kind of Windows-only.
- GitX: This is also really good but unfortunately it's one of those pieces of software that has forked into dozens of half maintained versions that you'll need to spend hours in phpBB forums figuring out which one to use (like TomatoUSB). Also Mac only.
I never tried Magit because TUIs are dumb.
Also don't listen to anyone that says "just use the CLI". It's okay once you've learnt how git works, but even then you're still going to want a way to view the commit graph. Learning Git without a GUI is needlessly masochistic. Once you have learnt it you can start mixing it up with the CLI.
git log --all --graph
I’ve been using TortoiseGit since the beginning, but it's Windows-only.
In TortoiseGit, the Log view is my single entry point to all regular and semi-regular operations.
Occasionally, I use native git CLI to manage refs (archive old tags into a different ref path, mass-remote-delete, etc).
Originally, it was a switch from TortoiseSVN to TortoiseGit, and from then on, no other GUI or TUI met my needs and wants. I explored/tried out many alternative GUIs and TUIs over the years, but none felt as intuitive, gave as much overview, or capabilities. Whenever I'm in Visual Studio and use git blame, I'm reminded that it is lacking - in the blame view you can't blame the previous versions to navigate backwards through history within a code view. I can do that in TortoiseGit.
I've also tried out Gitbutler and jj, which are interesting in that they're different. Ultimately, they couldn't convince me for regular use when git works well enough and additional tooling can introduce new complexities and issues when you don't make a full switch. I remember Gitbutler added refs making git use impractical. jj had a barrier to entry, to understand and follow the concepts and process, which I think I simply did not pass yet to have a more accurate assessment.
I did explore TUIs also as no-install-required fallback alternatives, but in practice, I never needed them. When I do use the console, I'm familiar with native git to cover my needs. Remote shell: native git, locally: Nushell on top of native git for mass queries and operations.
The git CLI. GUIs don't get anywhere near what it can do, and the CLI is scriptable and can easily interop with other programs.
Performing a diff would like a word.
Not sure what you're saying. Are you saying you need GUIs for diffs? Because that couldn't be further from the truth. Unified diff itself is highly underrated (and my preferred form for many reasons), but even if you wanted side-by-side diffs, there are many ways of accomplishing that without a GUI. That's the entire point of git difftool.
What I'm saying is that performing a diff via command line isn't something that brings as much utility as using a GUI. You can do it, but a major part of this utility is the visual aspect, layout, navigation. CLI tools don't come close to what I want. Isn't difftool meant to be used in GUI form? Am I missing something here?
Regular git CLI, with like 15 years of aliases
Most commonly used alias for me is gti="git"…
I prefer pen and paper.
When that's unavailable, command line is fine.
pen and paper is decentralized storage too, but the push and fetch sync protocols are a lot of work
Raw git. I get lost everytime I try to use any git front end, tui or gui.
SCM breeze. Lots of qol features I can't love without
git gud :P
I use the CLI mostly.
It gives me confidence that I am not doing something unknowingly.
In some cases, I prefer GUI tools:
- For
blame, I prefer what Qt Creator provides- Although it could have been better
- For
graph, the default CLI one is not pretty enough and honestly doesn't help as a graph. So I go with GUI stuff- there are quite a few alternatives available that make it much faster to grasp on sight
I just use the git CLI, and sometimes the git graph extension on VSCodium.
i use the standard git cli mostly, and sometimes the magit package for emacs (but only when i am also working in emacs already)
https://github.com/sourcegit-scm/sourcegit or command line.
Its kinda like gitkraken.
One more vote for SourceGit. It is very feature-rich and intuitive.
Sublime Merge is what I use, mostly for dealing with merge conflicts. For more complex operations I just do it in the terminal, even though I'm sure it supports way more features than I use it for.
It's not FOSS, but it's also not Electron.
Fork.dev on Windows and Mac
- GUI using native APIs, no electron
- It's free the same way that sublime text and winzip are. It asks about once a month if you want to pay and you can keep clicking "I'm still trying it out".
- Normal git cli is powerful but with a terrible UI with terrible defaults.
- To use the best commands you need to add a ton of flags to get what you want, or add a whole bunch of aliases and port them between machines.
- e.g.
git logvsgit log --graph --all --remotes --decorate - e.g.
git fetchvsgit fetch --prune --all - e.g.
git stage -pvs nothing (git cli still doesn't have a good way to specify lines correctly, only hunks that can't be split properly)
- e.g.
- To use the best commands you need to add a ton of flags to get what you want, or add a whole bunch of aliases and port them between machines.
Fork.dev is just what you get when the defaults are set up correctly by default, with more powerful control over staging, and with automatic branch/stash backups whenever your doing risky actions.
The only thing it doesn't have built in support for is git log -S for when you're searching for a specific file or commit and don't know the file or commit, but know a substring in the commit itself. But it doesn't matter since you can add that as a custom command into fork.dev
- lazygit: a TUI for git. This is my day to day UI for staging, committing, interactive rebases. I have delta configured for diffs in lazygit.
- neovim (nvimdiff): for diffing, and conflict resolution.
- vscode/neovim: I whatever functionally my editor had (or some plugins for neovim) for live changes as I work on code.
lazygit, VSCode or just git (in that order of preference).
sourcegit.
gitui and git-cli, as well as a pretty git log with an awk script to include the shortstat of the commits
I've been loving Jujutsu VCS. It's a terminal app, works on all 3 major desktop OSes, and makes it so easy to manage efforts across multiple branches.
Also, jj undo is like a gift from the gods.