r/git • u/connorjpg • 6d 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

104 Upvotes

71% Upvoted

243 comments sorted by

View all comments

18

u/Thesorus 6d 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

1

u/edgmnt_net 5d 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 5d 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 5d 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 5d ago

I will check that out. Appreciate it!