- 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.
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.
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)
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.
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.
That's a shame, I didn't know that. GitUp is really nice.
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.
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.
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.
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...
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.
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)
- Staging/unstaging/dropping hunks or specific lines within a modified file
- Interactive rebase is simpler and clearer
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.
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.
Otherwise I don't know. Command interfaces familiar to you are hard to beat.
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.