can you elaborate on why you think git is hard?
Its commands are, conceptually, tools to perform operations on the repo, rather than tools to version your code.
reset -- file #unstage a file reset --hard #reset everything in the working directory
Later they might learn to use reset to undo the last commit.
reset --hard HEAD~1
But they probably still don't really understand what the reset command does. I consider it to be an overloaded command. There should be a command to unstage files, a command to move the HEAD of the current branch (which can keep the --hard and --soft options), and a command to just clear everything from the stage/working directory to start over.
Other commands are similarly overloaded which makes it hard for users to understand unless they learn the internals of git.
Each program is also effectively developed independently such that one does not operate the way another does. So there are several learning curves: the one to understand the framework, and the one to understand each program, and then the one to understand how each program inter-operates with others.
Some people "pick it up" without difficulty, but it's because those people don't have to swallow the entire operational knowledge at once. To really grok how anything works you have to learn it from the ground up, instead of task by task. Git is the most convoluted open source project I have ever encountered (from a user's perspective).
You can grasp in about an hour concepts like "index", "staging area" and other that the article mentions.
Also, git history is more like a DAG.
Also, about that 'grasping in about an hour': way too often, reading some more confuses the hell out of you again. Witness:
You can grasp in about an hour concepts like "index", "staging area" and other that the article mentions.
So, is there a difference between index and staging area? Google "git index vs staging area" gives me top hit http://stackoverflow.com/questions/12138207/is-the-git-stagi..., which does not help me.
Second hit is http://stackoverflow.com/questions/4084921/what-does-the-git.... Again, far from a clear answer.
Further googling/clicking gets me to http://stackoverflow.com/questions/6716355/why-staging-direc....
And no, the git-scm book at http://git-scm.com/documentation did not help _me_ either. It seems to have banned the use of 'index' as the (almost? More or less?) synonym for staging area.
I think a large part of complaints about git are caused by its confusing user interface and confusing terminology. Yes, terminology may have been cleaned up officially, but 'the Internet' is littered with remnants of its history.
Apart from that, one thing that I find confusing about the staging area is that it is invisible. Consequently, there doesn't seem to be a way to build what would get committed on as 'git commit' (do a 'git add X', then edit X. 'git commit' will commit the old content of X, but 'make' will use the edited content of X. Or am I confused again?)
I've never really thought of Git history as a tree. I just think of it as a linked list of commits, and that I have more than one list available (branches).