The best thing is the discoverability - you don't need to know about the -p flag, for instance, since it's handled by the UI. Same for many other useful git commands that are hard to remember - they are often a simple option on a right-click menu, or a checkbox when performing an operation.
If you write code day in day out you SHOULD be comfortable on the command-line. That's why I highlighted in the article that I need two tools to do my development: an editor and version control. You use these tools every day--EVERY day. There's no excuse for not knowing them intimately. They are the foundation for doing your job.
GUIs also aren't always available across platforms, either. For the most part, all the git CLI commands port from Mac, Linux and Windows (msysgit). Also, have you ever tried using a GUI when SSH'd into a remote server in a pinch? You can't. And you'll really wish you invested the time to learn those underlying CLI commands.
My experience has been in forcing developers to use guis to do commits. It significantly improved their commits because they would browse over the changeset, could commit only specific hunks, didn't accidentally include extra gunk like test files, and generally made better messages.
It is certainly the case that the cli tools give experts the most power. But that power doesn't need to be exercised by everyone, and not even by experts on every occasion.
I would much rather my developer's heads are full of things relevant to the problem being solved (which is what pays the bills) than intricacies of cli tools.
Whilst in the real world the other half do things like 'git commit -a' to make commits which likely picks up unwanted gunk. A gui does not require memorizing flags and makes everything plain.
Or maybe that's just me. I don't claim to be the sharpest tool in the box.
But anyway, you need have no fear that people won't get forced into using the command line eventually, just because they like git gui. Any time you want to do anything remotely complicated, you need to drop out of git gui and hit the command line. gitk, for all its ability to display the history in a useful format, is similarly limited (or designed for a specific purpose, if you prefer).
I really didn't get on with GitX, but I don't remember it being a great deal more than git gui and gitk, in the same app, with a fancy OS X-looking interface. So the same would probably apply.
I've used CVS, Subversion and Mercurial in the past and never needed or wanted a GUI, but with git, I don't even want to be bothered by all the inane commands and switches. I love git for all it does, but I despise the CLI because it simply is downright evil: inconsistent, incoherent, convoluted, allows you to shoot yourself in the foot in too many ways, terrible user messages, and so on.
The Unix CLI is far more dangerous than Git. Also, there not very much you can do really wrong if you regularly push to a remote repository, as long as you don't push with force.
And don't we all do backups anyway?
Sure, but that's not really an excuse for git to have such a confusing and possibly destructive command line. I'm not a GUI person at all, but the times I had to lookup 20 different ways that 'git reset' worked, or had to google what on earth the apparently random combination of words like refspec, remote, origin, branch and non-bare actually meaned have been enough to drive me to a GUI tool. Now I'm much happier and actually enjoy working with git. Obviously when you are only pulling and pushing from master, there's not much that can go wrong, but if that's all you do, Subversion would do the trick just as well. The CLI usability completely falls apart when you start rebasing, merging and cleaning up WIP commits.
A tool like Mercurial proves that DVCS systems do not have to have a confusing CLI, in all the years I've been using it, I've never felt compelled to use a GUI. Too bad the Mercurial back-end is so slow.
Not necessarily: the Unix CLI has more powerful ways to saw off your leg, but it won't saw off your leg by accident, it won't destroy your files because you passed a strange flag to `ls`.
Needing to use git now and then while SSH'd in is not a good reason to make your entire development process slower and more error-prone. I would also say that there is a larger problem with your process if you have the need to use git on "a remote server in a pinch".
It's kind of like learning to play a musical instrument. You absolutely must pay attention to the fundamentals as a beginner, but if you only ever work on the fundamentals you will never become a great musician.
Keyboard strokes are, by any definition, much faster than mouse pointing-and-clicking. I have yet to find a single GUI that gets stuff done faster than what I can achieve with a command line prompt.
Or how about firstly determining which old commit you would like to revert a single file to, then secondly doing the actual revert. I can just view the file's log at a glance, get the revision I want, right-click and select "Reset File to This Commit".
By the way, I love Vim. But your disdain for "pointing-and-clicking" sounds like so much machismo.
Other than that, I generally think that keyboard is a faster input, though an 80-character terminal window is often a poor choice for visual feedback. Termkit has some interesting ideas: http://acko.net/blog/on-termkit/
Once you're at the level of git add -p you can probably start thinking about using a GUI if that's your cup of tea.
It makes crafting commits a joy.
I can't count the number of times I've caught stuff that wasn't supposed to be committed.
Also, site isn't loading for me so maybe this is discussed, but I also like using it to not commit logging / debugging statements without removing or stashing them.
I can't remember the last time I used a naked commit; record has become part of my core workflow.
If you want to get Google's cached version of a webpage, just type
EDIT: 14 already, after an hour!
I tend to use it even for git just so I have a consistent interface no matter what project I'm working on.
I'm a big fan of "git gui". You can commit individual lines.
Nice. Too bad I'm on svn. Though I suppose you'd want to be really careful about not creating a commit that's broken, e.g. by overlooking a declaration. Can you easily check whether currently staged changes still compile and/or pass a test?
The argument of creating a broken commit is natural, but not very relevant IMO: after all, with svn and co, the risk of forgetting to commit a new file is pretty strong as well. If you care very much about having non-broken commit, the only reliable solution is a gateway that merge commits only after they pass a test suite.
Combined with `git add -p`, stg is easily the most useful git tool in my toolbox.
I use git add -p whenever I've made too many changes between commits. I like for my commits to be of a single topic if possible.
If I use git add -p to break up a commit into 10 separate chunks, and find out something is broken, it's not hard to find the commit that caused the issue (if the commits are topical and not mixed).
That's what this is for. And it works pretty well. Any other helper for this task would look pretty much the same -- the goal after all is to translate your local hacks into a clean commit.
Sounds like a bad idea to me.
What's the difference? When you're done staging your patch, you can then check out the staging area and run unit tests on it prior to promoting it to a commit. Doesn't compile? Tests fail? Restage as necessary.
git add -p
When I first learned git, I was told, 'You'll never have to comment out code again'. Keeping the barrier for commits low (along with git -p and git rebase -i) makes this a reality.
I really don't care a whit about your feature branch when your broken commits mean I can't bisect an issue.
I wrote a blog post about it here: http://pivotallabs.com/users/khicks/blog/articles/2116-git-a...
There's also git reset -p, which is also in the same realm as git add -e as far as how powerful/advanced it is, though perhaps more difficult to comprehend. I wrote a blog post on that one, too: http://pivotallabs.com/users/khicks/blog/articles/2114-git-r...
I guess you learn something new every day. I thought this was the only way people use git and I was actually surprised to find out it wasn't made the default.
In Mercurial, I would use an hg patch queue to hg qpop, qrefresh, then qpush.
While the idea of a "Time Machine" style history is probably quite desirable when working on your own, it's totally useless for practice of checking in self contained "features", having them reviewed and potentially rolling them back even after many other "features" have been added that you want to keep.
beats any gui imho, although tig is technically a gui.
for those that don't know it, compile:
and type 'S'
They also have a second, more advanced course on the site.
OK, perhaps you are on Windows, then i am not sure if it's that simple.
I'd been using git for a couple months on a project on my own with no problems. I felt comfortable with it. Then I got hired at a company using it.
I wasn't even remotely prepared for the difference (and for how little I actually knew about git: addressing commits, modifying commits to make them more clear to review, moving branches around, etc). I flailed for several weeks (coworkers were always happy to help, but I prefer to try to swim on my own) before the light bulb really went off (and I'm not new to VCS or DVCS, eitherm by any stretch of the imagination).
I don't think you can really learn git until you are working with a group of people, because its not until that point that its strengths and peculiarities really show up. Especially since the UI is so cryptic.
Fwiw, I was a big mercurial fan pre-hiring. I'm now very happy that BitBucket has a git interface (I prefer BB to Github for closed-source, personal projects) as, unless there is a requirement that history not be changed in the repo, I'll be using git moving forward.
"Oh, you're friend was 20 commits behind and did [some stupid] shit that wiped out all commits and GUI tools aren't helping? Here's how to attack it..." which is where my Git knowledge falls apart very quickly.
Regular commiting/pushing/remotes etc are all okay to me, except the bad habits of using "sync" as a commit message when I move from my desktop to my laptop and I don't have wip branch.
Peepcode screencasts are worth every penny.