Code in the Browser with GitHub Classroom
github.blog
github.blog
This makes no sense. It all depends on the goals of the teaching. However, it's probably more meaningful for more people to be exposed to the capabilities of version control so they avoid creating one-off home grown solutions.
There was a time when the joke was that only teenagers knew how to set the time on the VCR.
(a) there’s definitely a route into learning how it works without getting confused. For example, use of analogy to explain the staging area and the commit process, then drawing on the analogy at the end of the process to reference the git jargon.
(b) I haven’t done the full research but I feel that there’s a good ecosystem of porcelain for git, even though the era of plumbing+porcelain is far behind us. I’d appreciate any hints in the right direction on this front. If your answer is “hg” then so be it hah.
- http://rogerdudler.github.io/git-guide/ - http://think-like-a-git.net/ - and https://www.sublimemerge.com/
Sublime merge is much better than most GUIs in that it doesn't try to paper over the git concepts. It's just a UI for executing the standard commands.
I think the key features of a CLI porcelain, other than simply renaming some commands (e.g. `git branch new` rather than `git checkout -b`) would be:
- Making staging optional. Committing with no staged files would be equivalent to `git commit -A`. If you do stage files, then it would only commit staged files.
- Auto-stashing. Such that you could switch between branches, and your in-progress changes would disappear and magically pop back when you switched back to that branch. It would be as if there was an additional "working commit" that was associated with a branch without actually being part of it.
- Make changes to branch A
- Checkout B (A changes are auto stashed)
- Make changes to B
- Checkout C (B changes are auto stashed)
- Checkout A again
As far as I know git stashes are FIFO, so it wouldn't be that easy to pop my stash for branch A at this point.
Stashes are kind of sort of like branches themselves [1], but they are usually seen as a list, from which you can (cherry-?) pick arbitrary stashes with the apply or pop command, just name it [2]
[1] https://stackoverflow.com/questions/18527171/how-does-stashi...
This is an aspect of the mechanism that I would like to change. That it isn't easy to pop your stashes once you have more than one going is precisely the problem! It'd probably need to be a separate kind of ref.
FWIW, `git branch newbranchname` does create a new branch. Run `git checkout newbranchname` after to switch to the newly created branch. Or run `git commit -b newbranchname` to do both at once.
The staging thing has to do with git's origin as being used for kernel development. Each patch is (ideally) meticulously constructed, and stands on its own. In order for that to be possible, git has the staging area in order to assemble pieces of a commit until it's perfect (aka `git add -i`). That large areas of software development doesn't have (and doesn't need) that level of attention to detail to each individual commit, is a function that most project don't look like Linux kernel development. For better or worse, Mercurial/hg does not have a staging area.
Unfortunately, I know git too well to reason if auto-stashing would help, rather than hurt (beginning) users. Personally I'll often commit my in-progress work (dumping plenty of mental state into the commit message to make it easier to pick up when I get back to it) and then then edit that WIP commit before submitting the PR. Your tools are there to support you, and one of git's strength is that it'll support pretty much any workflow due to all the low level plumbing available. Unfortunately, the cost of that flexibility it's learning curve.
Why?
Git is pretty fun. Learning that it's not magic but just references and pointers to different objects was very valuable.
Although I probably don't understand enough to implement efficient merging but I can make a simple git clone (I am currently trying).
Git is a good way to introduce kids about hashes and basic crypto stuff, graphs (DAG) and other data structures, collaboration, etc.
saying this as a 16 year old.
Probably a better way would be to start without git and to have a chance to experience the agony that that entails. Thus motivated, one can appreciate that the hours (!) it will take to get going with git are actually worth the price.
Or, alternatively, you may decide to just stop with the phase of
myprogram.js
myprogram.js.old
myprogram.js.broken
myprogram.js.20200515
myprogam.js.works
myprogram.js.test
myprogram.js.merge-with-ellen
and so on. Lots of programmers still do this.
That is indeed true. Only memorizing the git commands can get you going, but is often not enough. Eventually you'll mess something up and end up throwing more commands at it until you either fix it or give up and reclone the repo.
There are likely other sources available, but what helped me get a good understanding of how git works was Paolo Perotta's "How git works" Pluralsight course.
Disagree with you here. I think even elementary kids should be taught git and if done right, they'd be able to pick it up quickly.
I think books/manuals/references are the wrong way to teach git though. They should be shown how git works and shown what git is. Text material should be supplementary.
There are youtube videos that walks you through setting up repos, cloning, adding to staging, committing, pulling/pushing, etc. Also, youtube videos that explain the internal structure of git and its objects.
Being shown what a repo, head, master/branches, cloning, etc are and having these ideas explained is far better than being given a sheet of paper with a list of commands/instructions to clone, push/pull, commit, etc. Which sadly is what a lot of incompetent and lazy teachers do.
But, if do need to learn git, it's not hard at all.
The problem is that most people teaching git suck at it.
Git has been poorly explained since the begining of time, and because it has a terrible UI, plenty of gotchas and untold prerequisite, you can't really fiddle with it and learn it by yourself without putting a lot of efforts.
It's a shame, because it really is a simple system to use... provided you understand it, which a lot of teachers don't.
Important points:
- git log and checkout must be explained in details, as they are a huge source of confusion.
- don't use the famous graphs with revert arrows, they confuse the heck of students
- explain push/pull/clone as late as you can. Most of the course should be on a local repo.
- help them setup diff tools for their particular env. It's harder than you think given the diversity of them.
- you will often have to explain ssh and key management as well. It's not git, but git is close to useless without it. For windows users, you may have to spend an hour of terminal tutorial, putty or not. Use cmder or windows terminal, not cmd.exe.
- do give them a cheat sheet, but only incrementally once they understand the concepts behind them, otherwise they will copy/paste blindly.
- teach them to have a clean working copy before some key operations, and show them why.
- make a big final exercice where they all work on the same code base and push/pull/merge from each others. Twice. Once where you help them. Once to check they can do it now without your help.
- rebase, squash and cherry pick are optional. Do them only if you have plenty of time at the end, and that the rest is well understood.
I tried to delete Main.java, and it won't let you. Fine, so I just erase the whole text file. Then, I place two separate folders w/ src code in them. Code compiles fine, but still prints out "Hello, world!".
Buggy. If you use Main.java, you can still have several packages and it all works, but I don't like that. What I might do is erase Main.java, then you're forced to manually run your program from their bash shell ($ java MyClass). And then it works fine.
I also don't like they're on openJDK 11. All the nice stuff is in 12-14 (text blocks, switch expressions).
However, we do have some configuration hooks -- the run command is bound to an entrypoint (in this case Main.java). If you want to configure it, you can do so: https://docs.repl.it/repls/dot-replit
Finally, we're a bit conservative with language versions but will probably upgrade Java soon :)
$Git needs a generational ux improvement to see it in early education but I'm interested to see what (if any) pro education/developer tools trickle down that far.
Stop wasting your students time and learn literally anything else.