[groundCode]

As someone pretty comfortable with got on the command line, what advantages would a GUI give me? I’m not trolling, it’s an honest question. Anyone with good got command line skills move to something like this and find it offers them a better workflow?

[cytzol]

I use a Git GUI, not because it's more efficient or because it enables better workflows, but it's more comfortable for me.

- When I'm browsing the history, I can scroll up and down the list of commits and see the diff of each one by clicking on it.

- When I'm cherry-picking a commit, I can just drag the commit onto the branch.

- When I'm modifying a branch or a remote, I can right-click on it and go to Delete or Rename.

- When I'm resetting to an old commit, I can right-click on it and go to Reset.

Basically, I like to refer to things by pointing to them, and interacting by clicking or dragging. All of those things I just mentioned are trivial using the command-line — with the exception of modifying a branch or remote, you just have to write the git subcommand and its arguments. But having a Git resource as a tangible "thing" on the end of my mouse cursor makes me feel more calm using Git. I want to reset to that commit. I want to delete this branch. I want to cherry-pick this commit onto that branch. I want to see the diff for this commit. I can't really describe it but I feel more "connected" interacting with a repository like this, than on the command-line where I have to run commands and use the output of previous commands in new commands.

[Seirdy]

I concede the point on mouseability/clicking-and-dragging, but I respectfully disagree with your other points on what GUIs offer.

Everything else you described is easily available via already-existing CLI wrappers for git. I described my workflow in another comment[0] here. It is incredibly easy to search for specific commits and branches with instant live-previews using tools like forgit, and these tools are only possible because of the composability of command-line programs.

[0]: https://news.ycombinator.com/item?id=20516798

[apocalyptic0n3]

We've found that our repos get bad branches and bad merges far less often with them. For a long time, we had issues where a repo would have to be completely rebuilt (or replaced with all history lost) after a dev who thought he knew the Git CLI did a merge incorrectly or force pushed something. Detached HEAD branches locally and remotely, incompatible remote branches, inability to merge without conflict, etc. It was always strange issues that usually required we branch off a commit on develop from a few weeks earlier, merge a few weeks of changes in a single commit, drop every single remote branch, and push and merge back into develop. Was a mighty pain.

We noticed that this only ever happened with devs who (incorrectly) believed they knew the Git CLI and as a result, we instituted a GUI-only policy and preinstalled SourceTree on all computers. In the 2 or 3 years since we started the policy, we haven't had this issue even once. We occasionally have a complaint from a new hire, but after a week or so, they usually tell us that they prefer using a GUI after all. I wish we didn't have the policy, but it became necessary, unfortunately.

