“All you need is to watch the presentation”
Sufficient to learn git without a course.
Full comment
You don't need a course. All you need is to watch the presentation "Git For Ages 4 And Up" this video

208K views · Mar 25, 2013 · 1:39:43 · 8 HN recommenders · 8 mentions · discussed 2013–2023
A Linux.conf.au 2013 talk that explains git's internal model using a playful, toy-based approach. It presents git operations as operations on a graph of commits, aimed at people who find git confusing.
Why Hacker News points people here: HN repeatedly recommends it as the talk that finally makes git's data model click for beginners, despite its odd title.
“it's the one video that allowed me to fully grasp everything”HN comment, 2018
“All you need is to watch the presentation”
Sufficient to learn git without a course.
You don't need a course. All you need is to watch the presentation "Git For Ages 4 And Up" this video
“it's the one video that allowed me to fully grasp everything”
Explains git operations as operations on the DAG.
I think the main problem is that many developers don't think of Git as a DAG, so they don't really understand at a fundamental level what the operations are actually doing. Once you understand this, Git really does become simple. All you have to do is map each command to the actual operation on the DAG. This video really explains it quite well, it's the one video that allowed me to fully grasp everything: this video
“It is one of the best talks about git for beginners with an unfortunate title :D”
Helped the commenter understand the git graph.
This is very good explanation, but only explains what happens with the files, nothing about the graph what is a git repository. This talk helped me tremendously to finally understand what's going on in git: this video It is one of the best talks about git for beginners with an unfortunate title :D Also, this interactive visual tool helped me to understand branching: link
“I always recommend getting started with git with”
Recommended starting point for learning git.
I always recommend getting started with git with "Git For Ages 4 And Up" by Michael G. Shwern: this video
“The git model can be, to a sufficient degree of completeness, be demonstrated with child toys”
Demonstrates git's model with child toys.
> "I've really tried to 'get into' mercurial's mindset several times now, but never could, whereas, IMO, git's model is simple and powerful. " > > I find it hard to understand what this means The git model can be, to a sufficient degree of completeness, be demonstrated with child toys: this video I can't even imagine how a similar demonstration would look like with Mercurial. It would probably involve having a bunch of such trees on the table, and super-glue instead of sticking things together.
“it made a lot things clear that I just didn't understood before, like detached HEAD”
Clarifies git concepts like detached HEAD.
Just watched it, I have to agree, it made a lot things clear that I just didn't understood before, like detached HEAD. Here's the youtube link: this video
“beginner-oriented, teaches you how to model git's internal concepts, 90m video”
Beginner-oriented 90-minute talk modeling git's internal concepts.
Here's my standard recommendations: * Learn Git Branching (gentle introduction to git's UI, with a visualization of the DAG) [0] * Git for ages 4 and up (beginner-oriented, teaches you how to model git's internal concepts, 90m video) [1] * Git from the bottom-up (high-level overview of git's internal data structures) [2] * My Git Habits (sophisticated, you will have to study the man pages used to completely internalize the workflow) [3] [0]: link [1]: this video [2]: link [3]: link
“I particularly enjoyed this talk once I'd found it”
Helpful talk for learning git workflows like rebase.
This is a nice crash course / intro to the basics that you can play with at your own pace and with your own throwaway repos: link With that out of the way, if your bosses want to fire you a week after you've consistently and proactively been trying to learn workflows that are new to you in your new job, you'd actually be dodging a bullet. > I hate that I am always asking people for help You only need to do this for "tribal" knowledge, for which you should have (or start) an internal wiki. For the rest, you kinda have to plumb the depths of the public internet... > like today I asked for help to rebase my branch since I have never done it before Yeah, I still remember my first rebase very well, thinking I would just lose everything if it went wrong. I tried a bunch of things on a throwaway repo to figure out what exactly happens, which turned out to be very helpful. I particularly enjoyed this talk once I'd found it: this video > At my old job I was the guy that got things done, gathering requirements, designing and developing new features <...> did anyone else ever feel this way and if so how did you over come, did anyone get fired because they are incompetent? That is still your skill set, and not knowing something does not make you incompetent; though not wanting to learn new workflows and tribal knowledge does . I have always had pride in being a newbie to a new team - I get to learn another set of ways someone has thought about working through problems, and more often than