Thanks for the great report, Dena!
On Tue, Jan 9, 2018 at 7:23 PM, Strong, Dena L <dlstr...@illinois.edu> wrote: > Reporting in: I just taught from Steve’s version today, and it went > fantastically. I’ve never taught Git before. I really liked teaching with > this structure – the Dracula thing never made sense to me, whereas both the > audience and I didn’t have any problems following the “all right, we’re > adding new features to software under development” description. > > > > I would enthusiastically endorse anyone who wants to teach from this version > to give it a go! > > > > (I was particularly lucky since Maxim Belkin, my co-instructor, is > brilliant, friendly, and enthusiastic! My original co-instructor had a house > emergency and I’m really glad Max could step in. I would have been flailing > a lot when the IT pros I was teaching asked things outside my knowledge and > expertise level, but I would have been doing that with any lesson plan.) > > > > The TL;DR and a physical mechanism for conveying concepts below: > > > > This audience: 6 IT professionals ranging in experience from “I’ve never > touched Git before” to “I’ve been using it on and off for a few years, but I > still don’t get it.” > > > > The method: Steve’s non-Dracula version of git-novice, a slide deck for > supplemental concept walk-throughs, and a bunch of file folders for physical > representation of what was happening with each edit in each step. All my > links are collected up at https://tinyurl.com/itpro-gitnotes. > > > > On the potential confusion point Steve mentions below: Two of our pairs were > OK with the fork vs clone thing and worked out how not to have name space > collisions and knew where they were at. However, our third pair was > struggling and Maxim helped them out a lot. As suggested below, I think > revising it so people are forking from a different repository than you’ve > just cloned from would help reduce the name space collision headaches. And > people were also finding that they could just accept the pull request > because they already had access after having traded authorizations for > collaboration. (So maybe have them fork from the instructor’s version > instead?) > > > > We also discovered that either there weren’t instructions explicitly telling > you to go up a directory from your previous working directory before running > a clone command, or it was well enough buried that 2 of our 6 ended up > cloning their new stuff into the folder they were already working in. So > more clearly spelling out “before you start a new project, go back to your ~ > directory” could be helpful to add too? > > > > Because these were IT pros, they were more interested in complex workflows, > resets, “hitting the undo button,” and continuous integration capabilities > than in open science and R studio, so we went off the lesson plan at the end > of step 9 and Max freestyled branching, merging, resets, and travis-ci. > > > > I think it would be worth considering adding “how do you roll back” to the > course – they were really interested in branching and git reset and git > checkout, which don’t get touched on in the major material. One poor > individual had been manually undoing all his changes to get back to matching > the master version whenever he wanted to retrace his path, and I think > branches and git reset have changed his world. Food for thought? > > > > A teaching aid I found helpful: A “folders and notes” setup for physically > demonstrating what goes where at what step. (Image attached – in actual > class I put working-space on the left and repository on the right to match > reading order; this photo was when I was setting up mirrored versions to > test drive.) > > · Working directory: Papers in front of you > > · Edits: Sticky notes that get put on a thing in your working > directory > > · Stage: A folded-over piece of paper labeled “stage” (because I only > had manila or hanging folders, and the inner folders were commits) > > · Commit: “You take everything that’s in stage, and put it in this > manila folder. Then the manila folder goes into your local repository > hanging folder. You get more and more manila-folder commits as you add new > versions to your local repository, and each of them has its own label – > that’s this hash tag right here…” > > · Repositories: Two hanging folders of the same color, one in front > of the person (local) and another in a box at the end of the room > (remote/GitHub.com). > > > > It seemed to help people visualize the differences between add, commit, and > push as I walked them through things, and the manila-folder layer gave some > starter ground work for the difference between clone (“Blue wants to edit on > Pink’s project, so Blue grabs a manila commit folder from Pink’s remote > folder and puts it in Blue’s local folder in front of them”) and fork > (“Blue doesn’t want to edit in Pink’s repository, Blue wants their own. So > first we copy Pink’s manila folder commit into Blue’s remote directory, and > then Blue has their own working space for this project, and here’s how Blue > can give Pink some edits with a pull request.”) I hadn’t worked out how to > simulate branching because I knew Maxim would handle that the way he > preferred to, but everything up to that point seemed to work fine. > > I’d never thought I’d feel comfortable teaching Git, because I don’t use it > in my working life. But we needed teachers, so I dove in, and I loved this > lesson structure, and I want to give a huge thank you to both Steve (for > providing the lesson structure) and Maxim (for being the safety net and > expert guru all at the same time). :D > > > > From: Discuss [mailto:discuss-boun...@lists.software-carpentry.org] On > Behalf Of Bond, Steve (NIH/NHGRI) [F] > Sent: Tuesday, December 05, 2017 1:38 PM > To: Software Carpentry Discussion <discuss@lists.software-carpentry.org> > Subject: Re: [Discuss] Git and Github lesson (follow-up) > > > > Hi All, > > For a bit more context, we decided to strip the Dracula backdrop out of the > git lesson completely to give our workshop participants another opportunity > to write little scripts. The example we settled on was unit conversions > (dollars-to-cents, minutes-to-hours, etc.). We also wanted to change the > focus to the GitHub UI, because that is how the other instructors and I > generally manage repositories on a day-to-day basis. It seemed weird to > spend time showing students how to initialize a local repository and then > turn around and say they probably won’t often do it that way. > > In practice, the reworked lessons have gone reasonably well. Depending on > the class, though, it has gotten a bit sketchy when we move into > collaboration and conflict resolution. In the lesson as currently written, > students are asked to pair up and then create repositories that they then > reciprocally share. Unfortunately, people tend to get confused about which > repository they are modifying, which one is their own, and which is their > partner’s. It might make more sense to have the instructor create a central > repository that everyone clones and edits. Then we could create a conflict > that affects everyone the same way. > > It’s been a while since our last workshop, so the material hasn’t been > getting much attention. If there is sufficient interest from the community > though, I’m happy to facilitate further refinements on my own fork or work > with the core team on the main SWC version. > > Best, > > -Steve > > > > > > From: Anelda van der Walt <anelda.vdw...@gmail.com> > Date: Tuesday, December 5, 2017 at 10:39 AM > To: Software Carpentry Discussion <discuss@lists.software-carpentry.org> > Subject: [Discuss] Git and Github lesson (follow-up) > > > > Dear all, > > Back in July 2017 I started a conversation on the discuss list about > alternative Git/Github lessons that exist in the Carpentry community [1]. So > many of you responded with suggestions about how you have dropped the > Dracula example or augmented it with episodes on things like Git GUI or > Github and more. Thanks very much to everyone who responded. > > One of the first lessons I was pointed to, was Steve Bond's (copied on this > email) lesson [2] which was originally forked from the SWC git novice > lesson, but introduces Github and constantly show how to do things both in > git and github. > > Last week we ran a workshop at NWU where we trialled Steve's lesson. I chose > this lesson as it was mature enough to use off the shelf (Steve had put a > lot of effort in to make sure the lesson is refined). > > > Feedback from the workshop: > > It was great to introduce the power of local repositories and connect that > with online repositories and collaboration. > The lesson makes version control much more accessible even for learners who > are not yet comfortable on the commandline. > The switching adds cognitive load but we went very slow and got good > feedback. > I veered off the script to spend some time introducing all the things that > can be clicked on in the Github interface and people found that very > valuable, but I don't know how to incorporate this as an episode in the > lesson making it practical? > We didn't get to the collaboration part even though we had time to spare as > people's brains were fried by late Friday afternoon. We ended the workshop > on a high. The lesson includes screenshots for every step of the way so I > recommended people referred back to the lesson when they get to > collaboration and conflict resolution. > > Afterwards a colleague did a short demo of how she uses Git from RStudio and > another colleague showed the same for his text editor (Visual Studio Code > [3] - available for Mac, Windows, Linux). This was really helpful to show > people how they can use even better tools to be more efficient and adopt > version control easier. > > I'm wondering if the community would like to try out Steve's lesson as > alternative to Dracula and provide some feedback? Maybe this is a low > hanging fruit waiting to be picked and solve some of our git > teaching/learning problems? > > Steve already did most of the work... > > > > What do you think? > > > > Thanks, > > > > Anelda > > > > [1] > http://lists.software-carpentry.org/pipermail/discuss/2017-July/005319.html > > [2] https://github.com/biologyguy/git-novice > > [3] https://code.visualstudio.com/docs/supporting/faq > > > _______________________________________________ > Discuss mailing list > Discuss@lists.software-carpentry.org > http://lists.software-carpentry.org/listinfo/discuss _______________________________________________ Discuss mailing list Discuss@lists.software-carpentry.org http://lists.software-carpentry.org/listinfo/discuss