(for reference, we are a small-ish shop. Never had more than 15 devs at once. That makes such a policy more easily enforced and worked around. We're currently reevaluating using SourceTree as the default recommendation and Fork is one of the options we are considering)

[Morphion]

All your troubles would be solved if you simply locked down master and only allowed pull requests with limited merge options like fastforward and squash. I work at a small shop with 6 devs. We do this. No issues.

[apocalyptic0n3]

We did this at one point, but at the scale we work at (our GitLab has 671 projects, about 150 of which have been worked on in the last 4 months), that kind of lock down creates a major bottleneck for updating projects unfortunately. We had to disable it shortly after starting it because it was simply too much to manage with our current workforce. It's too much extra work for us compared to just saying "use a GUI", which has had a great success rate so far.

[rcxdude]

I have tended to use a gui to view the state of the repo (even gitk, which is bundled with git, is better than the CLI for this IMO), and the CLI to manipulate it. Inspecting the state of the repo through the CLI is mostly slower and less clear than through any GUI from my experience, except in the case of complex queries in a repo with a complicated branch structure (I at one point had a linux repo which had something like 7 different remotes for the purposes of tracking the differences between different branches of the kernel in embedded development. GUIs will struggle to show that tree sensibly)

[afarrell]

This is the reason I use the curses-based gui named tig.

I think it would be nice to have a UI where all input or manipulation of data was done through a CLI with autocomplete and a well-written tutorial, but which presented read-only graphics to represent the data model.

[piggybox]

Tig user +1, an amazing little tool. Yes, a few times I wish it could do more, but it's good as it is, as a git viewer.

[paol]

At the very minimum, having the local file status and recent history visible in a window at all times (i.e. a permanent 'git status', 'git log' and 'git diff' view) makes a GUI worthwhile. I can't even imagine working without that.

Another thing a GUI can be superior is operating on arbitrary subsets of files. E.g. imagine you have 100 new files and want to 'git add' an arbitrary subset of them; doing this in a GUI is far faster than the command line. (This is equivalent to shell vs. file manager - some operations are done more efficiently in the command line, some in a GUI.)

Then there's all sorts of niceties that a GUI can provide to speed up your work. E.g. git is very anal about what can be done if your local tree isn't clean, requiring often a stash-operation-unstash workflow. Smartgit (my weapon of choice, highly recommended) does it for me when required. More niceties I appreciate: reordering commits with a simple drag-and-drop; a diff/merge view to use during conflicts, or just to add a subset of file changes instead of whole files; jumping between repos with a single click. I'm probably forgetting a few.

TL;DR You can pry Smartgit from my cold dead hands.

[machiaweliczny]

Better code review than git diff, easy to commit only subset and faster way to view all changes in commits. I'm using GitUp and it's really good although not maintained anymore.

[pivo]

> I'm using GitUp and it's really good although not maintained anymore.

That's a shame, I didn't know that. GitUp is really nice.

[thomasjonas]

Are you sure it's not maintained anymore? There is still activity on the GitHub repository. Just no new versions?

[ChristianGeek]

There’s activity, but no new releases in a year and a pull request that’s been sitting for a year.

[whatever_dude]

To me it falls into that category of things that you don't know what you're missing until you use it.

A visual client just makes much much easier to visualize the state of a repo immediately, the relationship between branches, and individual changes over time. You see a commit from another branch in a list and you click on it; it's instantaneous and the diff is shown in a window. Doing the same on the command line takes a bunch of arcane commands and is extremely longer to execute.

Some things like interactive rebasing are also much easier (you can double check diff as you go, again with a click). Committing just hunks of a file is also much easier.

Some people are comfortable with the command line for everything and that's fine. But the reality is that certain actions are so cumbersome to execute via the command line that some people can never be bothered with them. In that case a GUI helps immensely.

[Bootwizard]

Basically, in GUIs the most common commands are represented in UI, and some combined into a single action. Also, visually viewing the entire tree (not sure the name for the entire branching structure) can be helpful to debugging and fixing issues caused by merging, accidental overwrites, etc.

The disadvantages are:

- cherry picking commits is not easy

- lacks advanced (read uncommon) commands

- sometimes git errors are encountered that can only be solved with command line anyways

It's also way easier to onboard junior engineers who haven't used version control before.

[Someone]

”cherry picking commits is not easy”

That always baffles me in git UIs. You have your list of branches on the left, list of commits in the current branch on the right (haven’t checked this client, but it likely has that), so why can’t I drag one of those commits on top of a branch to cherry-pick it?

Similarly, changing git commits shouldn’t need a separate dialog, and reordering commits could be done in-place by drag and drop (probably with a warning if done on commits that have been pushed). Yes, that’s less efficient and may occasionally lead to more or harder merge conflicts than doing complex rebase’s in one go, but it’s the GUI way.

[OJFord]

> visually viewing the entire tree [branching structure]

You can do that with git CLI no problem, it's one of my most used aliases (so I can't recall exactly the underlying command) - just flags to log. --pretty=oneline --all --decorate is the key bit iirc.

While I'm at it, my hands down most used alias is 'fixup', which takes a ref, commits with message 'fixup! <ref>' and rebases with whatever flag makes it turn that into 'fixup' instead of 'pick' automatically. i.e. it's commit --amend for older commits.

Recently I added fzsha and fzfile too, which use fzf to fuzzy find a SHA/file, and call the git command given as $1 with it and any other supplied args. So git fzfile add stages whatever I choose in fzf, and likewise git fzsha fixup amends a fuzzy-found commit.

