4 ms·
I think the reason you're disagreeing is that you're not looking at this from a beginner's point of view. Generally there are (roughly) three approaches depend
by pluma 10y ago
I think the reason you're disagreeing is that you're not looking at this from a beginner's point of view.
Generally there are (roughly) three approaches depending on where you are in your journey from beginner to expert:
As a beginner, you need specific, detailed, step-by-step instructions: First run X, then run Y, finally run Z, if something goes wrong along the way, follow these other steps, if that doesn't work, ask someone for help.
Once you've moved beyond being a beginner, you understand how the different steps are connected, so you already know the intermediate steps and just need to be told the task at hand: do an X (e.g. "move these commits onto the other branch").
An expert fully understands all the inner workings and just needs to be told the big picture: this is what I have, that is what I want, make it happen.
If you try to instruct experts like beginners, they will be frustrated because it seems so tedious and you're not giving them the information they want: what you're trying to do. If you try to instruct beginners like experts, they will be horribly confused because they don't know how to make any of it happen without you laying out each individual step they need to follow.
A case can be made that a beginner should learn each individual operation by heart before moving on to the next one (like kata in martial arts) but this style of learning assumes you're willing to spend a lifetime perfecting a single art. It's unlikely git will stick around that long and for most of its users git is just a tiny (though important) aspect of their work.
- majewsky 10y ago"A lifetime" is massively exaggerated. I would argue that I know the majority of intricacies of every git command, and I've spent much less than a lifetime on this (about 2 years in reality, alongside other things, of course). > As a beginner, you need specific, detailed, step-by-step instructions: First run X, then run Y, finally run Z, if something goes wrong along the way, follow these other steps, if that doesn't work, ask someone for help. That's one way to do it, but it's not preferable. I would rather sit the beginner down for at least an hour and go through the basic concepts with them. I've taught Git to a few people (mostly fellow students or colleagues) and I found that they have a much easier time when they are introduced early on to the basic concepts of Git (the commit graph, and branches/tags as pointers into the graph), they have a much easier time grasping relevant tasks like merge and rebase. For specific questions (mostly in these "I screw up" moments), a whiteboard is also really helpful to explain them how the two or three magic commands that I tell them are actually fixing things up.