I'm just curious; you seem to imply that you find basic commands (add, commit, push, pull) easier to perform in a GUI than a CLI. Why is that? What is it about a CLI which isn't simple?
work on the code
use git gui instead of add --patch on the command line
use git stash -k on the command line
run tests suite
Git gui lets you pick individual lines much easier than `add --patch` does, and I find that wanting to have that available at my fingertips means I use it for non--patch adds too. Maybe this is an indication of some other "flaw" in my workflow where I'm generating a lot of changes that I don't want to commit yet, but I think it's common and inevitable when working on legacy code or in maintenance-mode. But even for new projects I use this because I'm usually cleaning up my work via --patch.Another nice alternative to `add --patch` is magit for Emacs which lets you select a region in a diff and add that. I find both of these (git gui and magit) to be much easier and faster to use than `add --patch` on the command line, which has a pretty clever interface given the limitations, but is really far from perfect (split often doesn't work with small hunks, which means you have to open it in an editor. which means Emacs, so I might as well just use magit)
I've tried to get colleagues to use a workflow like this, so they stop committing garbage like bad comments and logging.
In my experience and humble opinion, your generalization is often enough wrong that I would avoid it. I've met plenty of people who prefer GUIs for this or that task which they could script or shell circles around me. It really all boils down to taste and what you find to work for you. Git's command-line interface is badly enough designed that you shouldn't make anyone feel bad for using something different. (I say this as someone who loves Git very dearly)
That said, I DO believe that users who NEW to Git specifically should use the command line a bit while they are learning, since it helps with the vocabulary used everywhere to talk about Git, while some GUIs bury it behind a leaky abstraction.
I'll turn it around and ask why, for simple tasks, is the CLI any better than a GUI ignoring personal preferences?
For me, the main thing is speed: I can type much faster than I can navigate a cursor (tab completion helps). I recognise that some GUIs have keyboard shortcuts to speed things up, but then at some point you're using the keyboard enough to justify using a CLI. The other thing is that I don't find graphical representations of my changes helpful at all. I commit early, commit often, so the output of `git diff` generally doesn't need to be paginated. My feature branches are small so I can merge them without the need to see a commit/branch graph.
To be honest it's hard to answer that without ignoring personal preferences because really, that's all it boils down to.
I can definitely understand the want to use a GUI when you're doing complex adds or merges. spacemanaki is right in saying that doing this a lot probably indicates a problem with workflow, though.
Its not that the CLI isn't simple, it's that the GUI is just easier. From your post i think i can safely assume you sit in a CLI all day so it makes sense you would prefer to use it. I spend the majority of my day in windows & IDEs and while i always have a few bash cygwin shells handy its just easier to right click -> commit/push/pull/switch branch/fetch&rebase then to switch context and type it out. Oh and merging, I just find visual diff/merge tools nicer.
When i need to actually do anything complicated the CLI is where i go, but generally, i really don't need to.
I'll turn it around and ask why, for simple tasks, is the CLI any better than a GUI ignoring personal preferences?
To be able to use the CLI you need to be more comfy with git; but just because it's less intuitive doesn't imply it's a a more powerful tool. Just that the user-base has a higher git-familiarity floor