Better yet, don't. Just use something decent like fossil or mercurial.
How to teach Git
41–50 of 273 posts
Re: How to teach Git
#42I found this very helpful: http://eagain.net/articles/git-for-computer-scientists/ . Git's data structures are well designed. Once you have internalized them, you will be better equipped to navigate through the jungle of command-line options. To understand the data structures interactively, use "git cat-file -p HEAD" and continue drilling down to an individual file in a subdirectory with "git cat-file -p OBJECTHASH "
I've never had to understand the internals of a web browser or text editor in order to use it; drivers ed courses don't start with a discussion of thermodynamics. Why should it be necessary for git?
Because every source management tool has a model, and to use it at all you need to know the model. Else you're jabbing buttons and turning dials on a complex machine and the outcome is going to be tragic.
Re: How to teach Git
#43I contribute to git, if anyone's got any UI warts they're bothered by in particular I'd love to hear about them. Maybe it's something we can fix.
Re: How to teach Git
#44I contribute to git, if anyone's got any UI warts they're bothered by in particular I'd love to hear about them. Maybe it's something we can fix.
LFS works by installing hooks. This prevents me from adding my own. Also the one-hook-only policy makes it harder to share hooks.
Re: How to teach Git
#45For anyone looking for resources on teaching git I'd recommend the software carpentries - all open source with a great community behind it. http://swcarpentry.github.io/git-novice/
Re: How to teach Git
#46Years ago, I tried to teach git to my (college) students, and it was a complete disaster. Like a lot of technical things, it's easy to get them totally confused with a single off-the-cuff sentence (and to be honest, I think I underestimated how difficult it would be to explain it and the kinds of pain points they'd encounter).
Reading this article, it occurs to me how useful the idea of a "staging area" would be to helping them understand. I don't think of it that way myself when I'm working with it (I suppose I do, but not in those precise terms). But looking back, that's what was tripping them up. If you're just talking about local and remote repositories, you're not really giving them the right idea of the workflow.
Re: How to teach Git
#47Here is my personal recommendation for getting more comfortable with git. Use "git status" a lot. Everytime you do something in git, and before you do something, do a "git status" and see what you change with your commands. And what you didn't change. Also "git log".
`git log` on its own (with no flags) isn't that useful, as it's missing a lot of important information. I prefer `git config --global alias.lg "log --color --graph --oneline --decorate"`. Then you can just type `git lg` and get a much more useful overview of the state of your current branch.
Re: How to teach Git
#48Having taught git several times within a data science course I find two concepts especially worth extra time: WHY there is a staging area, and what is the difference between “git” and “github”.
> WHY there is a staging area I understand your second point, but I have a hard time understanding the difficulty with this part. Why is it hard for people to understand the idea of staging? You put things in a box one at a time before closing the box. Does it require more explanation than that? What do people find difficult about it?
My hurdle was 15-20yrs of no staging area from previous VCSes so the extra step took some time to understand why it was needed.
Re: How to teach Git
#49The best way to learn git is to learn what's happening at the DAG level. That way you can think about what should happen on the DAG and then think of how you can use git to achieve that. For example, a fast-forward merge and a reset can be used to achieve the same thing. It's also very important to learn to use the reflog. When I was learning to climb they told me I'd never get really good until I'd fallen once. The…
I learned that Git stores data as DAG at the very beginning when introduced to it. But I came to get clicked until I realized that it is not only a DAG but an immutable one. That is, existing nodes of the DAG are never changed once created. The only operation supported by the system is more or less: create. Also, using the plumbings to peek into the content of the objects and refs inside the .git helps a lot as well.
Re: How to teach Git
#50Git itself is so simple, it's all the stuff around it that can be overwhelming. Social mores about all the possible workflows are maybe the biggest (rebasing vs merging, granularity of branches and their longevity, acceptance of partial commits reflecting a state never realized in isolation on disk, commit hooks, requirement of every commit to satisfy properties x,y,z, direct access to common parent repo copy vs requiring some sort of pull request flow (and dependence on github and all their stuff)) but there's also work tracking, code review, build automation, test automation, deploy automation...