Not alone, certainly, but almost certainly in the minority. I don't think I've met anyone in person (in five professional years, granted) who uses a GUI for anything Git-related except complex merges or history visualization, both on rare occasion.

Not sure why your perfectly reasonable question is getting downvoted...

I have some colleagues which use GitExtensions exclusively (they are Windows users who think CLIs are a thing of the 80s), and they have a hard time understanding Git operations because of it.

i mostly use the cli, but i use a gui (git-cola) for interactively committing only part of the current diff. it's way better than git add --interactive. also gitk is nicer than tig, though tig is easier to use when sshed into another server.

Incremental (interactive) commits are probably best done from within your editor. I use fugitive [1] for Vim, there's magit [2] for Emacs, and probably a plugin for your favorite IDE, or ST2.

[1] https://github.com/tpope/vim-fugitive/tpope/vim-fugitive

[2] http://www.emacswiki.org/emacs/Magit

what does fugitive do for interactive commits that beats git-cola? i love vim for single-file things, but once it comes to a global project view i usually prefer to use another tool.

I have never use git-cola, so I can't compare, but for an overview of fugitive's features, you should probably look into the Vimcasts on that subject. There's overall five videos, this one is the first:

http://vimcasts.org/episodes/fugitive-vim---a-complement-to-...

I'll throw in my vote for CLI git. It's much better with the bash-autocompletion additions (many people I run across don't even know this exists) and a tweaked PS1 to show status as I hop around.

But my main reason is that I haven't used a GUI yet that doesn't a) take more time to do basics (aliases are great), b) bog down on projects with lots of files or lots of history, and / or c) lack some feature I rely on (good rebase and / or cherry-pick and / or reflog support is usually lacking). I'm also pretty comfortable with my workflow, so there's a fairly large step backwards to try something else, but it has definitely taken longer to get to this point than with most GUIs.

And in general I continually have to resort to the CLI for something, git related or make/rake/script related, so I just stay there. I'd love to switch to a good GUI, since they're generally far better at displaying information, but I haven't found one I'm happy with yet.

I use the CLI for everything except merges and glancing at history of a particular file. For merges I use opendiff (simple merges I'll just drop into vim and do it quickly by hand) and history/diffs between versions I use SourceTree.

Honestly, the GUIs are more confusing to me than using the CLI. Git does a pretty good job at pushing the user in the right direction.

I use gitextensions as well, and could never imagine using CLI. I don't have the patience to type out filenames or read ugly diffs through the console just for the sake of using CLI. On top of that, I'm an extremely slow typer so CLI is almost always a hinderance.

Staging a handful of files for commit in CLI takes maybe 30 or 40 seconds for me, where with gitextensions it takes a handful of clicks, not to mention I can read the changes I made to the file as I stage, which is useful for commit comments.

I don't have the patience to use a GUI.

The CLI autocompletes git commands, filenames, remotes, branches, tags, anything you can think of simply by pressing tab once. Just press tab twice to see all options for the context, for example list all tags matching a prefix entered.

Staging a handful of files literally takes me a few seconds on the CLI. I constantly use interactive rebase, stash, amends. I could never imagine using a GUI for this.

I also use the cli heavily for the reasons you've listed. I also use vim as my primary editor so the prompt is only a ctrl+z or :sh away.

What I find especially powerful is when reviewing files in the commit window you can stage and commit subsection of files.

It allows you to really quickly separate out different change into unique commits and gets rid of the need to make messy I-did-A-and-then-did-B commits.

Select the lines you want in the commit window -> Right Click -> Stage Lines.

You can also revert selected lines, but for some reason it's grayed out half the time... I'm not sure what black magic controls that feature.

You can do all of that in the CLI but it's a lot more clunky and time consuming.

`git add -p` splits your changes into logical chunks and lets you choose whether to stage each on.

It also lets you edit them (press e on a hunk)! I love that command. And it was clearly inspired by "darcs record". I also use commit-patch[1] quite a lot, it comes with Emacs integration which makes it heavenly (vc-diff then edit the patch to your liking, then commit).

[1] http://porkrind.org/commit-patch/

I use magit (popular emacs interface) for my day to day git work. I only hit the commandline for things like the ones I've spoken about in the parent article.

The opposite is true for me. I use git/hg UIs almost exclusively for visualizing the repository history, but find that they are too cumbersome for modifying the repository. If you need any non-standard options, they're generally faster to type (especially if you have decent command line completion), and standard commands I have aliased so that they are usually faster, too (if they aren't already fast to type).

