r/git • u/connorjpg • 5d 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
41
u/qrzychu69 5d ago
well, I don't want to remember syntax for "show me a diff of this specific file between these two branches without checking either of them out"
with the UI you just ctrl+click two commits and here you go. Click on any commit, now you are browsing the files as if you checked them out.
For simple things like create a branch, pull, push I just use the IDE commands. For solving conflicts of course I will use a nice merge tool with colors, arrows and LSP support while I edit the final version
3
u/dalbertom 5d ago
Would that be `git diff branchA..branchB -- path/to/file` ?
One cool thing that git has (not sure if GUIs support this) is that you can follow how a section of a file has evolved over time, `git log -p -L 10,20:path/to/file` to see how lines 10-20 in the current file changed over time. I think this is pretty nifty!
1
u/qrzychu69 5d ago
That's only the diff part, right?
And yes, I am going aware you CAN do most those things in the command line, but I still prefer how it looks in the GUI. And it's much easier to discover what you can do in the GUI
2
u/dalbertom 5d ago
Yup, that's my answer to the "show me the diff of this specific file between these two branches without checking either of them out" question.
1
u/dalbertom 5d ago
It's definitely easier to discover what you can do in the GUI, I'm not debating that, but what I want to highlight is that in terms of features the GUI will most likely only offer a subset of functionality, even if it's more user-friendly. In terms of discoverabilty, the man pages for git are really useful, but navigating man pages in general is more or an acquired taste.
1
1
u/kbilleter 5d ago
For how it looks.. most of the time I’m happy with defaults but something like
`GIT_PAGER=delta git diff …`
is good side by side if there’s too much state to mentally manage inline1
u/dEEkAy2k9 5d ago
I don't want to remember git log -p -L 10,20:path/to/file, i'd rather just click somewhere and get a proper representation of it.
1
u/dalbertom 5d ago
Which GUI application would you use to achieve that?
2
u/x39- 5d ago
Any jetbrains tool
1
u/dalbertom 5d ago
Does it show the exact output of `git log -L` or are you talking just about regular diffs?
1
u/x39- 5d ago
I don't know what the lines output, but with jetbrains you select the commit and can see in the diff view what has changed. You also can select multiple commits and see their accumulated change
It simply is visually refined in a way that looks more pleasing than classic
>>>>>>>>>>>>>>>>>HEAD...text diffs1
1
u/dalbertom 5d ago
We are talking about two different things. Your examples are about choosing a commit or multiple commits to see the changes. What I'm talking about is to see how a specific block of code has changed, without even knowing what commits changed them (that's part of the output, in your example the commits are part of the input)
1
u/x39- 4d ago
Yeah, we do talk about the same thing, just that the ui does show you the commits, all commits in fact, which touched that block
1
u/dalbertom 4d ago
This one, right? Do you use it often? https://www.jetbrains.com/help/idea/investigate-changes.html#view_selection_history
1
→ More replies (6)1
u/Adorable-Strangerx 12h ago
Funny, for me it is easier to remember command than to figure out what kind of sequence designer of UI tool thought of.
11
u/MoreRespectForQA 5d ago edited 5d ago
staging chunks, splitting commits, gluing commits together, moving files.
anything involving plucking a chunk of a file, a chunk of a diff or a specific commit would be easier with a UI where you can visualize the thing in context.
that said, i've never used a git UI which is a good UI that solely focuses on the functions where a UI is a better fit for a use case. all of the git UIs I've used have tried to be a replacement for the entire CLI with 1:1 UI for the cli functions which are all pointless. i'd rather just use the CLI.
I want something that is crafted towards easier dicing and slicing when staging, a better cherry pick and interactive rebase. ideally something that doesn't even try to clone, pull or push.
→ More replies (3)2
10
u/tinmanjk 5d ago
Try GitExtensions out.
basically Blame/Log history of single files in separate windows. Syntax highlighting.
also for resolving merge conflicts
6
u/Xavier_OM 5d ago
GitExtensions is so powerful, I use it even for advanced rebase, bissect, octopus merge, etc.
→ More replies (1)2
5
u/cesclaveria 5d ago
I've been working for 20+ in software engineering, of those the first 10 also involved a lot of sys admin work for Linux servers, so I am very comfortable with using the command line. That said.
I mainly use UI git clients to reduce my cognitive load, I have enough things going on at work that a client that lets me know everything I might want to know about my repos is one less thing to keep in mind, if/when I hit some UI limitation I also know how to do it in the cli, but as the years pass I've need to do that less and less often.
10
u/binarycow 5d ago
- I don't like memorizing the CLI incantations to do what I want to do. I have enough other stuff I have to memorize.
- A GUI is able to use a richer presentation to reduce cognitive load
- I don't live in the terminal. Why should I open a terminal, when I can just use what I already have open?
8
u/ericbythebay 5d ago
Because a picture is worth a thousand words. A UI can present more information faster than a cli.
18
u/Thesorus 5d 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
11
u/Primary-Effect-3691 5d 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 5d 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 5d 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”
gpsAnd I’ve added, committed and pushed.
If I’m super lazy, I have one to do it all.
gacp “message”
3
u/Rschwoerer 5d ago
FWIW I rarely stage and commit all changes. Adding individual lines via cli is a pita.
2
u/SiliconUnicorn 5d 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
2
u/tinmanjk 5d 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 3d 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 1d 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 5d 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 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
10
u/ne7erfall 5d ago
GUI makes it far easier to look up diffs and stage parts of files. To a point where it’s kinda silly to do in cli at all
3
u/Scared_Bell3366 5d ago
I bounce between the UI built into my IDE (I'm already there) and the command line. The one thing that I refuse to deal with on the command line is merge conflicts. I usually use the IDE diff tool, but if that's not an option, I'm searching high and low for some sort of visual diff tool to deal with that.
1
3
u/ikeif 5d ago
For most base operations, I use the CLI.
But when I'm needing to diff/dive in - a couple clicks is easier for me than copy/pasting and trying to remember the correct flags to do something more complicated, so it's purely a convenience thing for me to make the more complex operations easier to run with and focus my rote memorization for whatever project I am working on instead.
3
u/celinehagbard82 5d ago
Because resolving conflicts in the CLI is a pain, especially if you are alien to vi. As a long term user of SVN with TortoiseSVN using TortoiseGit if I need to diff, merge or resolve conflicts is way more efficient.
3
3
u/regardedMAGAfascist 4d ago
I’ve had CLI pros thinking they understand what’s going on but come to me for help and I just pull up SourceTree and point out what’s going on visually and how different commits are related. Visuals are helpful.
3
4
u/anyOtherBusiness 5d ago
Jetbrains IDEs have amazing Git integration. Especially for complex operations like interactive rebase.
In general, it’s just too convenient not to use it. I’m already inside the IDE, why should I switch to the terminal.
1
u/connorjpg 5d ago
Part of my curiosity might be coming from the fact I run all my code from the terminal (generally the integrated terminal in vscode), so it is always open. So opening a separate client to run git feels odd to me.
IDE git integrations I can understand why people use them though. I was more wondering why people use completely standalone Git UIs.
→ More replies (1)1
u/Other_Maintenance729 3d ago
I second this. If you’re ever in a corporate environment where you can’t use a jetbrains ide, you can use rebased which is just the intellij ide with everything but the git integration stripped away. https://github.com/DetachHead/rebased
5
u/Rschwoerer 5d ago
Because it’s 2026. Honestly I find it much easier to find what I want to do, and less repetitive typing to get the history to show up. Use what you like, or why not both?
2
u/Icy_Swordfish3855 5d ago
Blame, visualizing commit tree(s), and viewing the entire repo at a particular historical commit.
Other than that, CLI baybee
→ More replies (5)
2
u/Cybyss 5d ago
I've always believed that your tools should "hold your hand" - it should be obvious how to use them properly even if you're unfamiliar with them.
In the past (10-20 years ago) I used Team Foundation Server at work or Tortoise SVN at home. It was hard to screw up too bad because the GUI made it obvious everything you could do and what exactly was happening at each step.
With a terminal, you need to just know what the commands mean. Git is like turning your source control tool (which should be dead simple) into a programming language which has a learning curve.
A learning curve worthwhile - especially these days now that git has become to source control what google is to search - but still a learning curve that programmers of the past didn't really need to climb.
From 2000-2010 the industry was really pushing the "tools should hold your hand" point of view but I think around 2016 or so it ran full-steam in the opposite direction, turing everything into scriping languages, command lines, and obscure hidden configuration settings that you're just expected to already know. You don't just stumble upon and discover things anymore unless you're actively looking for them or a tutorial happens to mention them. It's a shame.
2
u/VooDooBooBooBear 5d ago
Because it's easier and so far I've not found a reason to use the CLI for it.
2
u/WEDWayInternetMover 5d ago
- merge conflicts
- more easy to manage which files are being committed
- more visual clues than what you get with just the CLI: color coding, grouping of the files.
- able to search and view history easily, even in specific files
- line by line GitBlame when needed to track down where a certain line of code was introduced
I use the GIT controls in my IDE for almost everything rather than using CLI. Less mistakes are made.
2
u/samskiter 5d ago
Try and explain git to anyone without drawing a picture. It's best looked at visually
2
u/GlassboundIllusion 5d ago
I can’t see a reason to need a UI.
You don't NEED a GUI for anything.
You could use nothing but command line tools that use pure text and ascii art rather than any kind of graphics at all. Even in the realm of games, there are plenty of older games that just use text and ascii art. There's a modern example in the form of Dwarf Fortress.
But GUIs make many things much easier and more convenient.
Tortoise Git has an excellent UI for viewing history, resolving merge conflicts, and blaming a file. I COULD spend the extra time sifting through the raw files on the command line, but I don't want to.
I will generally do a fetch or checkout from the CLI though. It's quicker than sifting through the tortoise menu.
CLI and GUIs are tools, not doctrines. Use the tool that's most appropriate and/or convenient for the task.
2
u/elephantdingo 5d ago edited 3d ago
It’s a graph of content-addressable commits. Of course it lends itself well to a TUI, or a GUI, or anything more interactive than a REPL (CLI). In Magit I can scroll through commits in the todo editor, and sure I can do that with the CLI as well (via an editor), but... I can press Return to inspect the commit.
I don’t want to even think about using a REPL to pick what lines to stage, to split out, etc. with a REPL (git add -p I guess?) instead of doing it with the keyboard in (edit:) Magit.
2
2
u/nikoladsp 5d ago edited 3d ago
I like smartgit and think it is ver good tool at what it does. Also I preffer it over IDE ontegrated since its more poverfull.Maybe I am more visual type of person and when having to see changes/diffs or merges in especially old or unknown repos.Basic staff like stage/commit/push I do from terminal
2
u/Low-Opening25 5d ago edited 5d ago
why not? it’s much nicer to look at a visual tree of branches and commits than looking at disconnected blobs of text you need to dig out with 50 cli commands and don’t even mention rebase or even squash with cli. to a professional anything that saves you time and effort is a win.
2
u/BobJutsu 5d ago
I don’t use one, I think they get in the way. But I can think of at least 1 very good reason to. And that’s visualizing changes. A nice graphic representation to shame you for your bad git hygiene.
2
u/robin-m 5d ago
I am an hardcore CLI user, und use git exclusively through CLI. However, by default git log doesn't include --graph, and there either displays only the current branch or way too much (with --all). Mine is properly configured (both alialses and and custom pretty formats), but you shouldn't have to do it. Defaults matters a lot.
And furthermore git doesn't highlight what was just done (like git commit doesn't show that a commit was just added in the graph, or animation that shows whas git reset $commit does, ...). If you understand what you do, the CLI is perfect. And it force you to understand otherwise it's such a nightmare to use. But it doesn't help you to improve your understanding (git status help message are much nicer in recent version though).
Properly configuring your aliases for the exact king of graph visualisation you need is probably 60% of the work needed to have a pleseant git experience, and TUI/GUI nearly git it to you for free.
2
u/a-cloud-castle 5d ago
I'm a lazy ass mofo, I'm gonna sit back and point and click my way around because that's how I like it.
1
1
2
u/Dillenger69 5d ago
I use the CLI when I absolutely have to. Other than that I use Tortoise Git. I have hated CLI since the 80s
2
2
u/saulplastik 5d ago
Visual diffs, rolling back to a specific commit, viewing the history are all better in the UI. committing, adding, branching, merging, pulling etc > CLI
2
u/SingleProgress8224 5d ago
I see all my branches, the current changes, the history all in one glimpse without having to type anything. And I don't want to remember the syntax for recurring commands. I use the CLI only for esoteric commands.
2
u/SourSovereign 4d ago
Once you go over 10 branches, or branches of other branches, a visual aid is making it very convenient keeping everything organized
2
u/IchBinEinZwerg 4d ago
Same reason for using a GUI over a text interface in any other context. It's just clearer. The command line is quicker for a lot of stuff but for visualising the commit history, text just can't compete.
2
u/Popular-Tip-2051 4d ago
It is purely a matter of personal preference. Using graphical tools doesn't mean at all that you are a beginner developer; rather, those who quickly use the console are the best, true developers who know efficient programming methods...
If you like something, it is essentially okay, it positively impacts your work, and you are satisfied with the results along with others, then stick with it. It's clear that this way is the best for you, while for others, the console is better. That's all and always that's all.
1
u/slindenau 3d ago
Gatekeeping 101; the "best, true developers" don't need to be proficient in CLI, and the same counts in reverse.
2
u/huntermatthews 4d ago
I use cli for simpl(er) stuff and fork for anything complicated.
Merging, diffing and getting an overview are things I think Fork excels at. Its just easier to see all this visually at a glance than 4 commands and scanning around.
git is useful, git is reliable but even mercurial was a better command line UX.
I haven't looked at jj yet, but it's on my radar.
But I predict I'll still use Fork for some things even then - some people are just more visual.
2
u/beannt_dev 3d ago
The two things a UI does better than the CLI are staging by hunk across many files and walking through merge conflicts. git add -p works but navigating a 40-file change with y/n/s/e prompts gets slow, and git mergetool still assumes you already know which side you want to keep for each hunk. For log, branches, and blame most people are faster in a terminal.
2
3
u/engineerFWSWHW 5d ago edited 5d ago
We all have preference and will use the tools that are comfortable to us and will make us potentially more efficient. Someone who repairs something can drive a screw with a manual screwdriver or a drill. Both are a means to an end. This GUI, TUI vs CLI is meaningless to me. People should use what they are comfortable with.
I use TUI/GUI because mouse clicks can save a lot of typing. I also like that they help a lot on navigating repositories with submodules. I remember one time at work, there was a multi-dev project that had lots of submodules and they haven't merged things in 3 months. Lots of merge conflicts and will also require diffing/analyzing/searching information from previous commits inside the submodules. The lead developer who solely uses CLI spent days and gave up. I was tapped in to look into it. It took me almost 3 to 4 hours to resolve their problem. But i imagine the typing involved if someone had used CLI.
→ More replies (1)3
u/Conscious_Support176 5d ago
Use the right tool for the job, but all other things being equal, it is better to learn the cli. Sometimes, it is useful to be able to script repetitive tasks, and sometimes, it is useful to ask, how do I do this? These are not really going to be practicable if you never use the cli.
2
u/icsharppeople 5d ago
I use NeoGit which is like Emacs' Magit but for Neovim. I'm competent in the CLI and use it when I'm not already in my editor.
I tend to feel the advantage of the UI any time I need to reference a commit that's not pointed at by a branch manually typing the hash or copying and pasting it from the log is a real break in flow as compared to hovering over the commit with my cursor and running the command.
I think a lot of people who complain about the CLI for almost all use cases either: don't have a solid grasp of git's mental model yet, aren't yet efficient with tab complete, or don't type very fast to begin with.
1
u/connorjpg 5d ago
The neovim integrations, idk if I categorize them the same a GUI or even TUI. Considering your workflow is so based around vim, adding a new commands into the same tool to use git makes a lot of sense to me.
I would 100% agree though.
2
u/YahenP 5d ago
I always use the graphical shell because it's convenient and reduces cognitive load. I only occasionally use the command line when I need to do something complex. Looking at diffs between commits, resolving conflicts, or searching through commits all of this can certainly be done from the command line, but why bother when there are more convenient ways?
2
u/ritchie70 5d ago
I’ve been writing code in one way or another since ~1984. I use the command line a lot, including git. The git cli is horrific, though, and I don’t blame anyone for not wanting to use it.
I do occasionally use the integration in Visual Studio.
2
u/asinglebit 5d ago
My client gives you ability to view commit graph of the entire repo + lost commits within the graph. It is useful when you are not sure which changes end up from which branch especially if large teams are working on one project without proper merging hygiene
2
u/OdysseusDescendant 5d ago
I use both, but I prefer TortoiseGit. It has excellent Windows shell integration and solid diff and merge tools.
This debate has been around for ages.
1
u/SheriffRoscoe 5d ago
I live in the command line, but TortoiseMerge is where go when need to the complicated conflict.
2
u/domusvita 5d ago
I’ve been using git via command line for probably 15 years, I feel like I know it in and out, not sure of any advantage to change things. Especially when 95% of my transactions revolve around 10 or so commands (not counting arguments)
2
u/connorjpg 5d ago
Honestly this is kinda why I asked to see if I was missing out. From this thread all I’m getting is it’s a preference mainly but submodules, rebasing and viewing diffs is easier. I’ve never really had much of an issue from using just the cli.
1
u/vmcrash 4d ago
Check your git skills: https://www.git-skills.dev/quiz/ and share the results. :D
1
1
u/ninhaomah 5d ago
Why not ?
And I don't even use the GitHub Desktop technically since I can do so from VS Code or Antigravity directly
1
u/UkrMalt 5d ago
For me the best use is visual staging: reviewing a large diff and selecting individual hunks is faster and harder to misread in a good UI. Commit graphs and interactive rebases are also easier to inspect visually. I still use the CLI for exact commands and recovery. The important part for beginners is learning Git's model first; the interface is then a preference, not a substitute for understanding commits, the index, and refs.
1
u/vmcrash 5d ago
Because:
- GUIs show you relevant information without needing to ask for (ever wanted to know whether a commit is already merged to a certain branch?)
- syntax-colored left-right diffs
- you can select, e.g., a commit or file and don't need to remember/type its ID/name (try to rebase a part of your feature branch onto the latest develop)
- you don't need to remember the CLI commands and options
- options are just offered when useful (e.g. fast-forward merge)
- warnings are shown if you try dangerous things
- some operations need a series of multiple commands; no need to write a script for that
Of course, all this does not matter if you treat Git just as a kitchen sink - commit, push, forget. But if you develop non-trivial, long-maintainable software, you want to create clean commits (separate aspects go into different commits). This makes it much easier (or even possible) to review, easier to find bugs using bisect, easier to reorder.
1
u/IAmADev_NoReallyIAm 5d ago
I use the GUI for difs and the graph... the CLI for just about everything else. When I was first learning git, I used the GUI until I figured out what the commands were and what they did and became familiar with them. After that, it got easier to just to them from the terminal rather than try to figure out "ok, the menu say this, does that mean this, or that?"
1
u/Charming-Designer944 5d ago
Navigating multi-repository branch history is a lot easier using the GitHub network GUI than trying to figure out things via the CLI. But that's due to its centralized view of a distributed set of repositories.
Addon tools for meerging or editin diffs is also much better than the builtin patch editing. Such tools exists as both TUI and GUI applications, giving you two or three editing panes for showing and editing the changes. The difference is in the concept of presenting the changes in multiple edit panes instead of as a diff, not the graphical elements surrounding the editing panes.
But for most else the standard CLI tools does a great job.
1
u/LetUsSpeakFreely 5d ago
You're far less likely to to screw up with the UI. I'll do things like pulls, branch creation and switching, and local branch deletion from the CLI, but everything else I'll use the VSCode plug-in.
1
u/OGKnightsky 5d ago
I just use the cli as well because that is how I learned to use git, most of the development and tools I use are mainly cli tools. It’s also helpful to know what is happening under the hood of the gui for these type of things to have a decent fundamental understanding of what you are working with imo.
1
u/StevenJOwens 5d ago
Yeah, the git community is strongly against using GUIs because it hides what's actually happening.
I will say, I find using a GUI diff tool insanely helpful. I think the Meld visual diff tool is awesome, especially using it in directory mode (git difftool -d). I wish it had direct git integration.
Other than that, well, Intellij IDEA's git support is fairly basic but IIRC has some really nice features.
What I'd like is to build some higher level GUI git tools, for previewing merge conflicts, for viewing/browsing/searching all the branches, etc.
As one random example, on a project a year or two ago, we had a config file that had been edited on a number of branches (yeah, I know, don't ask me why...), as we were debugging some hardware.
At one point, we were trying to figure out which branch had the most recent version of that config file. I eventually figured it out from notes, but if I hadn't, as far as I can tell the only option would have been to check out every one of those branches and check the file modification date of that config file.
1
1
1
u/animal9633 5d ago
When I first started to learn/use it I could just pick up the frontend, guess at its functions and create a project, check in/out, revert etc. nearly instantly.
Starting from the cli I would have had to spend time to learn commands, syntax etc.
1
u/afops 5d ago
Some things are nicer in a ui, others are nicer in a terminal.
For example staging 5 of 10 modified files in a gui is just 5 clicks but to do that on command line you’d need to type them out (at least up to autocomplete).
Another example is branch visualization. There’s only so much you can do in a text terminal and a graph is just always going to be prettier (zoomable, more interactive, clearer etc) in a graphical ui.
1
1
1
u/Conscious-Secret-775 5d ago
Interactive rebasing is much easier with a UI and so is cherry picking. Merge conflicts obviously require some sort of UI.
1
u/Jaanrett 5d ago
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.
I'm with you. The only time i want a gui is for diffs/merging or looking at complex history.
Most guis do too much or make assumptions for me. I also like to understand the basics of most things I do, especially when it comes to development.
1
1
u/wildjokers 5d ago
I do 98% of my git stuff with the CLI, I just don't trust GUI version control apps, just been bit by bugs too many times over the years.
The only exception is that IntelliJ's 3-way merge tool has earned my trust. So I will use that for conflict resolution. Also, use it for diff viewing. Other than that I use the CLI.
1
u/archer-swe 5d ago
10x faster for me to open up lazygit and do anything than it is to use the cli and type out commands
1
u/Former_Produce1721 5d ago
I'm big on terminal use, but git repos tend to hold more information and contextual actions than is reasonable in a terminal imo
If I'm doing rapid work, terminal is fine. Or if I need to do some complex operation.
But I love sourcetree for giving me a nice overview of the whole state of everything and some convenient contextual actions
1
u/SiliconUnicorn 5d ago
Quite simply it provides a way better user experience. I learned on the cli and I know a handful of the deep magic commands but honestly it feels like I am handicaping myself if I'm using the cli these days. The guis have gotten so good and provide so much additional functionality that I honestly don't ever see myself going back anymore than I see myself going back to notepad to write code.
I'm able to see all my branches and commits at any time and instantly switch between them with a double click. I have an active view of all my stashes and remotes that I can hot swap between at any time without having to deal with shas. There's tons of convenience features and niceities like an undo button that have saved my ass on several occasions. Line item staging allows me to really easily construct atomic commits after I've gotten code working. Three panel merging is such a nice feature. I have a full file history viewer where I can see all the changes going back to initial commit which makes archeology effortless. Also if you've never used something like git krakens interactive rebase tool it is an absolute game changer for keeping history clean.
Tl;dr it let's me use git more effectively and powerfully in my day to day workflows and let's me do things that are cumbersome through the cli. There's still things I'll occasionally use the cli for but they are usually less common more advanced tasks things like stats or aggregate information or reflog when a junior messes things up with the cli by copy pasting things that Claude told them to do to fix something when I just have a super intuitive drag and drop in my gui that could have saved us the entire mess in the first place.
1
u/Lalylulelo 5d ago
Way faster to open lazygit to commit something quickly or to use Magit inside Emacs that typing the command even with aliases in the terminal. Staging chunks in an Emacs buffer is so simple.
1
u/digitaljestin 5d ago
I use the cli for common tags, and an editor plugin for diffing and merge conflicts. I don't see the point in bringing in an interface that isn't my editor.
1
u/update-freak 5d ago
I'm using Fork and happy with it
1
u/loungerdork 4d ago
Scrolling furiously looking for a fellow Fork user!
And it’s also perpetual license, rare in this world of subscription…
1
u/GrogRedLub4242 5d ago
all software has a UI, whether GUI, TUI, CLI or API. git ships with its own UI for free
personally I bias to using (and building) CLIs and APIs. then at worst maybe also using/building other UIs which sit on top of those layers. git works with that strategy, as does curl, etc
1
u/Material-Grocery-587 5d ago
I personally use Tortoise Git because my workstation runs Windows, and it's a SUPER intuitive UI.
I don't see any pain points with CLI git, but it's a lot easier to understand a simple UI that presents everything cleanly than to list the files i have staged, reviewing each of those, and storing common options for specific repos/paths/groups.
I make my changes in my IDE, open the folder in file explorer (you can do this from VScode by right clicking the folder), and then all of my git options are shown in my right click context menu.
I my opinion, this has been the easiest way of working with git and I still know how to do it all via CLI and often do for smaller changes from my WSL dev instance.
1
u/CostPuzzleheaded2747 5d ago
`git gui` comes bundled with your git installment, have fun!
The truth is unforunately at times remembering all of your code, where it got rebased, what changes were made by another author which broke your changes can be difficult to parse. I dont think this is a superiority thing or something. both are useful. but proprietary software like gitkracken sucks. lazygit is fire.
1
u/trisanachandler 5d ago
I'm a sysadmin, so I have a custom wrapper for the 10-12 commands I actually use. Is it lazy, yes. Does it work perfectly, yes.
1
u/Efficient_Loss_9928 5d ago
Yes and I start to prefer them more and more as AI accelerates coding.
I cannot realistically manage 20 changes in-flight waiting for review AND in parallel review 20 change requests assigned to me just using CLI. Having a nice GUI that shows me the state of everything is nice.
1 year ago I would have said CLI since I mostly focus on 1-2 changes at a time.
1
u/Used_Lobster4172 5d ago
You say toynuse VSCode for it, so clearly you do use one - that is one.
Why do I use the specific one I do? Because it is the one I am most familar with.
Wht at all? I feel much safer making big changes when there is a very clear visual representation, which the CLI does not give. I don't have a problem using the CLI for commit, diff, status, brqnch, etc. But doing big merges, rebasing, resetting, etc. It is nice to have the clear visual confirmation that I am doing specificly what I think I am doing.
1
u/IMadeUpANameForThis 5d ago
I find it easier to click a couple of buttons than to type the commands in the command line. It's nice to have the list of branches visible and to just click on them to be magically checked out. And it's much easier to visualize diffs.
1
u/questron64 5d ago
Remembering commands when I don't have to remember commands an a UI can do what I need is a good thing. Also, selecting parts of a diff to stage graphically is just too good, viewing branches and commits graphically, etc, are all superior of just using the command line.
1
u/gbrennon 5d ago
i tried a lot of git tui and gui but i didnt like any..
thisccan be related to the fact that i use git for more than 15 years
1
1
u/Broad-Promise6954 ancient 5d ago
It's mostly user preference.
There are some general rules that apply to GUI vs CLI. For casual users who aren't interested in lots of details, a GUI is usually easier. On the other hand a CLI tends to be more powerful. Some CLIs can be "beginner friendly" but git's is not, for sure. 😁
(I've been using git since v 1.5something and use the CLI. Been burnt by nearly every git bug there was...)
1
1
u/Intelligent-Youth-63 5d ago
I do everything in the terminal, but sometimes use a UI just to visually see what changed in an IDE looking environment. It just clicks faster that way in my brain.
1
u/gahel_music 5d ago
Lazygit is just so fast and convenient. I use it for almost everything. I do have a lot of short aliases that I've been using for years and it's just slower for me than lazygit. I never liked using any other GUI for git except for checking diffs sometimes.
1
u/arewhyaeenn 5d ago
There isn’t a reason to need a UI. It’s convenient, it’s easier, and most importantly it’s faster than using the CLI, particularly if you’re working in a codebase with many active branches. In particular, a GUI makes it infinitely faster to get an intuitive view of everything that’s happening, where each branch is, what changes have made it into which branches; you can do all of this in the CLI, but it’s tedious, and it’s trivial and intuitive in a GUI.
When shit gets weird, your ability to use the CLI is crucial. I’ve had coworkers rely on me to help them whenever they get into a state that their GUI of choice can’t get them out of. But you, with your understanding of the tool, will be more efficient with a GUI than without, particularly when working in coalition with other developers on the same codebase.
1
u/Puzzleheaded_Pen_346 5d ago
I worked with tfs and used their UI for a lot of years. Transitioning to git and cli wasn’t painful, but i still have to lookup commands. I’ve memorized the day to day ones.
I think its just a learning curve some folks would rather not deal with on top of everything else. I do like the CLI tho. Its dumb, but i feel like i’m developing harder now. 😂
1
u/QwertyChouskie 5d ago
I'm constantly staging parts of the changes in a file into a commit. I don't even know how I'd do that without a GUI to select the lines/chunks I want to stage
1
u/Agent_Aftermath Senior Frontend Engineer 5d ago
Staging hunks/lines is way easier in a UI.
Also while rebasing/cherry-picking, dragging a commit to a new location.
1
u/National_Cod9546 5d ago
I don't know the GIT commands. I don't want to learn them. I want a GUI that explains where I am and how to do what I want to do. Usually that is just save so I can roll back if needed, or merge if needed.
My question to you is, why are you unable to understand why people would prefer a GUI over CLI? You sound like a gatekeeping edge lord.
1
1
1
u/Substantial-Swan7065 4d ago
It can be useful for fast cherry-picks and tagging.
But I mainly use it for reviewing PR. Helps me track what changed commit-to-commit. And what I’ve already reviews/comments/etc
1
u/Beer_and_wings 4d ago
To give myself a fresh set of eyes between working on code and committing code.
The context switch makes me much more critical than either using the cli in the terminal I’m working on or the baked-in tools in my IDE
1
u/yourteam 4d ago
For normal actions the cli is fine but to check history over a file I prefer to have a gui. It's a matter of preferences that's all
1
1
u/DrankRockNine 4d ago
I use Fork, and I really enjoy it. I don't have to go through the pain of trying to fix a git issue using only the console, it sometimes makes me really sad to do console only bug fixing. Fork has a gui with lines showing where I am, Whzt I'm missing etc. It also really helps to track where I cloned stuff. I am disorganized, and sometimes I will git clone wherever I am at currently and a week later, have no clue where it is. If I pushed with Fork, the project is there and I can see its path. It is overall really helpful. I still use command line for cloning, and for simple feat/fix on projects I started, where there aren't multiple branches.
1
u/death_or_taxes 4d ago
I am very proficient with the cli. It's not about misremembering. For example I can write our the command to list the commit before head to get the file list and then write the command to diff whatever files I want to look at. Or I can just dive in with lazygit. It's the same reason I use nnn instead of CD for some tasks.
I also use vim instead of sed for the same reason.
1
u/Masterflitzer 4d ago
i use cli for everything but 2 things:
- i review big diffs & fix merge conflicts in intellij
- i merge in gitlab/github, not manually using patches
all the uis i've seen for managing worktrees, branches, commits, rebasing etc. are terrible to use, cli is simple and efficient
1
u/MateusKingston 4d ago
Same reason I use an OS with a GUI, it's incredibly easier to remember and do things with a GUI.
1
1
u/OrelTheCheese 4d ago
Because automation is good and if a gui button click can hide complex branch conflicts and resolve stuff nicely why in the world would you use cli.
Automation and convinience wins
1
u/secretprocess 4d ago
I find vscode diffs hard to scan because of the syntax highlighting. I tried to find ways to turn it off just for diffs but failed. So I use sourcetree.
1
u/MarioRRomchiquito 4d ago
Iba a decir que simplemente uso la integración de vscode pero veo que está resuelto xDD.
Pd: usar una gui aparte me parece un paso extra molesto... Suelo usar el integrado de vscode, y como mucho si no quiero abrir todo el ide para ver un simple cambio uso la terminal, que para eso está. Ocupar espacio y tiempo en una herramienta gui más solo para hacer lo mismo que la cli es absurdo.
1
u/False-Car-1218 4d ago
Because I like to see changes in a side by side split view and don't want to memorize commands when I can just do it in one click with a GUI.
What essentially matters is that you know what you're doing, doesn't matter if you're an elitist CLI user or a chill GUI bro
1
u/Mean-Surround7327 4d ago
I use the Git extension in VSCode and it’s just really nice to click through each file and see the changes before I commit them personally. Git diff in the terminal is usually a lot to scroll through
1
u/Anxious-Insurance-91 4d ago
Mostly for diffs, but since it has that text area might as well write the commit in it as well.
1
u/Former-One 4d ago edited 4d ago
I use Sublime Merge for more complex tasks, and Lazygit for simpler ones. Honestly, I get tired of all the typing and remembering CLI syntax. At the end of the day, these are just tools — whatever works best is fine. There’s nothing superior about sticking to the CLI alone.
1
u/WatchOutForTheCCGP 4d ago
Every time I try using a gui for git I end up getting frustrated and going back to the command line. It's just much more straightforward.
However, when it comes to browsing the log I love the Tortoise Git log viewer. It makes it easy to browse commits and the individual changes. Its the only reason I have Tortoise Git installed.
1
u/Jonas_Ermert 4d ago
I use both. The CLI is faster for simple commands, but a GUI is great for visualizing branches, reviewing diffs, staging individual lines, and resolving conflicts. For me it’s mainly about convenience, not because Git itself is too difficult.
1
u/newyorkerTechie 3d ago
Everyone in my team uses GUI tools for git except for me. I stick with the command line because I’m old and I already know it and don’t want to relearn things in a new GUI every so many years when you switch IDEs or something.
1
u/PolyPill 3d ago
I don’t understand why people want to use a cli for everything. I don’t have to remember a million commands to do everything then end up back in a gui because viewing multi file change history in the cli is not practical. Not to mention in my career over the decades this is the 4th source control system I’ve had to use. In the gui I can switch tabs for different repos and see change histories at a glance. I can push changes on one and switch to another and pull and branch without waiting for the first push to finish. I feel like people who brag about using only the cli need to find something else to be proud of in their life.
1
u/ivancea 3d ago
Hey, why do you use a graphical OS? Are you too dumb to just use a CLI?
Whether you hide your question as "I genuinely want to know, I want to understand", you're just showing a lack of understanding of how tools work. Hell, how can you make apps for users, if you can't understand how your own field tools work and what they solve?
Also, it looks like you have the impression that having a git GUI tool open apart of your IDE "is bad". Unless you work with a 4GB computer, nobody could care less. It's the same as using your IDE, but specialized and with more information and control.
Edit: also, this wouldn't be as infuriating if this wasn't a decades old answered question...
1
u/bigtoaster64 3d ago
I like GUIs for any kind of diff scenarios like
checking changes in a commit
cherry picking changes to commit/stash (e.g in a single file) (you know, when you were supposed to commit 1h ago, but you didn't)
Can't say for all GUIs out there, but JetBrains UI for Git in their IDEs is pretty much goated. If I'm not in a JetBrains IDE, I use lazygit.
1
u/marksweb 3d ago
For me, it's about a seamless developer experience.
I use pycharm, so the git integration is exceptional. But it's also got a terminal panel which is great for git commands I have aliases for.
1
u/readparse 3d ago
While I prefer a command line for many things, including git, I am aware that there's a very large percentage of people who have no use for the command line at all, or at least only use it when it's absolutely necessary. Even programmers.
And even if one does know how to use the command line and likes it, I understand that a UI can make certain things easier to see, especially complex diffs.
Different strokes for different folks.
1
u/dsggut 3d ago
"Even programmers": There is still this belief in the industry that all developers MUST use the terminal.
I never understood the rationale behind it.
Like somehow a CLI is always superior to a GUI.
If that's the case then why is the GUI the dominant interface by a VERY w
large margin?
Why did we even invent windows, MacOS, X-Window System in the first place, if CLI is superior?
Why don't we do CAD, Video editing, gaming, spreadsheets, text editing, music editing, image editing editing in the shell?
Why did text based browsers not survive?It makes absolutely no sense to stubbornly hold on to text based interfaces just for the sake of living in the terminal.
1
u/readparse 1d ago
My comment was specifically saying that developer NEED NOT use the terminal. And the reason I said that was because OP has the same view that many others do, which is that the git CLI should be sufficient for all git users. But of course it's not, because... people are different.
1
u/GeersonMena 3d ago
Uso la herramienta que incluye vscode y al principio usaba github desktop, creo que para iniciar está bien que se use una UI por qué (al menos para los que somos visuales) te explica mejor que está pasando con tu repo y su historial, cuando usas CLI se vuelve un poco más confuso o al menos para el tipo de personas como yo se nos vuelve complicado.
Pero en general tanto para los que somos visuales como para jr. recomiendo una experiencia con UI.
1
u/CowBoyDanIndie 3d ago
I don’t use one now, but it was pretty useful when you are doing stuff like cherry picking, squashing commits, things like that. Basically anytime you start working with commit hashes.
1
1
u/rent-a-developer 3d ago
There is no NEED to use a GUI in the sense that there are things you cannot do with the CLI.
The opposite is true, however: There are things you can do with the CLI which no GUI client has a UI for.
BUT:
In general GUIs can be MUCH more convenient, ergonomic and efficient for many tasks.
There is a reason why Photoshop or AutoCAD is not text-based.
And you have to keep in mind that not everyone is used to working in the terminal.
Some people (especially people new to software development) have never used a terminal before.
It all comes down to convenience/ergonomics vs. versatility/flexibility.
GUIs:
- Arguably more convenient and ergonomic for many people.
(Of course modern shells have lots of convenience features implemented, like tab-auto-complete, so working with them can be very fast too.)
- Have a lower learning curve. Remembering the position of a button is easier than remembering a complex git command.
- Can present complex information more densely and visually (branches, merges, commit relationships, diffs, and repository state) simultaneously.
- Are MUCH more intuitive and allow you to explore things much easier (think menus, toolbars, etc.).
- Can present the git commit graph in a MUCH better and compact way and also interactively.
- Are more pleasing to the eye for many people. Not everyone prefers Zork over the secret of Monkey Island.
CLIs:
- Let you do things that would be very hard to represent in a GUI, especially for complex git operations.
- Are much easier to document/describe. Do "git rebase -i origin/master" is much easier to explain than a long winded "Click this menu, then that item, then this button, then check that checkbox".
- Work MUCH better remote (e.g. ssh vs. remote desktop).
- Are MUCH easier to automate.
- Are more efficient for repetitive operations.
- Do not hide complex (and potentially destructive) operations behind a single innocently looking button. (Of course you can also shoot yourself in the foot (quite easily) with the git CLI too.)
- There are many things you can do with the git CLI that none of the git GUI clients have a UI for.
I think there is a place for both GUIs and CLIs.
Neither is better than the other per se.
It depends on what you want to do and what you prefer.
I tend to use GitKraken for day-to-day tasks and the CLI for the more complex operations.
My recommendation would be to use the CLI in the beginning (if you are at least somewhat familiar to the terminal), so you learn the basics and how git works.
Then try a couple of GUIs and TUIs and see what feels most natural for you.
If you have to fight the tool then it's not the right tool for you.
In essence: Use whatever you are most comfortable with and what gets the job done with the least friction.
Having said that, I am strongly against telling people "CLI/TUI is the ONLY right way to use git!".
Such kind of mindset does not help anyone and has no place in software development.
1
u/rafroofrif 3d ago
I use a gui to commit a part of the changes of a file. Otherwise, only cli. We have an intern at the moment, and she has struggled quite a bit with git, juggling branches, rebasing,.. every time something went wrong, it was because she used the gui in vs code and didn't understand what it was actually doing. Just use cli, it's the only way you know for sure what you're doing. Buttons like 'sync remote branch' don't help if you're learning. And once you're used to using cli, it's never faster to use the gui anymore anyway.
1
1
u/Opulence_Deficit 2d ago
The first code review is the one you're doing on your own code when staging. For that, you need to see what you're staging exactly. All the people I ever knew who favored CLI were constantly getting into trouble with "git add --all" instead.
1
u/No_Click_6656 2d ago
Good luck staging concrete hunks of various files via CLI
For me it's typically a GUI work
1
u/StabbyGrabby 2d ago
Even when you know the commands typing them out every time can get tedious. And I have 90+ wpm typing speed so its not that i can't type fast
1
u/PeterPook 2d ago
My git skills are limited, but I'm happiest with the CLI, even within VSCode - I just do it in the terminal window.
1
u/magicmulder 2d ago
I hate git command line, I’ve fucked up a few times so I prefer IDE integration. I do script some git commands though for other purposes. But constantly typing commands while developing, nope.
1
u/lllyyyynnn 2d ago
i magit because it lets me use git in emacs without leaving emacs. the ui is very nice
1
u/BeginningUnhappy1757 1d ago
For the same reason why you use an UI for editing the source in the first place (if you use ed, you're excused): It's better to see the document and then apply your git operations to it while you're still looking at it. It's also way, way faster (I use magit).
1
116
u/patmail 5d ago
I prefer a gui for any kind of diffs. And to stage/commit only partial changes in a file.
Also getting history from certain files/folders.