[ghayes]

My common advice is: bite the bullet and learn it. Specifically, delve deeper past the porcelain commands and understand what they do. Also, for a while I stopped using “git pull” and used “git fetch” and manually managed merges and branch tracking (a lot of “git reset —-hard origin/branch-name”). Once you get it, you will be a lot more productive. You’ll still have to deal with obtuse commands from time to time, but you’ll have a better model of what they should do and can check if they are doing it right.

[rectang]

The Git command line interface is confusing, but Git's data structure design — a content addressable store — is relatively simple (and very interesting!).

I went through the book Pro Git three times leading three different training groups, and I was pretty comfortable with it. But what took me to the next level was prepping a talk for Papers We Love San Diego which explores everything that happens inside the `.git` directory when you initialize a repo and perform a couple basic commits: https://www.youtube.com/watch?v=fHSZz_Mx-Uo

[magicalhippo]

I guess part of the issue. I just don't interact with git enough that it matters much.

I might spend half an hour every now and then trying to figure out right incantation for this specific issue, but overall SourceTree just tells git what it needs to hear and I can carry on with what I really want: code.

[ghayes]

Sure, but I might argue that you'll spend _even less time_, in aggregate, with more productivity if you understand the tool better. This is particularly useful when, for example, you're good at saving your peers time by properly rebasing and/or cherry-picking your commits.