I use the CLI for almost everything. The only time I use a GUI client is for complex stuff like cherry-pick or fixing conflicts.

What do you find is complex about cherry-picks?

From my experience, developers who rely on visual interfaces don't understand Git as well as developers who mostly use CLI. When relying on visual interfaces, at some point Git stops being the powerful tool it is.

You shouldnt generalize. I understand GIT very well and can (and for complex operations beyond the UI) use the CLI. However I generally use UIs because i simply prefer it. I see no need to use the cli for basic commits,pushes and pulls when neither is inherently superior..

I know this sounds very condescending and even a little elitist, but usually when people say "I am proficient with a CLI but prefer a GUI" I hear "I have memorised a few commands but I don't understand them, so I prefer a GUI". The reason being that I have genuinely never found a GUI for an application which is simpler or easier to use than a CLI.

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?

All right, I'll bite, I think it was a little condescending. I consider myself pretty proficient with Git, with maybe above average understanding of the internals and the porcelain. I use the command line for most git operations, but have ended up using `git gui` for a lot of simple and complicated commits, which almost always end up using `add --patch`. My workflow is something like:

  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.

Thanks for the explanations. After reading my comment again I realise that I sounded like a typical Git elitist - sorry about that.

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.

You're right, it does. I know where you coming from because i see it often myself, but you should never make assumptions about people because there's always exceptions.

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?

There is a correlation.

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

I use both CLI (when I'm on-server) and GUI (SourceTree on my Mac, TortoiseGit on my Windows PCs). I find the GUI better for most things for me, especially since it forces me into a review workflow before I commit and push much more than the command line tools.

Git Users Survey 2012 might give some indication: http://bit.ly/ZdRDxX

Questions 10-15 are relevant and show a quite wide variety of different tools people use. GUI's seem to be popular too.

I use CLI everything whenever I can simply b/c I can script anything moderately complex or more, back my scripts up to github or whatever, and never forget (or have to exactly remember) them.

I find that more valuable and useful than most CLI tools, although in their defense I haven't used one in years so maybe they're equal or better by now.

git-sh is clutch too - you can still run normal shell commands or full git cli commands, or you can drop the 'git' from git commands.

I use cli for everything but the occasional history inspection, for which I just use gitk. I have just recently started trying out p4merge as a mergetool.

SourceTree for OS X is great: http://www.sourcetreeapp.com/

Also available for Windows these days.

I use both. Most documentation for different operations is on CLI, but JetBrains IDE's for example have very powerful Git tools like in-editor git-blame, auto-adding files, resolving merge conflicts, and opening lines of code on GitHub.

I use gitk and tig from cygwin, osx (on osx actually GitX) and linux. But mainly the command-line.

Tried TortoiseGit, GitHub app and SourceTree - but use them rarely. Mostly if I want to get a good overview, they are bit easier to get into.

I use the CLI for batch operations on multiple repos/branches and some complex operations (history rewrites/repo maint) but for general everyday single repo use i typically use tortoiseGit or GitExtensions

I use the git CLI for most work; "git gui" for reviewing changes between writing them and committing them, especially for committing partial changes. Almost nothing else.

I use the CLI exclusively and rely heavily on the interactive commands: git add -p, git reset -p, git checkout -p.

People use a GUI for git?

i've only used the CLI on Win for features TortoiseGit was missing, though its SVN-ancestry has a lot of terms-clash with the actual Git commands issued under the UI.

I just ignore the flags that I don't need.