5 ms·
I gave a git talk at work recently and what I found works was teach the graph from the beginning. This includes a lot of diagrams of what the graph looks like a
by allenu 8y ago
I gave a git talk at work recently and what I found works was teach the graph from the beginning. This includes a lot of diagrams of what the graph looks like as you commit and branch:
- show what happens as you add commits to a branch
- show that branches are just pointers to commits
- show what creating new branches looks like, i.e. creating a new pointer
- show what merging looks like (a new merge commit is added, or else fast-forward merge and that the branch pointer just moves)
- show what happens if you don't rebase (i.e. "ugly" non-linear graph) ... then teach what rebasing does (i.e. creates new nodes and moves the pointer)
I found that building up from the ground up and illustrating graphs allowed people to conceptualize things much better. There was still some confusion once merging was introduced (what happens to those earlier commits? do we need them?) and mostly because people hadn't thought of the graph before.
Git is one of those tools where you can totally do your job just by knowing the basic commands but not really know what is happening under the surface, which I think is a testament to the tool. But, that leads people to conceptualize their own idea of what is going on... and getting it wrong and being confused when they want to do something outside of their basic toolset.
- da_chicken 8y agoYeah, it was definitely a set of images [0] that made git click for me, but even those are not necessarily the best pictures to use. Git's mental model is basically: > Ok, what if we took our SVN repository and the first thing we did was check in an SVN repository to that. So now you check out the repository, and you get a complete local repository that you can do anything you want with! > So Pull/Push are the terms we use for the check out and commit of your local repository to the remote repository, and then Checkout/Commit works from your local repository just like you're used to with SVN. And the real magic is what they did by building a system on top of this model to let you merge changes all the way up while looking at the code like you'd expect you'd need to. The problem is that git's toolchain still feels arcane to use, and it requires that you have good working knowledge of the underlying models. It's confusing enough that you can't function unless you have that because you don't know where you are or where you're going. It's a fantastic tool, but it's like driving a car with two steering wheels, two gear shifters, and six pedals. Then you say to yourself, "How do I get to the market, buy some milk, and come right home?" and your brain starts to melt a little bit. You shouldn't need to know the nitty gritty of how git works internally just to get it to work right any more than you should need to know how a disk works in order use a file system, but over and over we keep seeing that knowing that is really the only way to use the tool correctly and that it takes quite awhile for people to get. [0]: https://blog.osteele.com/2008/05/my-git-workflow/ https://blog.osteele.com/2008/05/my-git-workflow/
- ramses0 8y agoI did this quite a while ago following your same teaching methodology. Feedback welcome! :-) http://www.robertames.com/blog.cgi/entries/git-in-two-ten-minutes.html http://www.robertames.com/blog.cgi/entries/git-in-two-ten-mi...