I don’t avoid a GUI. I just use it for what I find it efficient (complicated diffs and merges, complicated history, etc) but use the CLI for other stuff I find the CLI more efficient for (simple history lookups, diffs, merges, staging changes, commits, cherry-picks, rebases, bisect, etc).<p>There are many reasons why the CLI is far more efficient for me for this.<p>1. I’m rarely ever just doing GIT operations in isolation. Depending on the kind of project there’s a whole lot of other stuff going on as well…builds, unit tests, etc… I can’t run that out of Git Tower. But I can run all of those from within the same CLI environment.<p>2. I can never modify the way GIT tower presents information to me. However, I have a lot of tools to isolate exactly the information I want using git on the CLI where it makes sense because the CLI allows me to compose GIT outputs with an extremely large library of tools in a way no GUI application does.<p>3. I love scripting. If I do the same action more than a few times I will write a script for it. And the CLI allows me to do that in a way GUI tools don’t.
Some people prefer CLI over GUI, me included. For a lot of us, GUI is really inefficient compared to keyboard-centric interfaces. You have to move your hand away from the keyboard for every little thing you want to do. I see it as analogous to the difference between spinning disks and solid state drives; one is better in almost every way, the other only has like one advantage for a subset of people.<p>I also recommend against using git GUI for beginners just because it hides so much of what's going on, making it easy for people to stop learning after they figure out how to do exactly 2 things with it: commit and push.<p>But honestly if we're going for "best" I think magit is the winner.
Simple: it's a preference. I go for CLI over GUI whenever I can. Some people go for a GUI whenever they can. And some people (way too many IMO) just go for whatever "seems to just work" and doesn't require them to learn how to use correctly.
I prefer GUIs simply because they let me see several things at once with a window split up into panes without having to multiplex or tile terminals.<p>It can’t just be any UI though, that I’m particular about. My favorite used to be the native GitHub client for Mac, but when GitHub abandoned that and replaced it with a much worse cross platform app I switched to Fork[0] which has been excellent and even has a native Windows counterpart. Sublime Merge[1] is also nice but doesn’t gel as well with how I think.<p>[0]: <a href="https://git-fork.com/" rel="nofollow noreferrer">https://git-fork.com/</a>
[1]: <a href="https://www.sublimemerge.com/" rel="nofollow noreferrer">https://www.sublimemerge.com/</a>
I’m surprised no one here is mentioning the two GUI programs distributed with Git: gitk and git-gui. Just type “git gui” in a repo to bring it up. The biggest thing I like to do with git-gui is staging individual lines from the working copy into the index. This is possible with “git add -i”, but this is one place where a GUI is much more pleasant.<p>gitk takes similar arguments as “git log” or “git rev-list” does. It’s a pretty ok way to view commit history.<p>Both of these are kinda quirky tk/tcl programs. But they are available on cross platform, so I only have to learn one GUI for Linux, Windows, and macOS (though the macOS support is the most likely to be broken).
In general, the primary values a gui has over a cli:<p>0. Visually demonstrate proposed intended behavior unfamiliar to the user.<p>1. Visually select desired operation behavior interactively.<p>2. Gradual disclose features and teach a cli from a gui tool.<p>A good git gui should continually display cli equivalents, log cli-equivalents of operations performed, or allow visual commits, rebases, cherrypicks, merges, branches, etc.
I’ve been primarily using lazygit and man is it nice. It’s perfect for typical workflow stuff (pulling/pushing, branching, even conflict resolution). Occasionally I’ll reach for the command line for more advanced tasks though. There’s just more fine-grained control with the cli tool.
For me at least I do all of my development on the command line, so it's just much easier to use the git CLI instead of switching between applications. And regardless, basically all the commands I run (moving between commits and rebasing, mainly) can be done just as fast or faster with the CLI, with the added benefit of being able to see and retrieve your command history to easily redo actions.<p>I kind of have the opposite question - what benefit does a GUI have for git? If your tree gets super complex I get how a GUI makes it easier to navigate, but if you only have a couple branches it seems easy enough to just view in terminal.
Intillij Git branches is the only git ui I've used and I love it for one feature: it stores your workspace layout based on the branch you're in. So now when I go to an old branch every tab I was working on is there in the configuration I left it. This prevents from having too many tabs and helps keep them organized.<p>Still, for every other git function I find the cli and ctrl-r much quicker.
I really like Visual Studio Code's Git integration. Both the default one and the GitHub extension that really helps with PR reviews.<p>I've paired with devs that use CLI and it feels like they're in the stone age, especially when doing merge operations, but, at the end of the day, to each his own.
Intellij has built in Git GUI which has lots of features of other commercial dedicated tools. Features I use include selecting and committing individual lines where needed, rearranging and squashing commits all within easy ui.
I prefer a gui and use magit in emacs. But everytime I ask someone they act offended that I'd even think they'd use a GUI instead of the CLI. I really really like gitkraken as well but I wouldn't pay for that.
100% agree with this. Personally I've been using SourceTree since before it was acquired by Atlassian. It's such a powerful tool because it instantly gives you a level of situational awareness that would take several commands to get from the command line.<p>I usually still make commits from the command line, but then review them in SourceTree before pushing. I also find it to be a much more straightforward interface for doing an interactive rebase.<p>Looking for a replacement has been on my to-do list for a while however, as Atlassian has kinda been letting it lagnuish.
Sadly TortoiseGit[1] is only available for Windows :(<p>git-cola[2] is a decent stand-in for TG's commit review window though.<p>[1]: <a href="https://tortoisegit.org/" rel="nofollow noreferrer">https://tortoisegit.org/</a><p>[2]: <a href="https://git-cola.github.io/" rel="nofollow noreferrer">https://git-cola.github.io/</a>
Historically, git gui programs were often incomplete. You still had to drop into a shell to do some work. Often, gui VCS were also not-git. Finally, there's this culture of "oh, you use a gui for git? you must not understand the tool."
I currently use a Git GUI (SourceTree) because I used to use a GUI when working with TFS, CVS, and SVN. So when we switched to Git, the CLI paradigm just seem unfamiliar to me.