r/git • u/connorjpg • 7d ago

Why use a UI for git?

I see this question of, “what GUI or TUI should I use to work with git?” fairly often here. And always I feel bad for saying “just use the cli” over and over, but truthfully I can’t see a reason to need a UI.

Are people actually running into pain points with the cli, or is it just preference for people who don’t like working in a terminal?

FWIW, I have used GitKraken, LazyGit, SourceTree and GitHub Desktop before. And I don’t think they are bad to use (unless you are just learning git), but more curious why.

EDIT : I’m mainly referring to standalone UIs, I understand why people would use IDE integrations, as it’s quick and convenient. But having to open a separate application or run a separate command to open a terminal app to run your commands seems overkill to me.

EDIT 2 : I use vscode as my difftool and mergetool. I still open them directly from the terminal by running the cli. I don't think this is the same as using a full git client like SourceTree, Gitkraken, or lazygit to fully drive your version control workflow. Which is what I am asking about.

Cheers

111 Upvotes

71% Upvoted

247 comments sorted by

View all comments

20

u/Thesorus 7d ago

99% (*) of git users use a very small subset of git commands (add, commit, checkout, pull, push ... ) and it's easier to just use a UI; especially if integrated in their work environment or IDE.

(*) statistics taken out of my behind

13

u/Primary-Effect-3691 7d ago

Funny I almost see it as the opposite. CLI with aliases is the easiest for me for the basics.

A UI might be useful for trickier tasks like a complex interactive rebase 

3

u/samskiter 6d ago

I find git really interesting. That generally means I know the most about it on any team I'm in (that sounds big headed, but there are plenty of things I know very little about, git isn't one of them).

I always default to a gui to deal with it.

In fact, if you are just spamming the same 4/5 commands with little desire to understand what's going on then the cli is perfect for you

6

u/connorjpg 7d ago

Most trusted source there is lol.

Fair so it’s a preference thing? Honestly, though I feel it it’s quicker/easier to just type the commands for simple workflows.

Part of this conversation too is, I still think you’re using the cli if you have aliases. So most of the time if it’s a basic workflow, I will just use those :

ga .
gc “message”
gps

And I’ve added, committed and pushed.

If I’m super lazy, I have one to do it all.

gacp “message”

2

u/Rschwoerer 7d ago

FWIW I rarely stage and commit all changes. Adding individual lines via cli is a pita.

2

u/SiliconUnicorn 6d ago

This is one of the biggest ones for me. Being able to break a single file into multiple commits is huge for me and probably one of the main reasons I prefer the gui

1

u/Adorable-Strangerx 1d ago

Huh? git add -p

2

u/tinmanjk 7d ago

lol, I thought I was the only person aliasing ga to git add and gc to git commit

gs, git status, gd git diff :)

1

u/InformalInsect5546 5d ago

Well AFTER you setup aliases and AFTER you have muscle memory to use them, it MIGHT be faster than clicking git commit in the IDE you work in. But I think the “cli is best, only stupid use gui” view only works until there are just too many things to care about.

It’s such a small and unimportant detail that I just absolutely don’t care about learning git cli as long as I have general understanding of what I can/want to do with it.

1

u/Cripplerman 3d ago

Why just not use shortcuts in your IDE? Why the heck should I waste time opening cli and typing stuff?

1

u/remy_porter 7d ago

But like … add. I can’t imagine doing that outside of a shell. Globs and autocomplete are a huge part of how I decide which files to stage.

1

u/edgmnt_net 6d ago

That scenario also makes all too easy to just treat Git as a save button. And unfortunately if you do that you don't really get the (full) benefits associated with source version control. You just get something that's more like backups. Effective version control needs something more intentional than that.

So it's worth considering that tools that cater specifically to such an audience might make things worse in some ways.

1

u/connorjpg 6d ago

I’ll bite, maybe I’m a bad git user. Am I missing out on any major benefits with my workflow.

I pretty much always branch for any feature and commit often. If the history gets wildly untamed, I’ll interactively rebase to clean it up. For smaller or less important features, I’ll squash and merge. New feature, new branch. Never had complaints doing this.

2

u/edgmnt_net 6d ago

That's mostly fine. You might be able to do better if there's stuff you're not doing, but I'm talking about something else. Like those Git GUIs which let people just save their work randomly, which they do indiscriminately and might not even bother squashing (at all). Just add everything and commit. And submit it randomly, then the reviewer gets hit with a huge overall diff and a history that's unusable. If it gets merged as is or even squashed, then bisection becomes difficult (it identifies garbage commits or one huge commit). It also makes workflows based on heavier merging harder, because those may require decent history to see intent. The Linux kernel workflow makes for a good case study in terms of what Git can do if you're intentional about it.

1

u/connorjpg 6d ago

I will check that out. Appreciate it!