These GUIs look pretty, but I've no desire to learn one when it inevitably misses some things I use frequently, and adds new features I don't have, sure, but no (quick, maybe it's open source and .. sure) way of adding my own.

[MayeulC]

The mnemonic is to do it like "a dog" [1], though I think some of these flags are now default.

The one option I really like is --first-parent. If you did merge commits for every new feature, and gave sensible names to those commits (instead of "Merge A into master", use "Merge awesome feature"), it really simplifies the git history and makes it easy to grasp the dev history.

Now, on command-line vs GUI, I think the contrary is actually true: once you know your way around some piece of software, small operations are easier using CLI. However, I really appreciate GUIs to set-up the most complex ones, or the fairly complex, but rarely used ones. And of course, GUIs tend to help you discover stuff while you're still learning the software, though git CLI does that pretty well too.

[1]: https://stackoverflow.com/questions/1057564/pretty-git-branc...

[xtracto]

I echo the other comment about easier selective commits. I have done that in the console and it's a pain. Nevertheless I have been using VSCode git features for that and it basically removed my need for a separate GUI program.

I used to use the one from atlassian, but they made it so difficult to use it, and also I think they started charging for it. I also downloaded kraken, but found it very heavy and intrusive.

Nothing beats using the terminal (except for selective commits)

[TheRealWatson]

I find GUIs easier for several tasks. These come to mind:

- Staging/unstaging/dropping hunks or specific lines within a modified file

- Interactive rebase is simpler and clearer

[ryanwinchester]

I use both command line and GUI as part of my workflow.

I use GUI mainly for doing "visual" stuff like looking at diffs, and commit and merge history (especially across branches), etc. In my opinion, this stuff is quicker and easier and looks better on a GUI.

I also use GUI if I have several changes and I only want to stage some of them (or partials). It's easy to go through and stage/unstage things on a good GUI.

For everything else I use the command line. Almost any time I want to actually DO something (like commit, push, pull, etc), I do this through command line.

[djeikyb]

i mostly use the git cli. i even like it; despite some ux problems! i've often been the one teaching git, and always make sure junior hires learn at least a little bit of git cli. but i do use a few extra interfaces.

1. complex staging operations. i do a lot of partial staging. staging by line or hunk is good enough most of the time. sometimes though i want a little more. maybe only part of a line, or parts of multiple lines. or even edit the staged content directly! i haven’t used eclipse in a few years, but its staging ui was great. side by side diff, working tree on one side, stage on the other. like resolving a merge conflict. full syntax highlighting, both sides editable. i haven’t found another tool like it. even primitive staging tools (like fork, tower, and tig) that don't do anything fancier than `git add -p` tend to be more useful to me, just because it's so quick to change your mind. no need to type out an unstage command then go through a bunch of screens. just drag and drop, or highlight and click.

2. studying history of a class or function. i use a jetbrains ide, and it makes it super easy to jump through the full history of a file. it's just git blame, but you don't have to copy and paste the ref to blame. very quickly you can see a bunch of versions all at once, and diff between them.

3. perusing git history. mostly, i use git-log and git-show. but sometimes, i want to see the git graph and quickly see the contents of individual nodes. a normal advanced scenario is, show me the full git graph, highlighting commits that touch a particular file, and let me quickly see the contents of those commits. i can do that with the cli, but it's way faster in other tools. if it's simple enough, i use tig right in my terminal. if my ide doesn't support the more complex cases, git-gui does.

4. interactive rebase. i don't know any tools where this doesn't suck. i'm rebasing against origin/master.. is it towards the top or towards the bottom? what files are in the commits i'm manipulating? what are the contents of those files? why can't i jump around between them without starting a new rebase session? i think there's potential for radically different tooling around interactive rebase, especially inside an ide. i'm used to the git cli. i interactive rebase constantly without any trouble. but my team mates don't, and it's not cause they're stupid or lazy. i just got really interested and put a ton of effort into learning it.

[SOLAR_FIELDS]

I also use CLI like 95% of the time. Last one I can think of (above the ones you mention) is complex merge conflicts. The CLI makes it kind of hard to read and visualize what is going on. I’ve actually gotten so used to the Jetbrains GUI for resolving conflicts that even if the language isn’t supported in whatever I’m trying to resolve I’ll open it in a Jetbrains software to resolve it.

[xorcist]

Interactive staging (add -p) can be very useful with a GUI.

Otherwise I don't know. Command interfaces familiar to you are hard to beat.

[dmitriid]

To add to what others wrote.

Some GUIs are insanely good for tasks that may be complex through CLI.

GitUp, for instance, allows you to instantly rearrange, squash and split your commits (mostly through keyboard shortcuts). It also has unlimited undo/redo even for complex actions such as merges and rebases.

[rado]

Multiple repos visible at a glance