Have you tried spending some time learning how it works and reading through the manpages? In my experience, as long as you hold onto the cognition that a repos

Have you tried spending some time learning how it works and reading through the manpages? In my experience, as long as you hold onto the cognition that a repository is a collection of files and commits are, in effect, diffs, git won't ever really make sense, since none of what it does could be feasibly implemented with diffs. It's actually much simpler than that, hence the name. When I first started learning git, I had only experience with SVN and Perforce. Both typically led to egregious practices (branches are directories?) and actual merges were rare (rather, you manually merged and just made a new commit). I felt they were a huge hindrance and were actually constantly in my way, a sort of mandatory bookkeeping I had to maintain. When I started working for a company that heavily uses git, I buckled down and read through pro git (available at http://git-scm.com/book http://git-scm.com/book for free), the user guide (https://www.kernel.org/pub/software/scm/git/docs/user-manual.html https://www.kernel.org/pub/software/scm/git/docs/user-manual...), and the man pages of the commands I was using. One day it just clicked and all made sense, and it was the only logical solution to SCM. Now I can't live without git. In my personal projects, step #1 is to git init a new repo. In working, git is never in my way, and rather provides me with incredibly powerful tools for massively increasing my productivity through workflows that just aren't possible under SVN/P4.