I think a big problem with Git is that it's not opinionated enough. Every team has their own Git flow because Git makes it possible to do so and most developers love nothing more than micro optimizing every minute aspect of any work that is not the task they've been assigned this sprint (myself included), or avoiding learning anything at all (half of my coworkers) thereby leaving the decisions to people like me. I'd much prefer a tool that has one way to do things and everyone just had to "get with the program." Instead, we have this Swiss Army knife that can do anything but requires arcane knowledge of how to do things that are just slightly off the beaten path.
I'm very comfortable with Git and have saved coworkers in just a few minutes from what they thought was going to be missing days of work. But I'd much rather if they had never gotten into that situation or could easily fix it themselves. I don't like the idea of every software team needing a Git expert in easy reach just in case something goes awry.
The problem with an optionated tool that mandated a specific workflow is that people that can't follow this workflow can't use the tool
This follows the Unix principle of "provide mechanisms, not policy" (as I remember from the esr book on Unix philosophy - <imagine a link here>). Git provides mechanisms for version control and it's up to users, projects, organisations, etc to set up policy. That's because mechanisms are more universal, and policy changes with the whims of the stakeholders
(I actually agree that tools that mandate a workflow are more enjoyable. Not everyone needs to use the same version control and different DVCSes can or could be interoperable like git and jj are)
just to add to the chorus, I'm switching to jj as well. I haven't started using it in every project but it's only a matter of time I think.
That said, I do which for a more jj aware GUI. For one, it's nice to be able to quickly see diffs across a bunch of changes. I use gg for this but I'd prefer a side-by-side diff and, ATM it only has a traditional diff.
Also, watching the video of git butler, it seems like a jj UI could take a lot of inspiration. I'd love to be able to just drag changes rather than `jj rebase ...` and/or drag selections of lines.
I'd also like a nicer GUI for interactive splitting/rebasing than the TUI UI built into jj
also just to add that I've noticed that `jj` comes way easier and more intuitive to newbies I've mentored. Just yesterday I told a friend to commit his changes and he just wanted to do `git commit` (without remembering to do `git add` first). This made me realize we should just install `jujutsu` for him and he's been committing very diligently afterwards. Can recommend trying this with any people you mentor/teach.
The less I use git directly, the more convinced I am that git is an absolutely awful interface to git repositories. I have been using jj for about two years now, and I literally cannot imagine going back to using the git cli. I have not used lazygit, but if you find it interesting, I say please go for it.
The please is because I am tired of fixing issues created by people being confused by git. Just use anything else than the git cli, it's probably better.
I have tried jj several times but I feel like it slows me down significantly because I can’t grok the workflow. I like to do a bunch of changes then quickly select them in my editor and commit them, breaking them up into different commits to keep them organized. With jj’s lack of editor integration, I don’t know how to do this with the cli alone so I end up with bigger messier commits.
You might laugh, but in years of serious development, I have not come across a better git UI tool than SourceTree.
If I want to be hard-core, I'd use the original git CLI. SourceTree is unmatched in how it makes using git so much more pleasant for when you need to do something relatively simple, but which would be quite cumbersome to do with the CLI and most other tools I've tried.
Its file status and history view is unmatched IMO. I can easily stage/unstage hunks and even lines. The whole UI is generally quite polished and pleasant to use.
It's a real shame there is not a version for linux. I've tried every other git interface under the sun and keep coming back to it. In the meantime, I tried lazygit the past weekend and I think it is one of the better TUI git tools out there, definitely better than GitUI.
There are few UI's that I hate more in the world than SourceTree. That pile of junk has cost me so many hours of life trying to support the developers in fixing a thousand weird issues.
For staging/committing I haven't found anything that I've liked more than Git Extensions' Commit view.
One of the main things I like about it is that it does _not_ auto refresh. A long time ago with SourceTree I'd have issues mixing git CLI and SoureTree because two processes would be doing things at the same time (I assume SourceTree was doing things like `git status` while I was trying to `git fetch` or something).
It's pretty good but also really slow. I never found one better than GitX, but that was in the days before IDEs had Git support built in. Now they do it doesn't really make sense to use a separate program IMO.
These days I use VSCode and the Git Graph extension.
If you're down to try it, I actually think SmartGit is a similar style but ended up working better for the slightly more exotic things like submodules.
If you don't mind a TUI, I've been very much enjoying gitui - in fact, this is the second time I've recommended it recently. Adding hunks and single lines is easy, and the various commands are all visible, so it lacks the usual TUI experience of "what key do I need again?"
I was using SmartGit for many years and was very happy with it, until they made it subscription based and had to switch to SourceTree. It works but I do not find it very smooth at all. It hangs every now (using MacOSX) and in general the experience is not as smooth as it was with SmartGit. I am surprised that you are saying that you haven't come across any better tool.
On Windows I've been using TortoiseGit for over a decade now and in terms of Git power user features in a GUI I think it's unmatched.
People who defend the CLI as the only real way to use Git simply haven't used a decent GUI for it. I consider myself a very advanced Git user, but I barely know the CLI commands off the top of my head.
A GUI really makes a lot of sense for something like Git, most of the time what you want to do is "contextual' from something like a list of files to commit or a log of commits and TortoiseGit is pretty good about exposing whatever you'd need to do.
I find that with GitKraken (aside from not being free), I just don't feel in control of what I'm trying to achieve with Git.
Git Extensions seemed pretty decent and possibly a nicer GUI paradigm than TortoiseGit, but when I tried it I found TortoiseGit to offer more power to me.
One thing that does annoy me a bit about TortoiseGit is that it has this philosophy of a new Window for everything, which for most things is not a problem, but is in a couple of places. For example, to work on a repository you tend to have to use the Explorer context menu to do things. I tend to open the git log window once and leave it open, and from it I can do pretty much everything. If it had some sort of "main app" view with a tab per repository you have open that would be awesome, instead of my having to have multiple open log windows. Similarly, for commits and PRs I like to double check each file's diffs. Its UI opens each one in a new window, but if it would rather have a sub pane from the commit view I think it would work better.
I used to use SourceTree in conjunction with TortoiseGit because I liked its tabbed UI for the simple things like pulling/fetching/pushing, switching branches, but I stopped using it about 5 years ago, the Windows version of it felt neglected in that it would often crash or become very slow.
Fellow SourceTree apologist here. It remains one of the first things I install on a new machine. I'll do simple stuff directly in the CLI, but stick with SourceTree for anything moderately complicated (as you've mentioned).
I've been using SourceTree for years, mainly because I like the staging experience. I've never felt good about it though, I don't know why I've put up with the terrible performance for so long. I recently stumbled upon https://github.com/sourcegit-scm/sourcegit and it's totally replaced SourceTree for me. Very similar (or better) UI/UX but much more performant.
I think there's a learning around stability of devtools here. It takes time to get used to things, but once you do you are ultra productive. That's why IDE Git UIs are not ideal, because the graphics change so often, confusing you more than helping etc.
I got stuck to git gui / gitk for so long for this reason, I couldn't parse other UIs e.g. for diffs until I forced myself to have a less productive time to learn new UI.
I hope lazygit is stable - I think I might need to construct some stable config for visuals / colors to ensure this! (:
the only good git GUI that exists is Fork. Unfortunately, it doesn't run natively on Linux, although some people have had luck running it under Wine.
I found lazygit specifically so bad to the point that I was better off typing in git commands into the terminal manually like some sort of caveman. Somehow, lazygit has found a way to make git even more confusing and user hostile than it already is, which is a significant achievement.
Using it was a harsh reminder of what people running emacs or vim for the first time have to go through.
This idiotic ui paradigm where you have to actively learn to use what should be simple software by memorizing commands and shortcuts needs to die off. It's mind bogglingly inefficient and disrespectful of user's time.
Just think about it - I've literally never had to open Fork's manual (I am not even sure it has one) whereas in lazygit it is utterly impossible to do the most basic things without referring to the manual. Why do we collectively keep tolerating these shitty tools?
As much as I heartily disagree with most of what you wrote - and seeing all the downvotes, I'm not the only one - there is a nugget of truth in what you wrote, which answers a lot of your complaints.
"Using it was a harsh reminder of what people running emacs or vim for the first time have to go through."
The benefit of keyboard-driven programs like Vim is that you're trading an initial learning curve for a vastly more efficient experience once the learning is done+.
Mouse-driven tools like VS Code don't demand that the user learns them. Keyboard shortcuts there are optional, since practically everything is in a menu or a UI that can be moused to. This adds on seconds per interaction, adding up quickly over time.
+And the "learning" for these tools can be shortened dramatically by keeping a printed-out cheatsheet. For Vim this can be a huge lifesaver; I made one for magit as well, back before I switched full-time to JJ.
Tower is also very good. Probably just due to having used it more, I prefer it over Fork, but I can get by if I have to use a computer not licensed for Tower.
Wow, $60! It had better be really, really good for that price.
I managed to get on fine with lazygit during a quick trial this morning. It actually doesn't have a manual (`man lazygit`: `No manual entry for lazygit`) but I found the contextual help (e.g. press ?) useful.
Lazygit, WezTerm, NeoVim, Yazi (TUI file manager) are a fantastic combination! I have a tmuxniator config file for every project I work on. And open a tab in WezTerm, run „mx projectname“, it opens a split for Yazi, one for Lazygit, one for neovim, and one for my agentic coding tool. Lovely setup, super fast, all in the terminal.
A large percentage of git users are unaware of git-absorb (https://github.com/tummychow/git-absorb). This complements just about any git flow, vastly reducing the pain of realising you want to amend your staged changes into multiple commits.
This sits well alongside many TUIs and other tools, most of which do not offer any similar capability.
I gave it a try a few months ago, and wasn't impressed. About a quarter of the time it got confused about the commit it should squash into, and left the repo in a half-applied state. This inconsistency was enough for me to not trust it when it did work, so I stopped using it.
Honestly, it's too much magic for my taste. And, really, it's not much manual work to create fixup commits for the right commit anyway.
Personally I just couldn't see all the extra layers as comfortable tools. It's a very rare thing that I need to see branches, relation between them etc. Using cli has always been the most reliable and simple way for me.The only git tool I need apart from cli is a convenient conflict resolver.
Lazygit is the only way I review PRs these days because it is trivial to step through a file commit by commit when that is necessary (which maybe says something about the quality of the PRs I'm reviewing...). They also won me over by using Legend of the Galactic Heroes references in the github readme gifs.
Something not mentioned in the article which has changed the way I interact with git repos (and the reason I will never not use LazyVim until something better comes along) is just how well the system plays with tmux floating panes.
I have it so that anytime I press ctrl-g in a git repo, I open a floating tmux pane in my current working directory. This might sound "whatever", but it means I don't have to actually be inside neovim or "switch" to the LazyGit UI. It just overlays it on top of whatever I'm doing at the moment in the terminal.
Makes for the most fluid, streamlined git experience ever if you primarily live in the terminal.
"git gui" is not just a wrapper for commands; it has usefully different workflows.
For instance, you can visually select a range of lines in a file, and stage those lines.
This is much easier than doing "git add --patch" and using edit, where you are deleting unwanted lines starting with +, turning - lines into context and whatnot.
I have found it useful to fire up "git gui" during rebase workflows with conflicts. It helps with the "git add" commands you would have to do to add conflict-resolved files into the patch and whatnot.
What! I was git gui user for decade and didn't notice this feature =D But yea, git gui is amazing overall. I don't think it's maintained anymore though.
BTW lazygit offers that too and it's a bit easier to discover and use (e.g. you don't need a mouse).
After a short stint when I had to do dozens of small edits to files, this became something I use every day (and I am the sort of person who types git commands by choice, even inside VS Code…)
I've found the built in gitk is pretty good for some GUI tasks. If I want to view the sate of some file at a given commit, it's easier to navigate using that rather than going through git log, find and copy the commit, git show, paste, copy the file path. GitHub desktop didn't seem to have this feature last I checked, even though the GitHub web viewer does.
Lazygit is great, I use it all the time for straight forward git-fu.
I do recommend turning off force push (there is an option), as it's easy to fat finger and leads to a whole lot of heartache.
But if you do any advanced work that involves merging a complex codebase across multiple branches, with generated code and multiple languages; and having to manage your load of conflicts, I find Fork[1] (the free version does fine) still takes the cake for that, as the clarity and lack of keyboard bindings, is essential; to make good, conscious decisions.
In the example of how they were removing specific lines from the previous commit, git gui had a way to do that instead of copying the diff lines and manually editing them back into the code:
git gui → Amend Last Commit → (select lines from a file in the Staged Changes area) → Unstage Lines From Commit → Commit
I still think it's the perfect does-just-enough GUI when the main thing you want is to visually craft commits.
Am I the only one who simply doesn't mind Git's CLI?
Sure, it's rough around the edges, but I know those edges well. I sometimes do need to look up how to do something, but those cases are rare. Over the years I've accumulated about a dozen shell aliases and a modest `.gitconfig`, and along with a couple of helper tools[1][2], I can do 90% of what I need Git for in seconds. I truly don't need a fancy TUI, GUI, or any wrappers around Git. Git itself is fine.
I tried Magit a few times, and even though Emacs is my main editor, I couldn't get used to it. It forces the user into doing things the "Magit way", and I'd rather not.
I don't understand the push to replace Git's porcelain with something shinier. If, and when, a better VCS comes along that truly feels like the next step forward, I'll give it a try. In the meantime, Git does the job I need.
89 comments
[ 0.19 ms ] story [ 68.7 ms ] threadNow I no longer directly use git, but instead use jujutsu (jj).
Once I became very proficient in the jj cli, I picked up jjui: https://github.com/idursun/jjui
Also, as splitting commits is an extremely frequent operation, this neovim plugin is really nice: https://github.com/julienvincent/hunk.nvim
Also this neovim plugin is amazing for resolving jj conflicts: https://github.com/rafikdraoui/jj-diffconflicts
Now with jj instead of git I edit the commit graph as effortlessly as if I am moving lines of code around a file in my editor.
I'm very comfortable with Git and have saved coworkers in just a few minutes from what they thought was going to be missing days of work. But I'd much rather if they had never gotten into that situation or could easily fix it themselves. I don't like the idea of every software team needing a Git expert in easy reach just in case something goes awry.
This follows the Unix principle of "provide mechanisms, not policy" (as I remember from the esr book on Unix philosophy - <imagine a link here>). Git provides mechanisms for version control and it's up to users, projects, organisations, etc to set up policy. That's because mechanisms are more universal, and policy changes with the whims of the stakeholders
(I actually agree that tools that mandate a workflow are more enjoyable. Not everyone needs to use the same version control and different DVCSes can or could be interoperable like git and jj are)
That said, I do which for a more jj aware GUI. For one, it's nice to be able to quickly see diffs across a bunch of changes. I use gg for this but I'd prefer a side-by-side diff and, ATM it only has a traditional diff.
Also, watching the video of git butler, it seems like a jj UI could take a lot of inspiration. I'd love to be able to just drag changes rather than `jj rebase ...` and/or drag selections of lines.
I'd also like a nicer GUI for interactive splitting/rebasing than the TUI UI built into jj
How about tig?
The please is because I am tired of fixing issues created by people being confused by git. Just use anything else than the git cli, it's probably better.
If I want to be hard-core, I'd use the original git CLI. SourceTree is unmatched in how it makes using git so much more pleasant for when you need to do something relatively simple, but which would be quite cumbersome to do with the CLI and most other tools I've tried.
Its file status and history view is unmatched IMO. I can easily stage/unstage hunks and even lines. The whole UI is generally quite polished and pleasant to use.
It's a real shame there is not a version for linux. I've tried every other git interface under the sun and keep coming back to it. In the meantime, I tried lazygit the past weekend and I think it is one of the better TUI git tools out there, definitely better than GitUI.
No, please throw SourceTree into the garbage can.
One of the main things I like about it is that it does _not_ auto refresh. A long time ago with SourceTree I'd have issues mixing git CLI and SoureTree because two processes would be doing things at the same time (I assume SourceTree was doing things like `git status` while I was trying to `git fetch` or something).
https://git-extensions-documentation.readthedocs.io/en/main/...
These days I use VSCode and the Git Graph extension.
People who defend the CLI as the only real way to use Git simply haven't used a decent GUI for it. I consider myself a very advanced Git user, but I barely know the CLI commands off the top of my head.
A GUI really makes a lot of sense for something like Git, most of the time what you want to do is "contextual' from something like a list of files to commit or a log of commits and TortoiseGit is pretty good about exposing whatever you'd need to do.
I find that with GitKraken (aside from not being free), I just don't feel in control of what I'm trying to achieve with Git.
Git Extensions seemed pretty decent and possibly a nicer GUI paradigm than TortoiseGit, but when I tried it I found TortoiseGit to offer more power to me.
One thing that does annoy me a bit about TortoiseGit is that it has this philosophy of a new Window for everything, which for most things is not a problem, but is in a couple of places. For example, to work on a repository you tend to have to use the Explorer context menu to do things. I tend to open the git log window once and leave it open, and from it I can do pretty much everything. If it had some sort of "main app" view with a tab per repository you have open that would be awesome, instead of my having to have multiple open log windows. Similarly, for commits and PRs I like to double check each file's diffs. Its UI opens each one in a new window, but if it would rather have a sub pane from the commit view I think it would work better.
I used to use SourceTree in conjunction with TortoiseGit because I liked its tabbed UI for the simple things like pulling/fetching/pushing, switching branches, but I stopped using it about 5 years ago, the Windows version of it felt neglected in that it would often crash or become very slow.
I think there's a learning around stability of devtools here. It takes time to get used to things, but once you do you are ultra productive. That's why IDE Git UIs are not ideal, because the graphics change so often, confusing you more than helping etc.
I got stuck to git gui / gitk for so long for this reason, I couldn't parse other UIs e.g. for diffs until I forced myself to have a less productive time to learn new UI.
I hope lazygit is stable - I think I might need to construct some stable config for visuals / colors to ensure this! (:
I found lazygit specifically so bad to the point that I was better off typing in git commands into the terminal manually like some sort of caveman. Somehow, lazygit has found a way to make git even more confusing and user hostile than it already is, which is a significant achievement.
Using it was a harsh reminder of what people running emacs or vim for the first time have to go through.
This idiotic ui paradigm where you have to actively learn to use what should be simple software by memorizing commands and shortcuts needs to die off. It's mind bogglingly inefficient and disrespectful of user's time.
Just think about it - I've literally never had to open Fork's manual (I am not even sure it has one) whereas in lazygit it is utterly impossible to do the most basic things without referring to the manual. Why do we collectively keep tolerating these shitty tools?
"Using it was a harsh reminder of what people running emacs or vim for the first time have to go through."
The benefit of keyboard-driven programs like Vim is that you're trading an initial learning curve for a vastly more efficient experience once the learning is done+.
Mouse-driven tools like VS Code don't demand that the user learns them. Keyboard shortcuts there are optional, since practically everything is in a menu or a UI that can be moused to. This adds on seconds per interaction, adding up quickly over time.
+And the "learning" for these tools can be shortened dramatically by keeping a printed-out cheatsheet. For Vim this can be a huge lifesaver; I made one for magit as well, back before I switched full-time to JJ.
I managed to get on fine with lazygit during a quick trial this morning. It actually doesn't have a manual (`man lazygit`: `No manual entry for lazygit`) but I found the contextual help (e.g. press ?) useful.
Lazy git checks off a lot of boxes. Easy tool to adopt to speed up and simplify your git workflow
Honestly, it's too much magic for my taste. And, really, it's not much manual work to create fixup commits for the right commit anyway.
Really happy to see it featured here, I became a convert couple of years ago after switching to Astronvim (lazyvim is bundled with it).
1. Fork: https://git-fork.com
2. Kaleidoscope: https://kaleidoscope.app
3. GitUp: https://gitup.co
4. Tower: https://www.git-tower.com/mac
But the main use I get from it is for incremental index adding, so maybe not as much as OP.
[1] https://jonas.github.io/tig/
https://github.com/jesseduffield/lazygit?tab=readme-ov-file#...
So with a newer non-LTS ubuntu you can just apt install lazygit, with 24.04 it's
``` LAZYGIT_VERSION=$(curl -s "https://api.github.com/repos/jesseduffield/lazygit/releases/..." | \grep -Po '"tag_name": "v\K[^"]') curl -Lo lazygit.tar.gz "https://github.com/jesseduffield/lazygit/releases/download/v..." tar xf lazygit.tar.gz lazygit sudo install lazygit -D -t /usr/local/bin/ ```
I have it so that anytime I press ctrl-g in a git repo, I open a floating tmux pane in my current working directory. This might sound "whatever", but it means I don't have to actually be inside neovim or "switch" to the LazyGit UI. It just overlays it on top of whatever I'm doing at the moment in the terminal.
Makes for the most fluid, streamlined git experience ever if you primarily live in the terminal.
Oh yes, I use lazygit as a separate binary (brew installed) from separate terminal shell all the time. No need for nvim!
Great to hear you can neatly configure similar UX (popup) with tmux!
For instance, you can visually select a range of lines in a file, and stage those lines.
This is much easier than doing "git add --patch" and using edit, where you are deleting unwanted lines starting with +, turning - lines into context and whatnot.
I have found it useful to fire up "git gui" during rebase workflows with conflicts. It helps with the "git add" commands you would have to do to add conflict-resolved files into the patch and whatnot.
What! I was git gui user for decade and didn't notice this feature =D But yea, git gui is amazing overall. I don't think it's maintained anymore though.
BTW lazygit offers that too and it's a bit easier to discover and use (e.g. you don't need a mouse).
I do recommend turning off force push (there is an option), as it's easy to fat finger and leads to a whole lot of heartache.
But if you do any advanced work that involves merging a complex codebase across multiple branches, with generated code and multiple languages; and having to manage your load of conflicts, I find Fork[1] (the free version does fine) still takes the cake for that, as the clarity and lack of keyboard bindings, is essential; to make good, conscious decisions.
[1] https://git-fork.com
git gui → Amend Last Commit → (select lines from a file in the Staged Changes area) → Unstage Lines From Commit → Commit
I still think it's the perfect does-just-enough GUI when the main thing you want is to visually craft commits.
Sure, it's rough around the edges, but I know those edges well. I sometimes do need to look up how to do something, but those cases are rare. Over the years I've accumulated about a dozen shell aliases and a modest `.gitconfig`, and along with a couple of helper tools[1][2], I can do 90% of what I need Git for in seconds. I truly don't need a fancy TUI, GUI, or any wrappers around Git. Git itself is fine.
I tried Magit a few times, and even though Emacs is my main editor, I couldn't get used to it. It forces the user into doing things the "Magit way", and I'd rather not.
I don't understand the push to replace Git's porcelain with something shinier. If, and when, a better VCS comes along that truly feels like the next step forward, I'll give it a try. In the meantime, Git does the job I need.
[1]: https://github.com/mroth/scmpuff
[2]: https://github.com/dandavison/delta