When I was teaching at General Assembly, I pushed to us to use Github for all of our assignments, workflow, etc. Homework turn-ins were pull requests, feedback was given via comments per-line that any instructor (or student) could make, etc.
The process to get students fluid at the basic flow took a few days, but after a while it was great and I couldn't imagine doing it any other way. Any programming course using this is obvious, but I'd even do it for non-programming things if I could get the student trained on it in a minimal amount of time.
The only roadblocks with git are that there's so many basic ways to screw up, which are hard to fix. Let's say a student does a `git init` in their `~/code` folder that holds all of their git projects... and then makes a bunch of commits, and then can't figure out why they can't push to github. I wish there were some better failsafes to prevent such things, but they happened by accident once a week at least.
In fact, the blog post doesn't include all the details, but some of the educators we interviewed were not from CS. You can see a table describing all the participants in our research paper (the link is provided at the end of the blog post).
Just like you, I believe it is completely possible to use this for non CS classes, and still gain all the benefits. However, like you said, there should be a basic understanding of Git.
One of the hardest things to overcome (even in a programming class) is the why of doing things in Git. Many of the things we do seem arbitrary to students who are just learning. Why do you make multiple commits? Why use branches if you're the only one using it? Why make decent commit messages? I just want to turn in my work!
Many of git's capabilities seem esoteric to students, and for someone just starting indeed they are (students aren't managing a huge FOSS project, just their homework).
Maybe you don't need to do some of those things for assignments? They are all intended as aids in maintaining a long-running software project with many contributors, which is a very different use case than personal homework.
Oh very very true. They start becoming more useful for group projects.
We taught what what needed, but students (in learning to be self resourceful) will often google things, try tutorials, read on stack overflow, etc... and sometimes get themselves turned around. Git is a big piece of software to understand completely I guess, and even if you only show someone a small bit, they are likely to get confused at some point when they are trying to go deeper.
As an interesting and certainly unintentional thing, we discovered at one point that the words git uses to describe commands are often daunting to students. Commit and blame in particular. At one point we found many students weren't making enough commits, or sometimes none and were reluctant to turn in their homework. Through meeting in some 1:1's, we discovered that some of the students felt that if their work wasn't perfect, they didn't want to "commit" to it and that the word held too much power seemingly- they thought maybe there was something deeper to it.
This probably sounds silly, but when teaching people who are new to programming there are all sorts of preconceived notions that can really hold people back, and this was one of them.
That doesn't sound silly at all. In fact what sounds silly is taking techniques designed for large professional software projects and applying them to things that aren't anything of the sort.
It reminds me of the problem with teaching Java as a first language – you must start with `public class Foo` in a file called `Foo.java`, containing a method declared as `public static void main(String[] args)`, which means you must either explain tons of concepts (what "class" means, what "public" means, what "static" means, etc.) long before you can motivate any of them, which makes everything seem complicated and hard, or hand-wave them away as incantations that you'll learn about in due time, which makes programming seem magical and mysterious.
None of which is to say that Java isn't a great language for doing professional work, just that it isn't great to start with. Git seems quite similar to me.
On the other hand, I get that it is valuable to teach techniques that will actually be useful to students in their professional life, even if they are clumsy in a non-professional setting. There's a real tension here.
Apropos of nothing else I wrote: I've always enjoyed seeing people alias `blame` as `praise` or something similarly positive (although `annotate` is the built-in neutral option, which is also pretty good).
Classroom for GitHub automates repository creation and access control, making it easy for teachers to distribute starter code and collect assignments on GitHub.
I teach a college UNIX systems programming class. This semester I decided to switch to GitHub, and so far, I can't believe I didn't do it earlier.
I like to write code in class, and it's great to be able to push every couple of minutes so students can follow along on their laptops if they want. Of course that's more about git itself, but the GitHub interface is good and I think that it lowers the frictional cost for both me and the students, so everybody gets a little more done.
I used it to teach my class as well. But I have to be honest, it wasn't obvious at first how to use it - especially how would I manage the course website there (which needed to accommodate different semesters). Eventually, I figured out that I don't really need an HTML website, but using Markdown files would get the job done (and would be better, as it makes it easy for students to commit PR with corrections and suggestions to the course website and material). I really love our setup now, but it took some figuring out the best way to do it. BTW, if anyone is interested here the course website (just as our example):
I am definitely feeling that: I've already had to do some reorganizing as I discover that some of my initial decisions weren't perfect, as to organizing the class repo.
By the way, your article has encouraged me to get the students using issues for eg. homework questions they'd normally email, thanks for that.
Sure. Basically, we go through the first half or so of Stevens' Advanced Programming in the UNIX Environment fairly sequentially. My first take was to group the example code by topic, but I've realized that it might make more sense to group it by book chapter. So that's my current reorganization plan. The thought is, with lots of topics, it will help orient people better if they have an explicit cue for what chapter to review if they are confused.
That's pretty specific to the more or less sequential approach with the book, though. It's a good book, so it can support that kind of thing.
I think it will also help with presenting the supplemental material that is linked with each chapter/section. Again, that might be specific since in the Stevens book, there is always a manpage or Single UNIX Specification reference to give for almost any section.
Yes, you're probably right. I didn't want it to include any HTML (to make it easy for anyone to contribute to course website), but perhaps there is a way to use a simple Markdown for GitHub pages.
Well, I use Octopress (similar to this) for my own blog. But, for the course, where I wanted all the students and other staff members to be involved, I wanted something much more simple. More specifically - nothing that would require building. Perhaps that could be just me and my preference.
This might be a good solution if people want something a bit more fancy as a course website. Thanks for sharing.
The process to get students fluid at the basic flow took a few days, but after a while it was great and I couldn't imagine doing it any other way. Any programming course using this is obvious, but I'd even do it for non-programming things if I could get the student trained on it in a minimal amount of time.
The only roadblocks with git are that there's so many basic ways to screw up, which are hard to fix. Let's say a student does a `git init` in their `~/code` folder that holds all of their git projects... and then makes a bunch of commits, and then can't figure out why they can't push to github. I wish there were some better failsafes to prevent such things, but they happened by accident once a week at least.