Shameless plug, I'm the author of Git Evangelism. This is the guide I built to onboard my coworkers during our transition to Git. This guide is updated regularl

Shameless plug, I'm the author of Git Evangelism. This is the guide I built to onboard my coworkers during our transition to Git. This guide is updated regularly and differentiates itself by putting the reader in a position to succeed during their first attempt at Git by providing sane defaults (which Git does remarkably poorly) like setting Sublime Text as the text editor (instead of Vim) and configuring Beyond Compare as the diff tool and mergetool. GE gives a brief introduction to the commands to move you towards being productive early-on and orders the commands that the user is likely to encounter the need. https://github.com/ryanrodemoyer/git-evangelism https://github.com/ryanrodemoyer/git-evangelism I like Vim, but it's incredibly intimidating and frustrating that you get presented with Vim if all you want to do is experiment with merging. I'm going to stop myself here. I could go on a long rant about the awful system defaults. I have a series of screencasts planned, some recorded, that follow through Git Evangelism so that you, the reader, can use Git confidently and successfully while avoiding the bizarre error states that plague new and seasoned users alike. In addition, I have created a non-traditional in-person workshop event that helps new users build up their understanding of the Git data model and we go in detail on how that differs from a centralized source control system (ie. TFS VC). Git Evangelism is in some ways heavily influenced by the thinking forced by centralized version control systems. At my current job, we are moving away from Team Foundation Server Version Control (TFSVC/TFVC) and to Git hosted by TFS. There is much in that document that is specifically geared towards Windows/TFS background although I have planned to make non-Windows specific updates (personally, I'm a Mac user). The problem with most getting started guides for Git, is that they continue to put the reader in a position to fail rather than a position to succeed. Git has all kind of "gotchas" that guides skip over. A typical guide leads you through staging and committing and reverting but rarely does the guide explain the nuances such as difference between "git add ." and "git commit -a" or the value in using a tool like GitLab (besides that it's hipsterish) or what is a hard reset (hint, there's multiple meanings so it depends how it is used).