I guess this is because there are so many more exposed levels of git to learn. The introductory chapters in git books about all the "this is how a commit hash is computed" and "it's all about the content, not the filename" is good if you want to know whats going on on the lower levels, but for git newbies it's more confusing than helpful.
The git concepts you need to know that are non-obvious are:
- there is no special branch, "master" is just a default name
- there is no special "central" repository on a technical level
- all git commits have one or more parents, but they don't know what branch they're from (i.e. reverting a merge can be a pain)
- a git commit always represents an entire project tree, you can't version individual files like subversion does
Unless you're planning on spelunking into the plumbing commands (i.e. low level stuff exposed to shell commands), small parts of the porcellain commands (i.e. that the end user should use) is more then enough to work with git and understand the "how I need to work with git" flow:
The commands I use 95% of the time are:
- git init
- git add
- git commit (and git commit --amend when I didn't pay attention)
- git rm
- git checkout
- git branch
- git pull
- git push
and most without any commandline options. These command invocations you should be able to learn within 4 hours, especially if you've used an SCM before. (and the git <command> --help pages are actually well written, once you know what you want to do).
Sure it's nice to know about git add --patch, or git rebase --interactive, but do you really need them to work well with git? I don't think so. If you're inclined to learn more about your tools, sure, go ahead. But thats something that comes with years of use and doesn't have to happen up front.
I find that knowing how it works is the only way the commands and flags make any sense. I am constantly seeing people around me fumble through git trying to get by on a handful of commands they've memorized and just live with the fact that they need to re-clone their repo every now and then.
These people scare me. How can they be comfortable not even knowing what they are telling git to do?
I taught myself how the DAG worked, then the low level commands to manipulate it. Now when I read the docs I get nice surprises like pre-built commands for doing the series of operations I plotted out in my head (most recently 'git merge --no-commit' instead of read-tree, update-index, write-tree)...
Oh god, I've become that guy in college who refuses to use a CRC library until he understands the proof.
But seriously, I'm genuinely amazed people can use git at all without understanding it completely. The mnemonics make zero sense without background, and the operations are completely arbitrary looking.
I'm genuinely amazed people can use git at all without understanding it completely. The mnemonics make zero sense without background, and the operations are completely arbitrary looking.
Remember, most things people use every day without understanding them completely. This is a huge barrier to entry and effective use of git; you can't require people to spend weeks learning it before they commit a single line of code. So yes, people learn sets of runes that work, and know that if you step off the path there's no easy way of working out what happened let alone undoing it without blowing away the local copy and going back to the master.
> [...] you can't require people to spend weeks learning it before they commit a single line of code.
But you can expect them to spend two hours to understand the little number of
fundamental objects that git works with, and maybe another quarter for basic
operations (fetch, push, merge).
The thing is, a lot of git commands are really, really subtle. And almost all of them don't do what you usually want without a couple of switches.
Personally, I'm more of a fan of darcs. It has a really good UI - defaulting to interactive use where it shows you what you're actually doing - and instead of branches you just clone into another folder, reducing a lot of cognitive load around them. It integrates with email as a primary use case - if you have a mailing list and an email client, you have a pretty good replacement for github pull requests.
I only delete everything and start again if I have made the mistake of making any changes to some source code. After a while you learn not to change things.
Lots of projects using git means that I get to spend more time doing things other than coding.
My top git commands from the commandline history are git status, git commit -a, git diff, git gui, gitk --all. There are a few git pull/pushes in there, but these 5 dominate. I hardly ever use git add, and over the years I've pretty much stopped using the index altogether. The GUI tools are my way of doing the fancy stuff. They work great and expose a lot of the more complex features without having to remember all the command line options.
That is the chicken-and-egg problem with git: to understand it well, you need to understand the lower level algorithms, because this is how git was developed in the first place. But most people will complain that it is hard to learn this low level interface, so they will always get stuck when understanding the high level operations.
It is in a sense the same with C programming. C is extremely easy to understand if you have a good grasp of machine architecture and assembly language. Everything makes sense. But if you look at it from the point of view of a high level language, you will always be amazed at why it does things in that particular way.
